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

What GUI toolkit looks the best?

P: n/a
I've been approached about writing a Windows app which will need a
really professional looking GUI. Forget TKinter, this has to actually
look good (real artists will be available to get the visual stuff
right). Assuming I write in Python, what's the best toolkit to use?
Some cost in implementation pain is tolerable if the finished
interface looks better as a result. It would be nice if the toolkit
runs on multiple platforms rather than being Windows-only.

I'm thinking Glade. Is that reasonable? I don't know squat about
Windows and haven't done much fancy GUI programming since the early X
days.

Thanks.
Jul 18 '05 #1
Share this Question
Share on Google+
53 Replies


P: n/a
Paul Rubin wrote:
I've been approached about writing a Windows app which will need a
really professional looking GUI. Forget TKinter, this has to actually
look good (real artists will be available to get the visual stuff
right). Assuming I write in Python, what's the best toolkit to use?
Some cost in implementation pain is tolerable if the finished
interface looks better as a result. It would be nice if the toolkit
runs on multiple platforms rather than being Windows-only.
Why forget Tkinter? I've seen Tkinter applications that look incredibly
fabulous. A lot depends on what you are trying to do. If you are
making a graphics-heavy application then Tkinter's canvas is pretty
sweet. I also think IDLE looks pretty good.
I'm thinking Glade. Is that reasonable? I don't know squat about
Windows and haven't done much fancy GUI programming since the early X
days.


Glade isn't a GUI, it is a GUI builder that uses GTK. In my experience,
GTK doesn't look quite right on windows boxes, especially the menus. Of
course I have the same basic view of Qt and Swing so know you know my
biases.

I tend to use Tkinter for canvas heavy applications and wxPython for
other stuff.

As for application building, here are my rankings
1 Emacs :)
2 Glade with libglade and Mitch Chapman's python libglade wrapper
3 BlackAdder with Qt
4 Boa-constructor (largish learning curve here I think)
5 wxGlade (layout isn't quite right)

So let me ask what kind of application are you building?

The bottom line is that I have seen great looking and really poor
looking apps in all of these gui's.

Here is my humble opinions in a nutshell (missing a lot here): wxPython
has a grid control to die for and many, many classes, good printer
support and looks like a native GTK app on Linux and a native app on
windows and macintosh. Qt is better for developing - it has a better
class structure and I tend not to have to look up docs as often and can
look really, really nice. Tkinter has a killer canvas and great
postscript output. GTK is really quite fast.

but don't take my word for this, why don't you see what you like the best?

http://www.wxpython.org/
http://www.gtk.org/
http://www.scriptics.com/
http://www.trolltech.com/

Speaking of Qt, does anyone want to make a python binding to jakasha?
http://www.jahshaka.com/

Brian

Jul 18 '05 #2

P: n/a
In article <od_Bb.500677$HS4.3867626@attbi_s01>,
Brian Kelley <bk*****@wi.mit.edu> wrote:
Paul Rubin wrote:
I've been approached about writing a Windows app which will need a
really professional looking GUI. Forget TKinter, this has to actually
look good (real artists will be available to get the visual stuff
right). Assuming I write in Python, what's the best toolkit to use?

Jul 18 '05 #3

P: n/a
cl****@lairds.com (Cameron Laird) writes:
Paul, I certainly can understand your dismissal of Tkinter
as it's commonly employed. Are you aware, though, of <URL:
http://tcl.projectforum.com/tk/Home > and <URL:
http://mini.net/tcl/10424 >? Tkinter might, in fact, best
meet your requirements.


No I'm not. I wrote one tkinter application just to try it out and
while it was nice for putting up a quick and dirty gui, it looked very
crude and the API was also quite inflexible. I clicked the first of
those two url's and it seems to be an in-progress discussion about how
to rework tcl to fix its limitations, but I don't want to rely on
something that's not yet already working. Thanks though.
Jul 18 '05 #4

P: n/a
P
Brian Kelley wrote:
Paul Rubin wrote:
I've been approached about writing a Windows app which will need a
really professional looking GUI. Forget TKinter, this has to actually
look good (real artists will be available to get the visual stuff
right). Assuming I write in Python, what's the best toolkit to use?
Some cost in implementation pain is tolerable if the finished
interface looks better as a result. It would be nice if the toolkit
runs on multiple platforms rather than being Windows-only.

Why forget Tkinter? I've seen Tkinter applications that look incredibly
fabulous. A lot depends on what you are trying to do. If you are
making a graphics-heavy application then Tkinter's canvas is pretty
sweet. I also think IDLE looks pretty good.
I'm thinking Glade. Is that reasonable? I don't know squat about
Windows and haven't done much fancy GUI programming since the early X
days.

Glade isn't a GUI, it is a GUI builder that uses GTK. In my experience,
GTK doesn't look quite right on windows boxes, especially the menus. Of
course I have the same basic view of Qt and Swing so know you know my
biases.

I tend to use Tkinter for canvas heavy applications and wxPython for
other stuff.

As for application building, here are my rankings
1 Emacs :)
2 Glade with libglade and Mitch Chapman's python libglade wrapper


Freaky. I've been using something VERY similar for the last 2 years.
An example of my libglade.py usage is at:
http://www.pixelbeat.org/talks/pygtk/mail/
Great minds think alike I suppose :-)

Pádraig.

Jul 18 '05 #5

P: n/a
In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
cl****@lairds.com (Cameron Laird) writes:
Paul, I certainly can understand your dismissal of Tkinter
as it's commonly employed. Are you aware, though, of <URL:
http://tcl.projectforum.com/tk/Home > and <URL:
http://mini.net/tcl/10424 >? Tkinter might, in fact, best
meet your requirements.


No I'm not. I wrote one tkinter application just to try it out and
while it was nice for putting up a quick and dirty gui, it looked very
crude and the API was also quite inflexible. I clicked the first of
those two url's and it seems to be an in-progress discussion about how
to rework tcl to fix its limitations, but I don't want to rely on
something that's not yet already working. Thanks though.


I persist at this out of concern that I'm not making things clear.
My stake, incidentally, is that you be successful, not that you
use any particular toolkit.

The second URL gives working code that you can use immediately in
your own applications to improve their appearance. This is not an
extension or anything at all difficult or constraining; it's just
a little prologue that refines the standard Tkinter appearance.
It *is* in use, right now, in several applications that must have
professional appearances. The first URL is about committee work,
essentially, that will fold the enhancements of the second URL
back into the standard Tk distribution.
--

Cameron Laird <cl****@phaseit.net>
Business: http://www.Phaseit.net
Jul 18 '05 #6

P: n/a
Brian Kelley <bk*****@wi.mit.edu> writes:
Why forget Tkinter? I've seen Tkinter applications that look
incredibly fabulous.
Got any url's for screen shots?
A lot depends on what you are trying to do. If
you are making a graphics-heavy application then Tkinter's canvas is
pretty sweet. I also think IDLE looks pretty good.
There will be some graphical icons and stuff like that which people
will click on, but no really heavy graphics or drawing tools in the
sense of a photo editor or anything like that.
Glade isn't a GUI, it is a GUI builder that uses GTK. In my
experience, GTK doesn't look quite right on windows boxes, especially
the menus. Of course I have the same basic view of Qt and Swing so
know you know my biases.
Oh ok, I understand a bit better now.
I tend to use Tkinter for canvas heavy applications and wxPython for
other stuff.
Is wxPython Windows specific? I guess it is, but can I port the
screen layouts to some comparable Linux toolkit or anything like that?
The screen shots for it do look really nice.
Here is my humble opinions in a nutshell (missing a lot here):
wxPython has a grid control to die for and many, many classes, good
printer support and looks like a native GTK app on Linux and a native
app on windows and macintosh.
Oh wow, yes I guess it's cross platform then. Hmm, what Micro$oft
tool do I need to build and run it? Is Visual C++ enough? I guess
I can get the client to pay for some stuff like that. Also, is there
a Glade-like drag and drop gui editor for it?
Qt is better for developing - it has a better class structure and I
tend not to have to look up docs as often and can look really,
really nice.
The KDE apps that I've seen look good but not really top notch. Maybe
more attention could improve them. They're certainly good enough for
practical use.
Tkinter has a killer canvas and great postscript output. GTK is
really quite fast.
I think I don't care about heavy duty graphics or more than rudimentary
printing.
but don't take my word for this, why don't you see what you like the best?

http://www.wxpython.org/
http://www.gtk.org/
http://www.scriptics.com/
http://www.trolltech.com/


I don't know what I can really tell from these without more experience
with them. In particular, which is the most solid and reliable across
a wide range of Windows versions (95, 98, ..., XP whatever)? That
matters too.

Thanks!

Paul
Jul 18 '05 #7

P: n/a
cl****@lairds.com (Cameron Laird) writes:
I persist at this out of concern that I'm not making things clear.
My stake, incidentally, is that you be successful, not that you
use any particular toolkit.

The second URL gives working code that you can use immediately in
your own applications to improve their appearance. This is not an
extension or anything at all difficult or constraining; it's just
a little prologue that refines the standard Tkinter appearance.
It *is* in use, right now, in several applications that must have
professional appearances. The first URL is about committee work,
essentially, that will fold the enhancements of the second URL
back into the standard Tk distribution.


Oh cool. The second screen shot on that page ("after") does look a
lot better than the "before" shot. I guess I'll look at it more
carefully, but Tkinter has always made me cringe because of its use of
tcl (why does it need its own extension language if Python itself is
supposed to be such a good one)? Thanks.
Jul 18 '05 #8

P: n/a
Paul Rubin wrote:
Here is my humble opinions in a nutshell (missing a lot here):
wxPython has a grid control to die for and many, many classes, good
printer support and looks like a native GTK app on Linux and a native
app on windows and macintosh.

Oh wow, yes I guess it's cross platform then. Hmm, what Micro$oft
tool do I need to build and run it? Is Visual C++ enough? I guess
I can get the client to pay for some stuff like that. Also, is there
a Glade-like drag and drop gui editor for it?


None. Just download the wxpython binaries and away you go. If you want
to build from scratch Visual C++ is enough. wxGlade is a good designer
although it does have some warts. wxDesigner is good as well, although
not free.
http://www.wxpython.org/

wxGlade
http://wxglade.sourceforge.net/

wxDesigner
http://www.roebling.de/

And join the wxpython mailing list. You'll be glad that you did.
Brian

Jul 18 '05 #9

P: n/a
I have a lot of experience with both wxPython and Tkinter. I would urge
caution regarding any quick judgments. All cross-platform toolkits have
significant bugs and design flaws.

My experience is that Tkinter is the "least bad" and more flexible.
wxPython (of course) inherits all the _many_ bugs in wxWindows. It's not
clear that wxWindows really actually works. Whenever I use
wxPython/wxWindows I find more bugs in a week than I have found in 3+ years
with Tk/Tkinter. YMMV. The (admittedly very cool) wxPython demo regularly
segfaults on Windows. Sheesh.

The main point is that some real experimentation (and risk!) is going to be
required for any significant project. You may as well budget some time for
frustration: it _is_ going to be there.

Just one example of what you might expect. My app uses a Text widget in
many non-trivial ways. Both Tkinter/Tk and wxPython/wxWindows have
seemingly minor, but actually _major_ problems with Text widgets.

Tk "helpfully" adds a newline at the end of text widgets in various
situations, which leads to no end of complications in my app. I wish Tk
would just _buzz off_ and not mess with my data. But noooooo.

The wxWindows Text widget, OTOH, uses an absolutely brain-dead api that
exposes platform-specific line endings. The complications become truly
horrendous for serious work: there is no proper model behind Text offsets.

Actually, both Tkinter and wxPython totally suck regarding offsets into text
widgets. One would like integer offset in the text widget to be _identical
in all respects_ with the integer offset into the Python strings that one
passes to and receives from these widgets. But nooooooo... I call this the
"cursed offset problem", which is really a special case of the "cursed
newline problem" :-)

In short, any cross-platform gui is going to cause you unexpected problems.
I'm not saying "don't use these tools". I am saying: "be prepared for nasty
surprises".

Edward

P.S. The idea that Tk is going to be "revitalized" any time soon is a
yawner, IMO. Wake me up when it happens.

EKR
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #10

P: n/a
In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
Jul 18 '05 #11

P: n/a
In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
Brian Kelley <bk*****@wi.mit.edu> writes:
Why forget Tkinter? I've seen Tkinter applications that look
incredibly fabulous.


Got any url's for screen shots?

Jul 18 '05 #12

P: n/a

"Paul Rubin" <http://ph****@NOSPAM.invalid> wrote in message
news:7x************@ruckus.brouhaha.com...
cl****@lairds.com (Cameron Laird) writes:
I persist at this out of concern that I'm not making things clear.
My stake, incidentally, is that you be successful, not that you
use any particular toolkit.

The second URL gives working code that you can use immediately in
your own applications to improve their appearance. This is not an
extension or anything at all difficult or constraining; it's just
a little prologue that refines the standard Tkinter appearance.
It *is* in use, right now, in several applications that must have
professional appearances. The first URL is about committee work,
essentially, that will fold the enhancements of the second URL
back into the standard Tk distribution.


Oh cool. The second screen shot on that page ("after") does look a
lot better than the "before" shot. I guess I'll look at it more
carefully, but Tkinter has always made me cringe because of its use of
tcl (why does it need its own extension language if Python itself is
supposed to be such a good one)? Thanks.


And that is what is called a "real good question." I believe that
you're supposed to be able to use the Tk libraries without using
TCL, but the people that wrote Tkinter weren't able to make it
work. I don't, however, know this for a fact, it's just something
that's bouncing around the old synapses...

John Roth
Jul 18 '05 #13

P: n/a
In article <vt************@news.supernews.com>,
John Roth <ne********@jhrothjr.com> wrote:
Jul 18 '05 #14

P: n/a
Edward K. Ream wrote:
Tk "helpfully" adds a newline at the end of text widgets in various
situations, which leads to no end of complications in my app. I wish Tk
would just _buzz off_ and not mess with my data. But noooooo.


that's why you should design your own leo widget:

http://effbot.org/zone/wck.htm

half-serious-ly yrs /F


Jul 18 '05 #15

P: n/a
John Roth wrote:
And that is what is called a "real good question." I believe that
you're supposed to be able to use the Tk libraries without using
TCL, but the people that wrote Tkinter weren't able to make it
work.


Tk comes with lots of configuration code and widget bindings
implemented in Tcl.

Tk also uses many pieces of the Tcl C library.

both parts can surely be replaced; someone just has to do it
(or pay for it).

</F>


Jul 18 '05 #16

P: n/a
In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
Jul 18 '05 #17

P: n/a
Paul Rubin wrote:
I've been approached about writing a Windows app which will need a
really professional looking GUI. Forget TKinter, this has to actually
look good (real artists will be available to get the visual stuff
right). Assuming I write in Python, what's the best toolkit to use?
Some cost in implementation pain is tolerable if the finished
interface looks better as a result. It would be nice if the toolkit
runs on multiple platforms rather than being Windows-only.

I'm thinking Glade. Is that reasonable? I don't know squat about
Windows and haven't done much fancy GUI programming since the early X
days.

Thanks.


What's wrong with Jython? I haven't used it myself, but have always wondered
why it's not mentioned when different Python GUI:s are discussed.

Carl
Jul 18 '05 #18

P: n/a
Cameron Laird wrote:
Guido certainly has the ability to do a low-level binding
to Tk (and I know someone did, on an experimental basis,
in the mid-'90s--was that he?)


david ascher, based on brian warkentine's Rivet project. you can
find traces of that project here (search for Trinket):

http://py.vaults.ca/parnassus/apyllo...8364.200301646
http://archive.dstc.edu.au/python/py....html#Graphics

(but don't expect the links on those pages to work)

</F>


Jul 18 '05 #19

P: n/a
Edward wrote:
I have a lot of experience with both wxPython and Tkinter. I would urge
caution regarding any quick judgments. All cross-platform toolkits have
significant bugs and design flaws.

My experience is that Tkinter is the "least bad" and more flexible.
wxPython (of course) inherits all the _many_ bugs in wxWindows.
It's not clear that wxWindows really actually works.


Isn't that last sentence a bit overly FUD-ish? Whether or not wxWindows is
better or worse than Tkinter is beside the point - many successful applications
are built on top of wxWindows and wxPython, so it's quite clear that it does
actually work.

-Dave
Jul 18 '05 #20

P: n/a
I'm working on a cross platform app which has a standard GUI front end
for administration and a kiosk front end for user usage. I'm using
wxWindows for the standard GUI and it does port between Windows and
Linux without a problem. The only significant difference I've seen is
that MDI applications in Linux don't look like the do in Windows.
Each child window shows up maximized in the parent window and there
are tabs across the top to switch between children. This just maybe
the default format and can be changed, but I haven't looked into it
yet.

For the kiosk I'm using PyGame which ports between Windows and Linux
just as well.

Andrew Barilla
http://www.exit66.com/
Jul 18 '05 #21

P: n/a
Edward K. Ream wrote:
I have a lot of experience with both wxPython and Tkinter. I would urge
caution regarding any quick judgments. All cross-platform toolkits have
significant bugs and design flaws.

My experience is that Tkinter is the "least bad" and more flexible.
wxPython (of course) inherits all the _many_ bugs in wxWindows. It's not
clear that wxWindows really actually works. Whenever I use
wxPython/wxWindows I find more bugs in a week than I have found in 3+ years
with Tk/Tkinter. YMMV. The (admittedly very cool) wxPython demo regularly
segfaults on Windows. Sheesh.
That's very interesting. I've never had the wxPython demos segfault on
windows, and I use it regularly (2 years) to examine various widgets. I
wonder if your setup or mine is the "special case" :)
The main point is that some real experimentation (and risk!) is going to be
required for any significant project. You may as well budget some time for
frustration: it _is_ going to be there.
Absolutely. The main attraction for me was wxWindows grid widget. I
use it to browser databases with 1,000,000+ entries.
Just one example of what you might expect. My app uses a Text widget in
many non-trivial ways. Both Tkinter/Tk and wxPython/wxWindows have
seemingly minor, but actually _major_ problems with Text widgets.


I hate wxPython's text widget for most of the reasons you described.
Plus, since we are using python, why isn't there a .write(...) method
for these widgets? Why can't I use a text widget like:

sys.stdout = TextCtrl(parent)

I had to make a wrapper around the text widget to make it behave like a
StringIO() class. It internally did all the necessary conversions to
the strings, but now I can use

widget.write()
widget.read()
widget.readlines()
widget.seek()

for line in widget:
pass

And the bastardication
print >> widget, file.read()

as if it were a real file object.

The interface to formatted text was a pain though. I still don't have a
good way of greating formatting except to say that it is in parallel
with the text stream.

Brian
Jul 18 '05 #22

P: n/a
Cameron Laird wrote:
I want to say a few words about portability and comparisons.

I'm very reluctant to advise "see what you like the best" in regard to
GUI toolkits
<URL: http://www.informit.com/content/inde...2F70A0695E0%7D >
the way I do for high-level languages. We all know it's entirely
realistic to counsel a newcomer, "Give yourself an hour, and you can
download and install Python (or Perl, or Ruby, or ...) and try it out
for yourself. You'll get a good first impression of how the language
operates."
That's not quite what I meant. The first step (for me) is finding out
what the toolkit supports. For example, tcl/Tk doesn't have a good grid
widget out of the box so for my project it was a non-starter which left
Qt, wxPython and GTK+
<URL: http://www.scriptics.com/ > isn't the URL I recommend; Scriptics
stopped doing business under that name three and a half years ago. <URL:
http://wiki.tcl.tk/tk > is a safe choice.


I would recommend http://www.tcl.tk/ actually which points to the same
place as http://www.scriptics.com/

Brian

Jul 18 '05 #23

P: n/a
> > My experience is that Tkinter is the "least bad" and more flexible.
wxPython (of course) inherits all the _many_ bugs in wxWindows.
It's not clear that wxWindows really actually works.


Isn't that last sentence a bit overly FUD-ish?


Umm. Maybe you are right.

My main point, and I think it is important, is that wxWindows seems
significantly flakier than Tk. Much more than Tk, the wxWindows experience
is "design once, debug everywhere".

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #24

P: n/a
> that's why you should design your own leo widget:

http://effbot.org/zone/wck.htm

half-serious-ly yrs /F


Thanks for this link. I'll look into it.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #25

P: n/a
Brian Kelley wrote:

I hate wxPython's text widget for most of the reasons you described.
Plus, since we are using python, why isn't there a .write(...) method
for these widgets? Why can't I use a text widget like:

sys.stdout = TextCtrl(parent)

I had to make a wrapper around the text widget to make it behave like a
StringIO() class. It internally did all the necessary conversions to
the strings, but now I can use ...


Probably the reason the text widget doesn't already do those things is
that nobody has taken the time to make it happen *and* release the changes
back to the project. Is Robin Dunn supposed to think of and write all
these things himself, just for your benefit?

-Peter
Jul 18 '05 #26

P: n/a
Peter Hansen wrote:
Probably the reason the text widget doesn't already do those things is
that nobody has taken the time to make it happen *and* release the changes
back to the project. Is Robin Dunn supposed to think of and write all
these things himself, just for your benefit?


That's a bit rough considering I give back quite a bit to the wxPython
community. Most of the useful things that I have written I have given
back to wxPython. A short resume includes PyGTK/Glade tutorial and Dr.
Dobbs article, WizardTransitionPages, grid_MegaExample, etc. Some made
it into the distribution, some didn't.

I don't even know if this is a sane interface. When I said "why isn't
there a .write(...) method for these widgets? Why can't I use a text
widget like<a file stream>" that wasn't a specious Robin should do this
for me question. It really was more like, is this a way a text widget
should behave?

I also wan't just talking about wxPython, non-pythonic behavior exists
across the board wxPython/Tk/Qt/Gtk. Is it worth the effort to make a
text widget behave like a file stream, I'm not sure. I'm certainly not
going to force this down someone's throat, but when I'm happy with it
I'll release it.

Andrew Dalke wrote a good piece in the Dr. Dobb's 25th anniversary
article about the pythonification of C toolkits that I think is pretty
good reference for these types of discussions.

Brian

Jul 18 '05 #27

P: n/a
On Thu, Dec 11, 2003 at 06:46:49PM +0100, Carl wrote:
Paul Rubin wrote:
I've been approached about writing a Windows app which will need a
really professional looking GUI. Forget TKinter, this has to actually
look good (real artists will be available to get the visual stuff
right). Assuming I write in Python, what's the best toolkit to use?
Some cost in implementation pain is tolerable if the finished
interface looks better as a result. It would be nice if the toolkit
runs on multiple platforms rather than being Windows-only.

I'm thinking Glade. Is that reasonable? I don't know squat about
Windows and haven't done much fancy GUI programming since the early X
days.

Thanks.


What's wrong with Jython? I haven't used it myself, but have always wondered
why it's not mentioned when different Python GUI:s are discussed.


Jython + SWT is a pretty cool combination. SWT is a well-designed, high
performance portable toolkit using native widgets. Python is our favorite
language. If they could be married without Java it would be even better.

Oren

Jul 18 '05 #28

P: n/a
I have been using wxPython and it performs well ... You should also look
at Boa Constructor a GUI designer generates decent Python code,
integrated debugger is cool, shows local varraibles... for some uses I
find it better than winpython.
Paul Rubin wrote:
Brian Kelley <bk*****@wi.mit.edu> writes:
Why forget Tkinter? I've seen Tkinter applications that look
incredibly fabulous.

Got any url's for screen shots?

A lot depends on what you are trying to do. If
you are making a graphics-heavy application then Tkinter's canvas is
pretty sweet. I also think IDLE looks pretty good.

There will be some graphical icons and stuff like that which people
will click on, but no really heavy graphics or drawing tools in the
sense of a photo editor or anything like that.

Glade isn't a GUI, it is a GUI builder that uses GTK. In my
experience, GTK doesn't look quite right on windows boxes, especially
the menus. Of course I have the same basic view of Qt and Swing so
know you know my biases.

Oh ok, I understand a bit better now.

I tend to use Tkinter for canvas heavy applications and wxPython for
other stuff.

Is wxPython Windows specific? I guess it is, but can I port the
screen layouts to some comparable Linux toolkit or anything like that?
The screen shots for it do look really nice.

Here is my humble opinions in a nutshell (missing a lot here):
wxPython has a grid control to die for and many, many classes, good
printer support and looks like a native GTK app on Linux and a native
app on windows and macintosh.

Oh wow, yes I guess it's cross platform then. Hmm, what Micro$oft
tool do I need to build and run it? Is Visual C++ enough? I guess
I can get the client to pay for some stuff like that. Also, is there
a Glade-like drag and drop gui editor for it?

Qt is better for developing - it has a better class structure and I
tend not to have to look up docs as often and can look really,
really nice.

The KDE apps that I've seen look good but not really top notch. Maybe
more attention could improve them. They're certainly good enough for
practical use.

Tkinter has a killer canvas and great postscript output. GTK is
really quite fast.

I think I don't care about heavy duty graphics or more than rudimentary
printing.

but don't take my word for this, why don't you see what you like the best?

http://www.wxpython.org/
http://www.gtk.org/
http://www.scriptics.com/
http://www.trolltech.com/

I don't know what I can really tell from these without more experience
with them. In particular, which is the most solid and reliable across
a wide range of Windows versions (95, 98, ..., XP whatever)? That
matters too.

Thanks!

Paul


Jul 18 '05 #29

P: n/a
I have been using wxPython and it performs well ... You should also look
at Boa Constructor a GUI designer generates decent Python code,
integrated debugger is cool, shows local varraibles... for some uses I
find it better than winpython.
Paul Rubin wrote:
Brian Kelley <bk*****@wi.mit.edu> writes:
Why forget Tkinter? I've seen Tkinter applications that look
incredibly fabulous.

Got any url's for screen shots?

A lot depends on what you are trying to do. If
you are making a graphics-heavy application then Tkinter's canvas is
pretty sweet. I also think IDLE looks pretty good.

There will be some graphical icons and stuff like that which people
will click on, but no really heavy graphics or drawing tools in the
sense of a photo editor or anything like that.

Glade isn't a GUI, it is a GUI builder that uses GTK. In my
experience, GTK doesn't look quite right on windows boxes, especially
the menus. Of course I have the same basic view of Qt and Swing so
know you know my biases.

Oh ok, I understand a bit better now.

I tend to use Tkinter for canvas heavy applications and wxPython for
other stuff.

Is wxPython Windows specific? I guess it is, but can I port the
screen layouts to some comparable Linux toolkit or anything like that?
The screen shots for it do look really nice.

Here is my humble opinions in a nutshell (missing a lot here):
wxPython has a grid control to die for and many, many classes, good
printer support and looks like a native GTK app on Linux and a native
app on windows and macintosh.

Oh wow, yes I guess it's cross platform then. Hmm, what Micro$oft
tool do I need to build and run it? Is Visual C++ enough? I guess
I can get the client to pay for some stuff like that. Also, is there
a Glade-like drag and drop gui editor for it?

Qt is better for developing - it has a better class structure and I
tend not to have to look up docs as often and can look really,
really nice.

The KDE apps that I've seen look good but not really top notch. Maybe
more attention could improve them. They're certainly good enough for
practical use.

Tkinter has a killer canvas and great postscript output. GTK is
really quite fast.

I think I don't care about heavy duty graphics or more than rudimentary
printing.

but don't take my word for this, why don't you see what you like the best?

http://www.wxpython.org/
http://www.gtk.org/
http://www.scriptics.com/
http://www.trolltech.com/

I don't know what I can really tell from these without more experience
with them. In particular, which is the most solid and reliable across
a wide range of Windows versions (95, 98, ..., XP whatever)? That
matters too.

Thanks!

Paul


Jul 18 '05 #30

P: n/a
I have been using wxPython and it performs well ... You should also look
at Boa Constructor a GUI designer generates decent Python code,
integrated debugger is cool, shows local varraibles... for some uses I
find it better than winpython.
Paul Rubin wrote:
Brian Kelley <bk*****@wi.mit.edu> writes:
Why forget Tkinter? I've seen Tkinter applications that look
incredibly fabulous.

Got any url's for screen shots?

A lot depends on what you are trying to do. If
you are making a graphics-heavy application then Tkinter's canvas is
pretty sweet. I also think IDLE looks pretty good.

There will be some graphical icons and stuff like that which people
will click on, but no really heavy graphics or drawing tools in the
sense of a photo editor or anything like that.

Glade isn't a GUI, it is a GUI builder that uses GTK. In my
experience, GTK doesn't look quite right on windows boxes, especially
the menus. Of course I have the same basic view of Qt and Swing so
know you know my biases.

Oh ok, I understand a bit better now.

I tend to use Tkinter for canvas heavy applications and wxPython for
other stuff.

Is wxPython Windows specific? I guess it is, but can I port the
screen layouts to some comparable Linux toolkit or anything like that?
The screen shots for it do look really nice.

Here is my humble opinions in a nutshell (missing a lot here):
wxPython has a grid control to die for and many, many classes, good
printer support and looks like a native GTK app on Linux and a native
app on windows and macintosh.

Oh wow, yes I guess it's cross platform then. Hmm, what Micro$oft
tool do I need to build and run it? Is Visual C++ enough? I guess
I can get the client to pay for some stuff like that. Also, is there
a Glade-like drag and drop gui editor for it?

Qt is better for developing - it has a better class structure and I
tend not to have to look up docs as often and can look really,
really nice.

The KDE apps that I've seen look good but not really top notch. Maybe
more attention could improve them. They're certainly good enough for
practical use.

Tkinter has a killer canvas and great postscript output. GTK is
really quite fast.

I think I don't care about heavy duty graphics or more than rudimentary
printing.

but don't take my word for this, why don't you see what you like the best?

http://www.wxpython.org/
http://www.gtk.org/
http://www.scriptics.com/
http://www.trolltech.com/

I don't know what I can really tell from these without more experience
with them. In particular, which is the most solid and reliable across
a wide range of Windows versions (95, 98, ..., XP whatever)? That
matters too.

Thanks!

Paul


Jul 18 '05 #31

P: n/a
> > What's wrong with Jython? I haven't used it myself, but have always
wondered
why it's not mentioned when different Python GUI:s are discussed.


Jython + SWT is a pretty cool combination. SWT is a well-designed, high
performance portable toolkit using native widgets. Python is our favorite
language. If they could be married without Java it would be even better.

Oren


I use jython + java swing for a large, ongoing contract. The plugable look
& feels allow you to add some nice UI skins to your application with 1 or
two lines of code - I use the 'Alloy' look and feel from incors
(http://www.incors.com/lookandfeel/index.php) - though it does cost.

One nice thing with swing (and forgive me if SWT does this, I am not
familiar with it) is that most widgets will allow html to be used within the
text for simple markup - allowing for easy display of formatted paragraphs,
bold text, etc. It also comes in handy when you want to throw an image onto
a label widget.

You can use sun's one-studio (netbeans) to design your gui, and then use the
classes it generates within your jython code fairly easily. I find myself
creating quick and dirty forms all the time by hand in jython (its just so
fast - so few lines of code), but I am convert a lot of them to actual java
classes later for increased speed.

I'm off to look into SWT...

~Jon Franz
NeuroKode Labs, LLC
513.260.5788
Jul 18 '05 #32

P: n/a
Paul Rubin wrote:
Brian Kelley <bk*****@wi.mit.edu> writes:
(snip)
I tend to use Tkinter for canvas heavy applications and wxPython for
other stuff.

Is wxPython Windows specific? I guess it is,


You lose.
but can I port the
screen layouts to some comparable Linux toolkit or anything like that?
The screen shots for it do look really nice.

Here is my humble opinions in a nutshell (missing a lot here):
wxPython has a grid control to die for and many, many classes, good
printer support and looks like a native GTK app on Linux and a native
app on windows and macintosh.

Perhaps because it uses 'native' (ie : Gtk+, Motif, Windows native or
MacOS X native) toolkits ?-)

Oh wow, yes I guess it's cross platform then.
You win !-)
Hmm, what Micro$oft
tool do I need to build and run it? Is Visual C++ enough? Yeps. Or bcc, or mingw, or...
I guess
I can get the client to pay
Why ? It's free (as in free beer and free speech)
for some stuff like that. Also, is there
a Glade-like drag and drop gui editor for it?
wxGlade.

And also boa, PythonCard...
I don't know what I can really tell from these without more experience
with them. In particular, which is the most solid and reliable across
a wide range of Windows versions (95, 98, ..., XP whatever)? That
matters too.


Can't tell you about that (I used wxWindows on win98 and NT4ws and
Linux/Gtk+, without any trouble but as in any non-trivial code, there
are bugs... no more no less than in MFC or Borland toolkits)

Bruno

Jul 18 '05 #33

P: n/a
Bruno Desthuilliers <bd***********@removeme.free.fr> writes:
I guess
I can get the client to pay


Why ? It's free (as in free beer and free speech)


I mean for the build tools (Visual C++ or whatever). I can't really
use the WxWindows source code without a way to compile it. I'm getting
discouraged to hear that WxWindows itself has numerous bugs though.
Jul 18 '05 #34

P: n/a
Paul Rubin wrote:
Bruno Desthuilliers <bd***********@removeme.free.fr> writes:
I guess
I can get the client to pay


Why ? It's free (as in free beer and free speech)

I mean for the build tools (Visual C++ or whatever). I can't really
use the WxWindows source code without a way to compile it. I'm getting
discouraged to hear that WxWindows itself has numerous bugs though.


I think that these might be a bit overblown. I have released some
medium-scale academic research packages to beta-testers using wxPython
and have had no problems so far. There are about 150 installations so
far at ten different sites. I have had more problems with different
installation styles of microsoft excel than I have had with supporting
wxPython bugs. Your mileage may vary however, and I certainly don't use
all the widgets (read textctrl).

The largest hurdles are with differences between windows/linux and mac,
but I have experienced similar differences with Tkinter. Not for the
GUI itself but with dealing with the clipboard etc. You may get
different behavior on different platforms so debugging on those
platforms is a must. I've been luck so far and the documentation is
pretty good.

I have seen wxPython crashes during development but they all have to do
with errors in the constructors of subclassed widgets. If you raise an
exception in a constructor before calling the baseclass' __init__
function wxPython get's very unhappy and dies miserably taking
everything down. Two solutions/workarounds are

1) always call the subclassed constructor first
2) use a try...except block where call the base __init__ with default
arguments and raise an event that will close down the app nicely.

I haven't been able to figure out a way to do this automatically on
constructor errors yet. If I could I would submit it to wxPython.

If you are running on windows or redhat linux, you won't need to build
wxPython/wxWindows, you can just download and install the binaries.

If you want to build wxPython/wxWindows by yourself you will just need
Visual C++.

Brian

Jul 18 '05 #35

P: n/a
Paul Rubin wrote:
Bruno Desthuilliers <bd***********@removeme.free.fr> writes:
I guess
I can get the client to pay
Why ? It's free (as in free beer and free speech)

I mean for the build tools (Visual C++ or whatever). I can't really
use the WxWindows source code without a way to compile it.


You can build wxWindows with the free (as in free beer) Borland's bcc5.x
compiler, or with free (as in free beer and free speech) compilers like
Minwg's gcc.
I'm getting
discouraged to hear that WxWindows itself has numerous bugs though.


I did not used wxWindows intensively, but I never had a crash in three
years. I couldn't say the same about apps written with MS VisualBasic or
like :(.

Every non-trivial code does have bugs. Python has bugs, gcc has bugs,
not talking about msvc. I think that some posts in this thread were a
bit of a special case (FUD or bad experience, I can't tell...)

wxWindows has 11 years of existence, and bindings exists for more and
more languages (Javascript, Python, Perl, haskell, lua, Ruby, Eiffel,
and even Java and C#...). I don't think so many developers would spend
personnal time writing bindings to a 'that much buggy' toolkit !-)

Bruno

Jul 18 '05 #36

P: n/a
Brian Kelley wrote:
I hate wxPython's text widget for most of the reasons you described.
Plus, since we are using python, why isn't there a .write(...) method
for these widgets? Why can't I use a text widget like:

sys.stdout = TextCtrl(parent)
The Wax TextBox (which is based on wxTextCtrl) has had a write() method for a
while, for exactly this purpose.

(http://zephyrfalcon.org/labs/, look for Wax)
I had to make a wrapper around the text widget to make it behave like a
StringIO() class. It internally did all the necessary conversions to
the strings, but now I can use

widget.write()
widget.read()
widget.readlines()
widget.seek()

for line in widget:
pass


The TextBox control doesn't have the other methods, mostly because I've never
felt the need to do these things. :-) The iterator idea is interesting, though.

--
Hans (ha**@zephyrfalcon.org)
http://zephyrfalcon.org/

Jul 18 '05 #37

P: n/a
Paul Rubin wrote:
I've been approached about writing a Windows app which will need a
really professional looking GUI. Forget TKinter, this has to actually
look good (real artists will be available to get the visual stuff
right). Assuming I write in Python, what's the best toolkit to use?


Wow! What a response this question has generated. I would have to throw
my hat into the PyGTK ring, for both objective and subjective reasons.

I think GTK looks great on Windows and my PyGTK apps have been very
stable and responsive. On a more subjective note, for me, the PyGTK API
just fits my brain better than the wxPython one does. It just feels
more seemless to me and things make more sense when I look at them.
Like I said, pretty subjective.

Maybe you could write a small sample app using both PyGTK and wxPython
and see which one feels right to you.

Jamey

Jul 18 '05 #38

P: n/a
> > > It's not clear that wxWindows really actually works.
Isn't that last sentence a bit overly FUD-ish?
Umm. Maybe you are right.


After sleeping on this question, I think not :-) True, my choice of words
wasn't the best, but since you brought up FUD, I'm willing to discuss my
fears, uncertainties and doubts about wxWindows.

Motivation & experience

The typical FUD campaign is driven by ulterior motives. I have no such
motives--I am not the author of a product that competes with wxPython or
Tkinter: I am a somewhat frustrated user of both products. Leo is about to
come a rare beast: a gui-agnostic application. That is, Leo will soon be
able to support other gui toolkits besides tkinter. Indeed, an experimental
wxPython plugin already exists. This plugin replaces Leo's default tkinter
gui with a wxPython gui. My remarks are based on experiences with a failed
wxWindows project and the present wxPython plugin.

Psychological responses

In my case, I do have doubts that I can make wxPython projects as solid as
the equivalent Tkinter projects. Related feelings include fear and
uncertainty, and some others ;-) These feelings are real, and they are based
on substantial experience.

Objective responses

In my experience, it is a _fact_ that wxPython (really wxWindows) seems to
have many more bugs than Tkinter. It is a _rare_ bug that has no
workaround, so this fact does _not_ mean that it is impossible to produce
"working" apps with wxWindows/wxPython. What is probably _does_ mean is
that it will be more expensive to create a solid wxPython app than one would
hope. In my experience, the answer to the question "Why the hell hasn't
wxPython become the standard GUI for Python yet?" is: "wxWindows is buggy."

Conclusions

All my comments have been intended to alert people to the complexities and
difficulties in choosing one gui or another. I wish that Tkinter and
wxPython were better, and I think people should have their eyes open when
considering using these tools.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #39

P: n/a
Paul Rubin wrote:

Bruno Desthuilliers <bd***********@removeme.free.fr> writes:
I guess
I can get the client to pay


Why ? It's free (as in free beer and free speech)


I'm getting
discouraged to hear that WxWindows itself has numerous bugs though.


Paul, that's a load of FUD, as someone else said. While I'm sure
it's not bug-free, it does *not* in general crash as frequently
as Edward suggested. In fact, I'm pretty sure there are hundreds of
people using it successfully (and quietly) for every time it has crashed
for him. I'd suggest he investigate his own machine's stability rather
than pointing the figure solely at wxPython. From my own experience,
it has *never* crashed in that manner, including after using the demo
extensively (i.e. trying out effectively *all* the included demos),
except with one that involved some DirectX or OpenGL stuff that wasn't
installed on my machine.

We haven't used it for really large apps, but we have a half dozen
smaller apps that are in relatively frequent use and so far no bug
reports of mysterious crashes.

Please don't let one person's experience spoil you on the idea of
at least investigating wxPython for your own use.

-Peter
Jul 18 '05 #40

P: n/a
Brian Kelley wrote:

When I said "why isn't
there a .write(...) method for these widgets? Why can't I use a text
widget like<a file stream>" that wasn't a specious Robin should do this
for me question. It really was more like, is this a way a text widget
should behave?


That wasn't clear from the wording you used. Thanks for clarifying. :-)
It's a good question... I don't have the answer.

-Peter
Jul 18 '05 #41

P: n/a
> Please don't let one person's experience spoil you on the idea of
at least investigating wxPython for your own use.


Actually, I think we are in "virulent agreement". I have never suggested
writing off wxWindows/wxPython, as Leo's wxPython plugin shows. I merely
suggest due caution.

My experience isn't that wxWindows doesn't work at all, it is that it takes
a lot more work to make wxWindows work as I expect than with, say, Tkinter.
It's a cost/risk issue. I should have made that clearer. wxPython reduces
that cost difference substantially, and Python provides ways of end-running
problems that didn't exist when I was using C++.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #42

P: n/a
Edward wrote:
> It's not clear that wxWindows really actually works. Isn't that last sentence a bit overly FUD-ish?
Umm. Maybe you are right.


After sleeping on this question, I think not :-) True, my choice of words
wasn't the best, but since you brought up FUD, I'm willing to discuss my
fears, uncertainties and doubts about wxWindows.

Motivation & experience

The typical FUD campaign is driven by ulterior motives. I have no such
motives --I am not the author of a product that competes with wxPython or
Tkinter


Well, I'm not really interested in pressing the issue (I don't have ulterior
motives either ;-) ), but if not FUD, it was inaccurate in the _general sense_
as many applications are built upon wxWindows/wxPython and do not have
problems. I do not doubt that you've experienced problems with that framework;
but I do take issue with the implication that such an experience is the norm -
for example, the wxWindows site has quite a list of examples that use it, and
many of which are quite widely used and certainly not toy applications (AOL
Communicator, Audacity, etc.), so I'd say it _is_ clear that it "actually
works". I have a hard time understanding how wxWindows could be so flaky and
buggy and yet still enjoy such commercial and open source success - why aren't
the people who use it drowning in support calls/emails?
In my experience, it is a _fact_ that wxPython (really wxWindows) seems to
have many more bugs than Tkinter. It is a _rare_ bug that has no
workaround, so this fact does _not_ mean that it is impossible to produce
"working" apps with wxWindows/wxPython. What is probably _does_ mean is
that it will be more expensive to create a solid wxPython app than one would
hope. In my experience, the answer to the question "Why the hell hasn't
wxPython become the standard GUI for Python yet?" is: "wxWindows is buggy."


The good news is that the wxWindows and wxPython developers are pretty good
about fixing bugs, so there's a good chance that all the bugs you found and
reported to them have been fixed by now. ;-)

It was good talking to you. Congrats on your progress with Leo - pretty neat!
-Dave
Jul 18 '05 #43

P: n/a
On Fri, 12 Dec 2003 00:12:45 +0100, Bruno Desthuilliers wrote:
You can build wxWindows with the free (as in free beer) Borland's bcc5.x
compiler, or with free (as in free beer and free speech) compilers like
Minwg's gcc.


but not wxPython. You must use MSVC for compiling on Windows. However,
unless you have patches or extensions to compile, the precompiled version
should work just fine.

-Mark
Jul 18 '05 #44

P: n/a
Peter Hansen wrote:

Brian Kelley wrote:

When I said "why isn't
there a .write(...) method for these widgets? Why can't I use a text
widget like<a file stream>" that wasn't a specious Robin should do this
for me question. It really was more like, is this a way a text widget
should behave?


That wasn't clear from the wording you used. Thanks for clarifying. :-)
It's a good question... I don't have the answer.


And by the way, I do appreciate your efforts on KitViewer and such... apologies
for the slight.

-Peter
Jul 18 '05 #45

P: n/a
> if not FUD, it was inaccurate in the _general sense_
as many applications are built upon wxWindows/wxPython and do not have
problems.


Yeah, as I think about this more, I am tending to agree with you. Perhaps I
was just being too grumpy or pessimistic. I owe the wxWindows people an
apology. Consider it given.

For sure wxPython is pretty easy to use. Looking back, I was letting
earlier trauma color my thinking too much. Also, the wxSTC control might
well solve the problems with the plain wxText control...

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #46

P: n/a
Edward K. Ream <ed*******@charter.net> pisze:
My experience isn't that wxWindows doesn't work at all, it is that it takes
a lot more work to make wxWindows work as I expect than with, say, Tkinter.
It's a cost/risk issue. I should have made that clearer. wxPython reduces
that cost difference substantially, and Python provides ways of end-running
problems that didn't exist when I was using C++.


There are times, when Tkinter doesn't work at all, i.e. on
"second-half-of-world" terminals (non-ASCII/non-LATIN1). wxPython has no
problems there. Yes, I know, it's due to flaws in TCL/Tk, not in Tkinter
itself. But all Pythons ship with this flawed, broken, unusable Tk. And
don't even try to argue, that my customers can "build their own Tk with
bcc32 or OpenWatcom", they dont need to do anything more than install
wxPython from readily-available binary distribution.

NP: Sex Pistols - EMI

--
Jarek Zgoda
Unregistered Linux User #-1
http://www.zgoda.biz/ JID:zg***@chrome.pl http://zgoda.jogger.pl/
Jul 18 '05 #47

P: n/a
Mark Roach <mr*****@okmaybe.com> writes:
but not wxPython. You must use MSVC for compiling on Windows. However,
unless you have patches or extensions to compile, the precompiled version
should work just fine.


I've had enough experiences getting stuck in a project due to library
bugs or incorrect documentation that I really want to be able to run
the complete program (including libraries) under a debugger. That
sounds like I need MSVC. However, I guess that's tolerable since this
would be a paid project that needs to run on Windows. Sure, using
MSVC is distasteful, but so is using Windows in the first place, so if
I'm willing to use Windows at all, having to use MSVC as well is just
more of the same. Thanks.
Jul 18 '05 #48

P: n/a
In article <br**********@nemesis.news.tpi.pl>,
Jarek Zgoda <jz****@gazeta.usun.pl> wrote:
Jul 18 '05 #49

P: n/a
"Edward K. Ream" <ed*******@charter.net> schreef:
The (admittedly very cool) wxPython demo regularly
segfaults on Windows. Sheesh.


Were you using the Unicode build on Win95/98/ME?

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Jul 18 '05 #50

53 Replies

This discussion thread is closed

Replies have been disabled for this discussion.