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

Python and GUI

P: n/a

Just wondering on what peoples opinions are of the GUIs avaiable for
Python?

All I am doing is prompting users for some data (listbox, radio
buttons, text box, ect...). Then I will have some text output, maybe
a scrolling text message as things are happening.

I have some minor things I need to do, for example, if Checkbutton X
is clicked, I need to disable TextBox Y, and I would like to display
the scrolling text (output)

Ultimately, is it worth downloading and learning some of the packages
avaiable for Python, or should I just stick to the Tkinter stuff that
is included.

More specifically, has anyone used the Qt stuff for python, easy to
use?

May 21 '07 #1
Share this Question
Share on Google+
31 Replies


P: n/a
sd******@gmail.com wrote:
Just wondering on what peoples opinions are of the GUIs avaiable for
Python?
We have used wxPython with great results. It's cross platform. Can use
native OS widgets and is easy to program. Compiles easily to exe
binaries for Windows users as well.

Best of luck,
Brad
May 21 '07 #2

P: n/a
On 21 May 2007 08:39:44 -0700, sd******@gmail.com wrote:
>All I am doing is prompting users for some data (listbox, radio
buttons, text box, ect...). Then I will have some text output, maybe
a scrolling text message as things are happening.

I have some minor things I need to do, for example, if Checkbutton X
is clicked, I need to disable TextBox Y, and I would like to display
the scrolling text (output)
You should be able to do all those things with TKInter (though I am
not sure about the automatted scrolling text.).
>Ultimately, is it worth downloading and learning some of the packages
avaiable for Python, or should I just stick to the Tkinter stuff that
is included.
Like Brad, I would recommend trying wxPyhton
(http://www.wxpython.org/). There is an installer for Windows. Best is
to look at the wxPython-Demo first thing. It contains a lot of
example-code to borrow from. You can both read and try the code within
the Demo-Application.

However, the documentation of the class-library is for C++ only. You
have to apply it to the python-version yourself.

I prefer wxPython to TKInter because it offers more complex widgets
namely Grids and Tabular-Lists right out of the box.

Best wishes,
Thomas
May 21 '07 #3

P: n/a
sd******@gmail.com wrote:
Just wondering on what peoples opinions are of the GUIs avaiable for
Python?

All I am doing is prompting users for some data (listbox, radio
buttons, text box, ect...). Then I will have some text output, maybe
a scrolling text message as things are happening.

I have some minor things I need to do, for example, if Checkbutton X
is clicked, I need to disable TextBox Y, and I would like to display
the scrolling text (output)

Ultimately, is it worth downloading and learning some of the packages
avaiable for Python, or should I just stick to the Tkinter stuff that
is included.

More specifically, has anyone used the Qt stuff for python, easy to
use?
There's PyQt thingy, imho very good and easy to learn/use, but still
powerful. I've used it for a small gui-oriented project with almost no
problems and it worked like a charm. However, sometimes I had troubles
finding useful documentation for it.
I've also tried to play with PyGTK, it's quite nice and easy (and you
have the advantage of Glade), but I don't like GTK way of creating GUI.
I haven't used Tkinter a lot, only looked at it. And I didn't like it much.

I would really suggest PyQt. (with a big IMHO :)

Petr
May 21 '07 #4

P: n/a
In article <11**********************@b40g2000prd.googlegroups .com>,
<sd******@gmail.comwrote:
>
Just wondering on what peoples opinions are of the GUIs avaiable for
Python?

All I am doing is prompting users for some data (listbox, radio
buttons, text box, ect...). Then I will have some text output, maybe
a scrolling text message as things are happening.

I have some minor things I need to do, for example, if Checkbutton X
is clicked, I need to disable TextBox Y, and I would like to display
the scrolling text (output)

Ultimately, is it worth downloading and learning some of the packages
avaiable for Python, or should I just stick to the Tkinter stuff that
is included.

More specifically, has anyone used the Qt stuff for python, easy to
use?
While PyQt is plenty wonderful, Tkinter's more than adequate,
given the requirements you've described.

May 21 '07 #5

P: n/a
sd******@gmail.com wrote:
Just wondering on what peoples opinions are of the GUIs avaiable for
Python?
Python has, I believe, 4 compelling choices for GUI library: Tkinter,
wxPython, PyQt, and PyGTK. Like everything in life, each has their
relative merits and downsides. Briefly, here are my feelings on each,
but I'm mostly versed in wxPython.
Tkinter:

Pros: comes with Python out of the box; terse; easy

Cons: owner-drawn (not-native OS widgets); limited in out-of box
functionality; kind of ugly
wxPython:

Pros: easy to install binary on all platforms, active development,
active friendly community of contributors, native os base widgets on all
platforms.

Cons: hard to build from source on all platforms, everything but the
kitchen sink comes with it, and some things are pretty buggy still or
abandoned.

PyQt:

Pros: looks good on all platforms, easy to install and use.
Cons: licensing issues require you to understand lots of specifics;
owner-drawn widgets.

PyGTK:

Can't comment because I haven't used it. The major con in my mind is
that (I think) you need the Gtk library to be installed on all
platforms, so on OS X / Windows the widgets won't look platform-native.

All I am doing is prompting users for some data (listbox, radio
buttons, text box, ect...). Then I will have some text output, maybe
a scrolling text message as things are happening.
I think each of the GUI libraries would be able to handle this easily.

I have some minor things I need to do, for example, if Checkbutton X
is clicked, I need to disable TextBox Y, and I would like to display
the scrolling text (output)
Again, this is simply responding to events as they happen. You set up a
callback function with your reactive code, and tell the GUI library to
call that function when the event occurs.

Ultimately, is it worth downloading and learning some of the packages
avaiable for Python, or should I just stick to the Tkinter stuff that
is included.
I think everyone should use wxPython, but I'm biased.

More specifically, has anyone used the Qt stuff for python, easy to
use?
I've used it and it is easy, yes. Relative ease I can't answer though,
because I find wxPython extremely easy due to depth of use over the years.

Shameless plug: consider using Dabo on top of wxPython - we feel it
makes wxPython even easier and more pythonic, but admittedly there's a
bit of a learning curve there too. Even though Dabo is a full
application framework originally meant for desktop database
applications, it is modular and you can choose to only use the UI
bits... http://dabodev.com

--
pkm ~ http://paulmcnett.com
May 21 '07 #6

P: n/a
On 2007-05-21, Cameron Laird <cl****@lairds.uswrote:
While PyQt is plenty wonderful, Tkinter's more than adequate,
given the requirements you've described.
Tkinter is easier to use for simple things. You just have to
try not to think about the fact that it's pulling a complete
Tcl interpreter into your app. It also seems to come only in
various flavors of ugly. ;)

wxPython (based on wxWidgets) is cross-platform,
industrial-strength and has native look-and-feel. It is,
however, more complex to use. In some places it's not very
"Pythonic" and shows it's C/C++ heritage (this has improved a
bit in the past couple years). There are also a couple more
Pythonic wrappers on top of wxWidgets.

pyGTK isn't a bad choice if Linux/Unix is what you care about.
GTK for Windows was still a bit sketchy the last time I looked
into it.

PyQt I haven't tried, but both Linux/Unix and Windows support
is reported to be solid.

--
Grant Edwards grante Yow! My polyvinyl cowboy
at wallet was made in Hong
visi.com Kong by Montgomery Clift!
May 21 '07 #7

P: n/a
sd******@gmail.com wrote:
Ultimately, is it worth downloading and learning some of the packages
avaiable for Python, or should I just stick to the Tkinter stuff that
is included.
It depends. Are you selling your application commercially/closed-source
or is it freeware/open-source? Are you deploying on several platforms,
or just one?

Here are a few things to consider:

1. Tkinter is simple to code and easy to deploy. It's a bit bare-bones
without additional packages.
2. wxPython is big, harder to learn than Tkinter, but looks good on Mac,
Windows, and *Nix. It will require users to install a lot of extra stuff
(or you'll have to bundle the extra stuff).
3. PyQt is also nice, and works well on Mac/Windows/*Nix but the free
version requires your app to be released under the GPL. That may or may
not be an issue for you. PyQt is also a large package to install.
4. PyGTK is popular on*Nix and works OK on Windows. But it doesn't run
natively on the Mac.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
May 21 '07 #8

P: n/a
Kevin Walzer wrote:
2. wxPython is big, harder to learn than Tkinter, but looks good on Mac,
Windows, and *Nix. It will require users to install a lot of extra stuff
(or you'll have to bundle the extra stuff).
PyInstaller builds binaries beautifully from raw py source. No need to
bundle the wx stuff. I develop on Linux, build on Windows (with
PyInstaller) and it works great. The source runs on any platform, the
Windows binaries is neat for the point and click users.

Brad
May 21 '07 #9

P: n/a
Hello,

My 2 cents contribution:
To me all toolkits offer nice features. It's just a matter of choice
depending on your needs.
I've personally chosen pyGTK and I use it successfully on
Linux/windows/MacOsX for my home grown softs.
The reasons of my choice:
- It looks the same on all platform (actualy I want to use the softs
on different platform and I definitly prefer that it look the same on
all of them!)
- It's easy to develop with (Glade3,...)
- It works perfectly on all platform and it's no difficult to install
(even compile!) on all of them.
- It looks nice (GTK is the Gimp ToolKit)

Let me say that I also tried TkInter (ugly :-( ), pyQt (a mess to
understand what kind of license you are allowed to use for you soft),
wxpython (it's GTK on Linux but not on other platform and thus not
looking the same on all platform...)

Just a personal view...

David

21 May 2007 08:39:44 -0700, sd******@gmail.com <sd******@gmail.com>:
>
Just wondering on what peoples opinions are of the GUIs avaiable for
Python?

All I am doing is prompting users for some data (listbox, radio
buttons, text box, ect...). Then I will have some text output, maybe
a scrolling text message as things are happening.

I have some minor things I need to do, for example, if Checkbutton X
is clicked, I need to disable TextBox Y, and I would like to display
the scrolling text (output)

Ultimately, is it worth downloading and learning some of the packages
avaiable for Python, or should I just stick to the Tkinter stuff that
is included.

More specifically, has anyone used the Qt stuff for python, easy to
use?

--
http://mail.python.org/mailman/listinfo/python-list
May 21 '07 #10

P: n/a
On Mon, 2007-05-21 at 18:23 +0200, Petr Muller wrote:
There's PyQt thingy, imho very good and easy to learn/use, but still
powerful. I've used it for a small gui-oriented project with almost no
problems and it worked like a charm. However, sometimes I had troubles
finding useful documentation for it.
I've also tried to play with PyGTK, it's quite nice and easy (and you
have the advantage of Glade), but I don't like GTK way of creating GUI.
I haven't used Tkinter a lot, only looked at it. And I didn't like it much.
How does GTK's way of creating the GUI (I presume you're not talking
look and feel) differ from Qt's? From what I can see (having developed
large apps in both GTKmm and Qt (C++), they both function the same. In
other words you create the widget first, then parent it in a container
and add callbacks. Whereas wxPython's approach is somewhat different.

It appears that most wxPython apps setup the GUI programmatically,
whereas Most Qt and Gtk apps tend to use XML-based gui-building
factories. In this latter case, Glade's method is quite different from
Qt's.
>
I would really suggest PyQt. (with a big IMHO :)

Petr
May 21 '07 #11

P: n/a
Well wxPython offers all of the above. They use XRC which is a XML
file which can be loaded inside the GUI, that auto-creates the
components + layout for you. It also supports creating the gui
programatically, which might be very handy when your layout is
undetermined or changes when users select options etc.

I use wxPython because I am used to wxWidgets C++ and it is very good
under python (I am a python newbie and the integration in python is
fine). I use wxGlade to auto generate the GUI from inside the GUI
designer, works great as well

As for tkinter, PyQt or PyGTK, I do not have much experience with
them. You don't change a winning formula ;-)

- Jorgen
On 5/21/07, Michael L Torrie <to*****@chem.byu.eduwrote:
On Mon, 2007-05-21 at 18:23 +0200, Petr Muller wrote:
There's PyQt thingy, imho very good and easy to learn/use, but still
powerful. I've used it for a small gui-oriented project with almost no
problems and it worked like a charm. However, sometimes I had troubles
finding useful documentation for it.
I've also tried to play with PyGTK, it's quite nice and easy (and you
have the advantage of Glade), but I don't like GTK way of creating GUI.
I haven't used Tkinter a lot, only looked at it. And I didn't like it much.

How does GTK's way of creating the GUI (I presume you're not talking
look and feel) differ from Qt's? From what I can see (having developed
large apps in both GTKmm and Qt (C++), they both function the same. In
other words you create the widget first, then parent it in a container
and add callbacks. Whereas wxPython's approach is somewhat different.

It appears that most wxPython apps setup the GUI programmatically,
whereas Most Qt and Gtk apps tend to use XML-based gui-building
factories. In this latter case, Glade's method is quite different from
Qt's.

I would really suggest PyQt. (with a big IMHO :)

Petr

--
http://mail.python.org/mailman/listinfo/python-list
May 21 '07 #12

P: n/a
On 5/21/07, Paul McNett <p@ulmcnett.comwrote:
Shameless plug: consider using Dabo on top of wxPython - we feel it
makes wxPython even easier and more pythonic, but admittedly there's a
bit of a learning curve there too. Even though Dabo is a full
application framework originally meant for desktop database
applications, it is modular and you can choose to only use the UI
bits... http://dabodev.com
I second this. I used (and struggled!) with wxPython for over a year.
The results were great, but I hated coding it. I switched to the Dabo
UI wrapper, and stuff that used to take me a day to create is now done
in an hour or two.

--

# p.d.
May 21 '07 #13

P: n/a
On May 21, 10:50 am, brad <byte8b...@gmail.comwrote:
sdoty...@gmail.com wrote:
Just wondering on what peoples opinions are of the GUIs avaiable for
Python?

We have used wxPython with great results. It's cross platform. Can use
native OS widgets and is easy to program. Compiles easily to exe
binaries for Windows users as well.

Best of luck,
Brad
I don't recoment gtk because it doesn't install well on python 2.5 on
windows. It is a shame because it has alot of realy nice 3d
packages. I would stick with wxpython and tkinter for general use gui
use there are other options for the high tek 3d stuff

May 22 '07 #14

P: n/a
Paul McNett wrote:
Shameless plug: consider using Dabo on top of wxPython - we feel it
makes wxPython even easier and more pythonic, but admittedly there's a
bit of a learning curve there too. Even though Dabo is a full
application framework originally meant for desktop database
applications, it is modular and you can choose to only use the UI
bits... http://dabodev.com

Hi Paul,

I'm considering moving over to dabo for wxpython development.
However I do not write traditional database applications
├* la foxpro (I'm a 20 years user of fox...) anymore.
Only xml-fed applications.

I'm a bit hesitant to jump onboard since dabo seemns to carry
over its own lot of database connectivity dependancy.

Can you reasonably use dabo for plain datafree application?

Fran├žois
May 22 '07 #15

P: n/a
daniel gadenne wrote:
Paul McNett wrote:
>Shameless plug: consider using Dabo on top of wxPython - we feel it
makes wxPython even easier and more pythonic, but admittedly there's a
bit of a learning curve there too. Even though Dabo is a full
application framework originally meant for desktop database
applications, it is modular and you can choose to only use the UI
bits... http://dabodev.com


Hi Paul,

I'm considering moving over to dabo for wxpython development.
However I do not write traditional database applications
├* la foxpro (I'm a 20 years user of fox...) anymore.
Only xml-fed applications.

I'm a bit hesitant to jump onboard since dabo seemns to carry
over its own lot of database connectivity dependancy.

Can you reasonably use dabo for plain datafree application?

Fran├žois

Yes, the only database dependency is sqlite as a store for app-preferences.
But even this could get changed easily.

Uwe
May 23 '07 #16

P: n/a
On 5/22/07, daniel gadenne <da************@caramail.frwrote:
I'm considering moving over to dabo for wxpython development.
However I do not write traditional database applications
Ó la foxpro (I'm a 20 years user of fox...) anymore.
Only xml-fed applications.

I'm a bit hesitant to jump onboard since dabo seemns to carry
over its own lot of database connectivity dependancy.

Can you reasonably use dabo for plain datafree application?
That's exactly how I use it. I write apps that don't use database
servers, and don't have any database programs installed. I just want
the dabo.ui stuff, since it makes wxPython so easy to work with.

--

# p.d.
May 23 '07 #17

P: n/a
Peter Decker wrote:
On 5/22/07, daniel gadenne <da************@caramail.frwrote:
>I'm considering moving over to dabo for wxpython development.
However I do not write traditional database applications
├* la foxpro (I'm a 20 years user of fox...) anymore.
Only xml-fed applications.

I'm a bit hesitant to jump onboard since dabo seemns to carry
over its own lot of database connectivity dependancy.

Can you reasonably use dabo for plain datafree application?

That's exactly how I use it. I write apps that don't use database
servers, and don't have any database programs installed. I just want
the dabo.ui stuff, since it makes wxPython so easy to work with.
Dabo has three main modules: db, biz, and ui, and an overarching
application object. Every class descends from an abstract dObject. For
database apps, you'd typically set some connection information in the db
layer, put all your business code in the biz layer, and define your GUI
in the (you guessed it) ui layer. You can certainly do what Peter has
done and only use the ui layer and application object. I've done this
myself and if I ever had to code a non-database UI that's probably what
I'd do, too. Although I have to admit I can't really picture an
application that doesn't need to save data. Here's a simple example that
puts up a textbox:

"""
import dabo
dabo.ui.loadUI("wx")

app = dabo.dApp()
app.setup()

frm = app.MainForm
tb = dabo.ui.dTextBox(frm, Value="Type in here", FontBold=True)

app.start()
"""

You can easily define your own subclasses, too:

"""
import dabo
dabo.ui.loadUI("wx")

class MyRadioList(dabo.ui.dRadioList):
def initProperties(self):
self.Choices = ["Snakes", "Bees", "Fishes"]

def onHit(self, evt):
print "Radio choice '%s' selected." % self.Value

app = dabo.dApp()
app.setup()
frm = app.MainForm
rl = MyRadioList(frm)
app.start()
"""

So, yes, you can reasonably use Dabo even if you have no traditional
database in the mix.

--
pkm ~ http://paulmcnett.com
May 23 '07 #18

P: n/a
Peter Decker wrote:
On 5/21/07, Paul McNett <p@ulmcnett.comwrote:
>Shameless plug: consider using Dabo on top of wxPython - we feel it
makes wxPython even easier and more pythonic, but admittedly there's a
bit of a learning curve there too. Even though Dabo is a full
application framework originally meant for desktop database
applications, it is modular and you can choose to only use the UI
bits... http://dabodev.com

I second this. I used (and struggled!) with wxPython for over a year.
The results were great, but I hated coding it. I switched to the Dabo
UI wrapper, and stuff that used to take me a day to create is now done
in an hour or two.
Hello,

I'd like to ask the Python community about this, because it seems to me that there is
a real need that is not being met very effectively. Almost everyone agrees that
wxPython looks great and is very powerful, and for full-fledged cross-platform
applications is nearly the best, if not *the* best, choice as far as *function* and
*look* are concerned. The next sentence out of Python programmers seems to be
"...but wx is written in C++ and definitely shows, even in the Python port". It's
just not very pythonic.

Then there is Dabo, which I personally have had problems with. I am looking for a
pythonic, professional looking GUI framework. I first tried dabo with python 2.4,
and had to install sqlite, which seemed a bit odd for trying to just get a GUI
framework...I understand why, but when you're looking for one thing, having it tied
to a completely different thing feels a little strange. I never got it working in
Python2.5, either on Linux or OS X, and the problem is most definitely mine and I
didn't have the patience to debug it. I am really not trying to diss dabo here,
because there enough people who swear by it, that it must be doing many things right.

My problem with Dabo is not what it is, it is what I am looking for...a pythonic GUI
framework. Coming from Unix, I generally feel that a program should try to do one
thing, and one thing well. To mix really different functionality seems to me to be a
bad idea. If you can use the GUI parts separately, why not package it separately?
One might find a lot of users who only what that.

Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). In my view, this is
*exactly* what python needs, and its not being maintained anymore as far as I can
tell. What I like about it is:

1) it is small...I can include the entire wax distribution in my app with only a 780k
footprint.
2) it is a very thin layer on wx, so when something doesn't quite work, I can
immediately fall back onto wx, mixing and matching wax and wx objects. it's just
that the wax objects have more pythonic calling and use properties
Is there a reason that the port of wxPython doesn't include wax, or something
similar? It would seem pretty straightforward, when porting the wx to Python, to
simply include such a wrapper. I wish I were more clever, and had more time, to take
over the maintenance of wax because I think it is the most straightforward,
practical, and pythonic solution out there.
Do others think like me here?
thanks,

Brian Blais
--
-----------------

bb****@bryant.edu
http://web.bryant.edu/~bblais
May 24 '07 #19

P: n/a
On 2007-05-24, Brian Blais <bb****@bryant.eduwrote:
I'd like to ask the Python community about this, because it
seems to me that there is a real need that is not being met
very effectively. [...] "...but wx is written in C++ and
definitely shows, even in the Python port". It's just not
very pythonic.

Then there is Dabo, which I personally have had problems with.
[...]
I haven't tried Dabo, so I can't comment.
Finally, consider wax (http://zephyrfalcon.org/labs/wax.html).
In my view, this is *exactly* what python needs, and its not
being maintained anymore as far as I can tell. What I like
about it is:

1) it is small...I can include the entire wax distribution in
my app with only a 780k footprint.

2) it is a very thin layer on wx, so when something doesn't
quite work, I can immediately fall back onto wx, mixing and
matching wax and wx objects. it's just that the wax
objects have more pythonic calling and use properties
I did try wax, and I liked it. It seemed much more "Pythonic"
than bare wxPython, and resulted in cleaner, easier-to-read
code. When I tried it, it was still early in its development,
and there were still parts of it that needed to be fleshed out
(a lot of stuff was still unwrapped). I contributed a little
bit of code (wrapping one or two more things), but I didn't
have enough time at that point to wrap and debug all the things
I needed, so I switched back to plain wxPython (I had a mixture
of wax and wx for a little while, but I that annoyed me too
much).
Is there a reason that the port of wxPython doesn't include
wax, or something similar? It would seem pretty
straightforward, when porting the wx to Python, to simply
include such a wrapper. I wish I were more clever, and had
more time, to take over the maintenance of wax because I think
it is the most straightforward, practical, and pythonic
solution out there.

Do others think like me here?
Yes. I thought wax was a good idea, and there was a a good
start on an implementation.

--
Grant Edwards grante Yow! My nose feels like a
at bad Ronald Reagan movie ...
visi.com
May 24 '07 #20

P: n/a
On May 24, 2007, at 10:22 AM, Brian Blais wrote:
Then there is Dabo, which I personally have had problems with. I
am looking for a
pythonic, professional looking GUI framework. I first tried dabo
with python 2.4,
and had to install sqlite, which seemed a bit odd for trying to
just get a GUI
framework...I understand why, but when you're looking for one
thing, having it tied
to a completely different thing feels a little strange.
FWIW, we made that decision only after Python itself committed to
including SQLite as part of the standard distribution. While there
may have been some problems during the transition, such as you
apparently had, it made for a much better product in the long run.
I never got it working in
Python2.5, either on Linux or OS X, and the problem is most
definitely mine and I
didn't have the patience to debug it. I am really not trying to
diss dabo here,
because there enough people who swear by it, that it must be doing
many things right.
I checked the archives, and didn't find any messages from you asking
for help. We know that the documentation is far from complete, and
the installation process can be problematic, but one thing we pride
ourselves on is quick response to help requests, and then fixing
whatever it was that caused the initial problem.
My problem with Dabo is not what it is, it is what I am looking
for...a pythonic GUI
framework. Coming from Unix, I generally feel that a program
should try to do one
thing, and one thing well. To mix really different functionality
seems to me to be a
bad idea. If you can use the GUI parts separately, why not package
it separately?
One might find a lot of users who only what that.
We've thought about doing exactly that, but to be honest, it would
take a large investment of time without a corresponding increase in
value. Right now all you have to do is install Dabo, and then just
use the dabo.ui classes. You never need to touch the database or
business object layers if you don't want to.

Also, I don't feel that we are "mixing different functionality".
Rather, we are creating an integrated environment for those wishing
to create rich desktop apps. Nearly all such apps require displaying
and persisting information, and that's what Dabo is designed to do.
If you don't need persistent information, the display stuff works
just fine.

I'd encourage anyone who is curious about what dabo.ui offers to
view the part of my recent PyCon presentation that discusses exactly
this topic. Take a look at http://dabodev.com/pycon2007?3 to see an
example of simpler and more Pythonic Dabo code is compared to what
you would have to write in either raw wxPython or even Wax.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

May 24 '07 #21

P: n/a
In article <11**********************@b40g2000prd.googlegroups .com>,
sd******@gmail.com wrote:
Just wondering on what peoples opinions are of the GUIs avaiable for
Python?

All I am doing is prompting users for some data (listbox, radio
buttons, text box, ect...). Then I will have some text output, maybe
a scrolling text message as things are happening.

I have some minor things I need to do, for example, if Checkbutton X
is clicked, I need to disable TextBox Y, and I would like to display
the scrolling text (output)

Ultimately, is it worth downloading and learning some of the packages
avaiable for Python, or should I just stick to the Tkinter stuff that
is included.

More specifically, has anyone used the Qt stuff for python, easy to
use?
My opinion is that Tkinter is perfect for the job you describe. It is
easy to use, fairly pythonic (an issue with some competing toolkits) and
does not require any fancy installation.

If you want a very professional and "native" look then you have to work
harder. Options include Tkinter with tile, wxPython, PyQt and several
others.

-- Russell
May 24 '07 #22

P: n/a
>
Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). In my
view, this is *exactly* what python needs, and its not being maintained
anymore as far as I can tell. What I like about it is:

1) it is small...I can include the entire wax distribution in my app
with only a 780k footprint.
2) it is a very thin layer on wx, so when something doesn't quite work,
I can immediately fall back onto wx, mixing and matching wax and wx
objects. it's just that the wax objects have more pythonic calling and
use properties
Sorry I don't know wax,
but I wonder "a GUI designer without screenshots",
is that Pythonic ;-)

cheers,
Stef
May 24 '07 #23

P: n/a
On 2007-05-24, Stef Mientki <S.**************@mailbox.kun.nlwrote:
>Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). In my
view, this is *exactly* what python needs, and its not being maintained
anymore as far as I can tell. What I like about it is:

1) it is small...I can include the entire wax distribution in
my app with only a 780k footprint.

2) it is a very thin layer on wx, so when something doesn't quite work,
I can immediately fall back onto wx, mixing and matching wax and wx
objects. it's just that the wax objects have more pythonic calling and
use properties

Sorry I don't know wax, but I wonder "a GUI designer without
screenshots", is that Pythonic ;-)
Uh, wha?

Who are you quoting about the screenshots?

Wax isn't a "GUI designer", and I'm a bit lost as to what
screenshots have to do with the topic at hand.

--
Grant Edwards grante Yow! I'm changing the
at CHANNEL ... But all I get
visi.com is commercials for "RONCO
MIRACLE BAMBOO STEAMERS"!
May 24 '07 #24

P: n/a
Grant Edwards wrote:
On 2007-05-24, Stef Mientki <S.**************@mailbox.kun.nlwrote:
>>Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). In my
view, this is *exactly* what python needs, and its not being maintained
anymore as far as I can tell. What I like about it is:

1) it is small...I can include the entire wax distribution in
my app with only a 780k footprint.

2) it is a very thin layer on wx, so when something doesn't quite work,
I can immediately fall back onto wx, mixing and matching wax and wx
objects. it's just that the wax objects have more pythonic calling and
use properties
Sorry I don't know wax, but I wonder "a GUI designer without
screenshots", is that Pythonic ;-)

Uh, wha?
quote original message:
"I am looking for a pythonic, professional looking GUI framework."
Who are you quoting about the screenshots?
Sorry, maybe I'm not Pythonic enough,
but talking about "GUI framework",
the first thing I want to see are screenshots.

cheers,
Stef Mientki
>
Wax isn't a "GUI designer", and I'm a bit lost as to what
screenshots have to do with the topic at hand.
May 24 '07 #25

P: n/a
On 2007-05-24, Stef Mientki <S.**************@mailbox.kun.nlwrote:
>>>Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). In my
view, this is *exactly* what python needs, and its not being maintained
anymore as far as I can tell. What I like about it is:

1) it is small...I can include the entire wax distribution in
my app with only a 780k footprint.

2) it is a very thin layer on wx, so when something doesn't quite work,
I can immediately fall back onto wx, mixing and matching wax and wx
objects. it's just that the wax objects have more pythonic calling and
use properties

Sorry I don't know wax, but I wonder "a GUI designer without
screenshots", is that Pythonic ;-)

Uh, wha?

quote original message:
"I am looking for a pythonic, professional looking GUI framework."
>Who are you quoting about the screenshots?
Sorry, maybe I'm not Pythonic enough, but talking about "GUI
framework", the first thing I want to see are screenshots.
0) While wax is a GUI framework, it is not a GUI designer, so I
was wondering who you were quoting when you wrote "a GUI
designer [...]".

1) Wax doesn't have any effect on the appearance of
applications, only on the appearance of the Python code used
to write the applications. So, screenshots are irrelevent.

If you want screenshots of what wxWidgets apps look like,
there are lots of them at wxWidgets.org. But, since
wxWidgets generally uses "native" widgets, wxWidget apps
look pretty much like any other app on the given platform.

--
Grant Edwards grante Yow! WHOA!! Ken and Barbie
at are having TOO MUCH FUN!!
visi.com It must be the NEGATIVE
IONS!!
May 24 '07 #26

P: n/a
>
>Sorry, maybe I'm not Pythonic enough, but talking about "GUI
framework", the first thing I want to see are screenshots.

0) While wax is a GUI framework, it is not a GUI designer, so I
was wondering who you were quoting when you wrote "a GUI
designer [...]".

1) Wax doesn't have any effect on the appearance of
applications, only on the appearance of the Python code used
to write the applications. So, screenshots are irrelevent.

If you want screenshots of what wxWidgets apps look like,
there are lots of them at wxWidgets.org. But, since
wxWidgets generally uses "native" widgets, wxWidget apps
look pretty much like any other app on the given platform.
Thanks for the information,
didn't know that.

cheers,
Stef Mientki
May 24 '07 #27

P: n/a
Do others think like me here?
Yes!! I agree completely: Wax is not only a fantastic idea, but a very
good start at an implementation of that idea.

--Matt Newville

May 25 '07 #28

P: n/a
Hi Paul, Peter, Uwe

Thank to the three of you for your
clear answers :)

May 25 '07 #29

P: n/a
Brian Blais <bb****@bryant.eduwrote in
news:ma***************************************@pyt hon.org:

[...]
Finally, consider wax (http://zephyrfalcon.org/labs/wax.html).
In my view, this is *exactly* what python needs, and its not
being maintained anymore as far as I can tell. What I like
about it is:

1) it is small...I can include the entire wax distribution in my
app with only a 780k
footprint.
2) it is a very thin layer on wx, so when something doesn't
quite work, I can immediately fall back onto wx, mixing and
matching wax and wx objects. it's just that the wax objects
have more pythonic calling and use properties
Is there a reason that the port of wxPython doesn't include wax,
or something similar? It would seem pretty straightforward,
when porting the wx to Python, to simply include such a wrapper.
I wish I were more clever, and had more time, to take over the
maintenance of wax because I think it is the most
straightforward, practical, and pythonic solution out there.
Do others think like me here?
I certainly do. Whether wax is the particular solution or not,
something very like it should be. Something like this was tried at
one time (Anygui) and the general consensus seems to be that it
doesn't work as an approach because the packages are too
different. I think that it's past time to revisit that conclusion.

It would be very useful to a user of the Language we call Python
to be able to write GUI code without regard to the back-end
package. If there were a standard Python GUI API (call it the PGA,
say) that be the target for app developers, they wouldn't have to
worry about the back end. The PGA would have to be flexible enough
to handle incompatibilities among the various approaches to
displaying widgets and text. In order for that to happen, some
kind of meeting of minds (among those who now deal with the murky
middle between gui packages and python) would have to take place.
A standard would have to be hammered out and then used.

The standard would have to allow for generic calls for tasks that
any reasonable GUI would have to handle. It would also have to
provide for system-specific calls for those things that each
package might require uniquely. The interface to the system-
specific stuff should itself be the same regardless of the back
end. What I mean by this is that, where wax's limitations are
overcome by dropping to wx directly, there should instead by a PGA
winsys() call that permits passing command strings, values, or
whatever in a dict-like object that would be permit the pga2wx
interface to create the specific calls it needs. When the back end
changes to Qt, the pga2Qt interface would make the translation
instead. The code from the app programmer should not have to
change, except maybe to add another item or items to the winsys
dict.

I also think there should something similar for an interface for
Python database access (PDBA). Anydb might not be the solution,
but it could be. It would take cleverness (which abounds in the
Python community), determination (which may not be in such
abundance) and project coordination for either of these projects
to come to fruition. A summer of code kind of thing would provide
a good initial push, and some sprints could move things along at a
good clip. Wax, anygui, and anydb seem to be acceptable starting
points, but the key thing is to get agreement from key players
(like the developers of wxPython, dabo, PythonCard, and so on) to
agree that this is a good direction to go in, and to try to work
out the requirements for a flexible PGA and PDBA. I'm sure that
the approach could produce usable results in short order, and then
attack the remaining limitations over time.

Do I think this is going to happen? No.

There are two overlapping things we call Python: the Language and
the Package. The Language comes from Guido and a few others, but
the Package comes from many sources, mostly volunteers. The GUI
interfaces come from many such sources, each with a different view
of what constitutes a good Pythonic interface. Having put a lot of
time and effort into getting their version up and running, they're
not about to change for some abstract reason, but nonetheless, I
do believe that the Language of Python should have a GUI API
defined, and that the Package of Python should accommodate to
that. Unless that happens, we'll see more of what we now see:
continual questions about what is the best GUI or the best
Database. Because once you start building an app, you commit to
the syntax of the package and you are no longer (in my view)
coding in Python, but in that subset that includes the GUI Package
of your choice.

--
rzed
May 26 '07 #30

P: n/a
On May 26, 2007, at 3:17 PM, rzed wrote:
If there were a standard Python GUI API (call it the PGA,
say) that be the target for app developers, they wouldn't have to
worry about the back end. The PGA would have to be flexible enough
to handle incompatibilities among the various approaches to
displaying widgets and text.
FWIW, this has been a design goal of Dabo from Day One. While we
currently wrap only wxPython, the ui module is not tied to it. We
have standardized on a syntax for control names, property names,
etc., that is independent of wxPython, and then is implemented in the
ui.uiwx module. Throughout Dabo, the only place where you will ever
see "import wx" is in the ui.uiwx module; when you write Dabo UI
code, you never need to import wx; instead, you write to the Dabo
uiapi. The same will be true when we get around to wrapping Tkinter,
Qt, etc.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
May 26 '07 #31

P: n/a
brad wrote:
Kevin Walzer wrote:
>2. wxPython is big, harder to learn than Tkinter, but looks good on
Mac, Windows, and *Nix. It will require users to install a lot of
extra stuff (or you'll have to bundle the extra stuff).

PyInstaller builds binaries beautifully from raw py source. No need to
bundle the wx stuff. I develop on Linux, build on Windows (with
PyInstaller) and it works great. The source runs on any platform, the
Windows binaries is neat for the point and click users.
Hi Brad:

This is my preferred method of development, but I am a newcomer to
python having lived in the C world for a long time.

Have you any experience with this development method using boa
constructor as the GUI builder?

Cheers,
mvdw

May 27 '07 #32

This discussion thread is closed

Replies have been disabled for this discussion.