By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,772 Members | 906 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,772 IT Pros & Developers. It's quick & easy.

Gnu/Linux dialogue boxes in python

P: n/a
Hi,
Okay, so I am in the mood to try this: Inform the user about what modules
the app requires in a graphical dialogue that can vary depending on what
the system already has installed. (It will fail-to output on cli)

I am running Kubuntu and I seem to have 'kdialog' installed by default (not
sure if it came as stock.)

What other 'stock' systems are there out there in the wild? Ubuntu? Suse?
Fedora? Others?

I would take a stab at wrapping them in python so that I can use the first
dialogue system found to popup messages for the user.

(Hoping, natch, that this has already been done ... ? )

\d

Nov 30 '07 #1
Share this Question
Share on Google+
12 Replies


P: n/a
On 30 Nov, 14:55, Donn Ingle <donn.in...@gmail.comwrote:
Hi,
Okay, so I am in the mood to try this: Inform the user about what modules
the app requires in a graphical dialogue that can vary depending on what
the system already has installed. (It will fail-to output on cli)

I am running Kubuntu and I seem to have 'kdialog' installed by default (not
sure if it came as stock.)
I think it's part of KDE. You can check by doing something like...

dpkg -S kdialog

That should tell you about the package which provided it, which is
possibly one of the KDE packages.
What other 'stock' systems are there out there in the wild? Ubuntu? Suse?
Fedora? Others?
There's Xdialog which is the old-fashioned graphical dialogue tool and
Zenity: the oddly named GNOME successor to gdialog. See this article
for some details:

http://www.linux.com/articles/114156
I would take a stab at wrapping them in python so that I can use the first
dialogue system found to popup messages for the user.

(Hoping, natch, that this has already been done ... ? )
I wanted to do this for the desktop module [1], but without any
obvious dialogue tool support for Windows, I didn't proceed any
further than a simple wrapping around KDialog, Zenity and Xdialog,
since the aim is to cover more than the usual UNIX-like platforms.
However, I could make that code available separately, or someone could
tell me how Windows and Mac OS X manage to perform the same tricks.
Perhaps some nasty win32 API dialogues need to be created by hand on
Windows - something which I certainly have no interest in doing, but
someone might find it exciting work.

I thought that there was another package out there which wrapped these
programs, but I can't seem to find it right now. It's certainly worth
trying to make a generic interface, though, since the features
provided by each of the programs do differ in certain important ways
which you might not care too much about if you only really care about
portability. For example, if you want to have a list of choices, I
seem to recall that KDialog offers much more flexibility than Zenity
(whose method of presenting various things is fairly awful at times),
but the lowest common denominator might well be better than reading up
on all the options for each of the programs and coding something up
yourself.

Paul

[1] http://www.python.org/pypi/desktop
Nov 30 '07 #2

P: n/a
Paul Boddie wrote:
I didn't proceed any
further than a simple wrapping around KDialog, Zenity and Xdialog,
since the aim is to cover more than the usual UNIX-like platforms.
However, I could make that code available separately
Thanks for the feedback and the links. I'd like to use your code (if you
don't mind! ) if it's GPL or something similar -- it may save me time.

Anyone know if zenity can be reliably assumed to be installed on a typical
Gnome desktop?

\d

Dec 1 '07 #3

P: n/a
[1] http://www.python.org/pypi/desktop
Oh, just saw this link and fetched the code -- will have a look around.

\d

Dec 1 '07 #4

P: n/a
On 1 Des, 07:02, Donn Ingle <donn.in...@gmail.comwrote:
[1]http://www.python.org/pypi/desktop

Oh, just saw this link and fetched the code -- will have a look around.
The dialogue box support isn't in the released version, but I'll
either upload a new release, or I'll make the code available
separately.

Paul
Dec 1 '07 #5

P: n/a
Paul Boddie wrote:
but I'll
either upload a new release, or I'll make the code available
separately.
Thanks, give me a shout when you do -- if you remember!

\d

Dec 2 '07 #6

P: n/a
On Fri, 30 Nov 2007 15:55:16 +0200, Donn Ingle <do********@gmail.comwrote:
Hi,
Okay, so I am in the mood to try this: Inform the user about what modules
the app requires in a graphical dialogue that can vary depending on what
the system already has installed. (It will fail-to output on cli)

I am running Kubuntu and I seem to have 'kdialog' installed by default (not
sure if it came as stock.)

What other 'stock' systems are there out there in the wild? Ubuntu? Suse?
Fedora? Others?
There are countless Unix configurations out there which can run Python.

I run Debian Linux, and I install none of that KDE or Gnome
cra^H^H^Hsoftware. Apt/dpkg uses some kind of console dialogue program
("newt"?) but that's the only thing I have.

There is no guarantee that even a modern, full-featured Unix
installation contains a dialogue application like you want.
I would take a stab at wrapping them in python so that I can use the first
dialogue system found to popup messages for the user.
But why? Either

(a) your program has a GUI and can display a dialogue box by itself
(b) your program has a GUI but has problems opening even a tiny part
of it (missing modules?), and should output diagnostics on the terminal
(c) your program is console-based, or a daemon or something, and should
not require a GUI to work.

/Jörgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!
Dec 2 '07 #7

P: n/a
But why? Â*Either
>
(a) your program has a GUI and can display a dialogue box by itself
(b) your program has a GUI but has problems opening even a tiny part
of it (missing modules?), and should output diagnostics on the terminal
(c) your program is console-based, or a daemon or something, and should
not require a GUI to work.
I realise those things, and it's the simplest case.

I was thinking of <a yet unknown, to me, way toallow a setup.py file to
be double-clicked and have the install start to run. When it comes to the
bit where all the import statements happen, it can popup a stock dialogue
informing the user about what they need to install first.

I was hoping to get a list of the most common, distro-installed scriptable
dialogues. Perhaps I should even look at TK -- I understand it comes
standard with Python?

Another thing to realize, and I have experienced this first-hand, is that a
bunch of text, no matter how nicely formatted, spewed out of an app in
white on black ( the usual terminal colours ) does *not* invite a user's
attention. To read it is a chore and they usually panic.

\d

Dec 2 '07 #8

P: n/a
On Sun, 02 Dec 2007 17:18:45 +0200, Donn Ingle <do********@gmail.comwrote:
>But why? *Either

(a) your program has a GUI and can display a dialogue box by itself
(b) your program has a GUI but has problems opening even a tiny part
of it (missing modules?), and should output diagnostics on the terminal
(c) your program is console-based, or a daemon or something, and should
not require a GUI to work.
I realise those things, and it's the simplest case.

I was thinking of <a yet unknown, to me, way toallow a setup.py file to
be double-clicked and have the install start to run. When it comes to the
bit where all the import statements happen, it can popup a stock dialogue
informing the user about what they need to install first.
But does "setup.py install" really trigger any of your code's imports?
I must admit I haven't give it much thought.

Somehow this seems like setup.py's job, and if it cannot do it maybe
someone should invent an alternative.

Or maybe it's setup.py's job to create a suitable distribution:

../setup.py --help-commands
...
bdist create a built (binary) distribution
bdist_dumb create a "dumb" built distribution
bdist_rpm create an RPM distribution
bdist_wininst create an executable installer for MS Windows

"bdist_wininst" has a very nice GUI. But I doubt that you can
make it warn for unmet dependencies.
Another thing to realize, and I have experienced this first-hand, is that a
bunch of text, no matter how nicely formatted, spewed out of an app in
white on black ( the usual terminal colours ) does *not* invite a user's
attention. To read it is a chore and they usually panic.
I have experienced it too. I have tried to understand it, and failed.
Do they read books and newspapers? They are generally not stupid.
So what you really want is a nice GUI Python installer for Linux,
which everyone can use, and which can explain to users that they need
some other packages first. Yes, that sounds like a very reasonable
thing to want.
/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!
Dec 7 '07 #9

P: n/a
On Nov 30, 7:55 am, Donn Ingle <donn.in...@gmail.comwrote:
Hi,
Okay, so I am in the mood to try this: Inform the user about what modules
the app requires in a graphical dialogue that can vary depending on what
the system already has installed. (It will fail-to output on cli)

I am running Kubuntu and I seem to have 'kdialog' installed by default (not
sure if it came as stock.)

What other 'stock' systems are there out there in the wild? Ubuntu? Suse?
Fedora? Others?

I would take a stab at wrapping them in python so that I can use the first
dialogue system found to popup messages for the user.

(Hoping, natch, that this has already been done ... ? )

\d
If you built a GUI with wxPython, it would just use the OS's native
dialogs unless it didn't have one and then it would use a generic
dialog. I would think creating a installer with wxPython and threads
would be fairly trivial.

Mike
Dec 7 '07 #10

P: n/a
On 7 Des, 17:43, kyoso...@gmail.com wrote:
>
If you built a GUI with wxPython, it would just use the OS's native
dialogs unless it didn't have one and then it would use a generic
dialog. I would think creating a installer with wxPython and threads
would be fairly trivial.
I'm not convinced that bundling a GUI component with a program which
may have no GUI elements whatsoever is easier than having a
lightweight wrapper around the spawning of a program like kdialog or
Xdialog. Of course, there's some work required in supporting dialog
program variants, mostly because the developers of these programs do
like to extend the interface and add new features and options, but
it's arguably less effort than messing around with "wxPython and
threads" (without considering the additional dependencies).

Of course, not all operating systems bundle a dialog-like program, so
perhaps there'd be a need to duplicate this functionality for some
platforms, as you suggest.

Paul
Dec 8 '07 #11

P: n/a
On 2 Des, 07:02, Donn Ingle <donn.in...@gmail.comwrote:
Paul Boddie wrote:
but I'll either upload a new release, or I'll make the code available
separately.

Thanks, give me a shout when you do -- if you remember!
I've now uploaded a new release of the desktop module which is now, in
fact, a package:

http://www.python.org/pypi/desktop

From release 0.3 onwards, the intention is that the desktop.dialog
module (spelled in the American way to show the connection with the
classic dialog command) will support dialogue boxes for many desktop
environments, although only X11 environments are supported so far.
There's also a desktop.windows module (no relation to the operating
system with the dubious trademark) which currently only supports
window introspection in X11 environments, but I imagine that
supporting win32 wouldn't be too difficult for those motivated enough
to look into it.

Paul
Dec 17 '07 #12

P: n/a
I've now uploaded a new release of the desktop module which is now, in
fact, a package:
Thanks Paul, I saw it via the cheese shop rss. I have been too busy to read
this list for a week. I will have a look in due course.

\d

Dec 19 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.