What GUI toolkit looks the best?
Paul Rubin
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.
Brian Kelley
> 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
Cameron Laird
Brian Kelley <bke...@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?
.
.
>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
.
.
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.
--
Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net
Paul Rubin
> 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.
P...@draigbrady.com
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.
Cameron Laird
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.
Paul Rubin
> 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
Paul Rubin
> 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.
Brian Kelley
>
>>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.
wxGlade
http://wxglade.sourceforge.net/
wxDesigner
http://www.roebling.de/
And join the wxpython mailing list. You'll be glad that you did.
Brian
Edward K. Ream
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: edre...@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Cameron Laird
Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
.
.
>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.
Division of labor. Python is not petty or exclusive;
Python welcomes all things beneficial.
Cameron Laird
Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>> Why forget Tkinter? I've seen Tkinter applications that look
>> incredibly fabulous.
>
>Got any url's for screen shots?
.
.
<URL: http://wiki.tcl.tk/Good+Looking+Tk > is
an easy almost-answer. Tkinter-based ones will
take just a bit longer ...
John Roth
"Paul Rubin" <http://phr...@NOSPAM.invalid> wrote in message
news:7x65gn1...@ruckus.brouhaha.com...
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
Cameron Laird
John Roth <newsg...@jhrothjr.com> 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. I don't, however, know this for a fact, it's just something
>that's bouncing around the old synapses...
.
.
It's a choice. Perlites tried both ways, and largely
settled on Perl/Tk, which uses the Tcl-free C bindings.
It's much, MUCH easier maintaining a Tcl-coded applica-
tion, though, so Tkinter pops out a couple of hours
after a new Tk release, while Perl/Tk takes months of
calendar time. 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?); he
chooses to invest his time elsewhere.
There's actually more to it than that. These are the
right highlights, though, to the best of my knowledge.
Fredrik Lundh
> 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
Fredrik Lundh
> 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>
Cameron Laird
Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
.
.
.
>> 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.
.
.
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/index.asp?product_id=%7BCC8D8943-BC39-45B9-B455-2B608FA03C48%7D&session_id=%7B65C794A2-51C8-4FD3-8BD8-22F70A0695E0%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."
It's not the same, though, for C# vs. Java, or the GUI toolkits. There's
a considerably greater start-up cost involved in exercising them meaning-
fully. You really are best off with advice from a live person whom you
trust.
You probably must "see what you like the best" ultimately, because your
requirements are unlikely to duplicate those of your potential mentors.
We can, however, help focus your search--and I'm posting because I think
we should.
<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.
You ask, "which is the most solid ...?" for Windows. I *am* a fan of
Tkinter, and the answer to this question explains much of that.
Tkinter's portability story is at least as good as that of any of the
alternative toolkits, and, I argue, better than all but Qt (depending
on your sentiments about licensing). You're likely to get quite a
range of testimony in this regard; I certainly know GTK+ experts who
seem quite productive under Windows. In my experience, though, Tkinter
just *thumps* all the others, in regard to the robustness of its
portability.
How's it happen you're not talking about Java (Jython, say)? In fact
I think it wouldn't be right for you; I'm surprised, though, not to hear
you mention it.
Carl
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
Fredrik Lundh
> 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.py/808292924.247038364.200301646
http://archive.dstc.edu.au/python/python/Contributed.html#Graphics
(but don't expect the links on those pages to work)
</F>
Dave Brueck
> 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
Andrew Barilla
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/
Brian Kelley
> 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
Brian Kelley
> 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/index.asp?product_id=%7BCC8D8943-BC39-45B9-B455-2B608FA03C48%7D&session_id=%7B65C794A2-51C8-4FD3-8BD8-22F70A0695E0%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
Edward K. Ream
> > 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
>
> http://effbot.org/zone/wck.htm
>
> half-serious-ly yrs /F
Thanks for this link. I'll look into it.
Edward
John Benson
Tkinter Programming" book; you just have to look in the second half of the
book for artsy and ray-traced interfaces.
Peter Hansen
>
> 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
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
Brian Kelley
> 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
Oren Tirosh
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
Max Slimmer
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.
Max Slimmer
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.
Max Slimmer
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.
Jon Franz
wondered
> > why it's not mentioned when different Python GUI:s are discussed.
>
> 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
Bruno Desthuilliers
>
>
>>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
Paul Rubin
I'm not at all concerned about artsy or ray-traced interfaces. I need
UI widgets that are responsive and look crisp and act like the native
widgets for the underlying OS.
Paul Rubin
> > 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.
Brian Kelley
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
Bruno Desthuilliers
> Bruno Desthuilliers <bdesth...@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
Hans Nowak
> 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.
Jamey Cribbs
> 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
Edward K. Ream
> > 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.
Peter Hansen
>
> Bruno Desthuilliers <bdesth...@removeme.free.fr> writes:
> > > I guess
> > > I can get the client to pay
> >
> > Why ? It's free (as in free beer and free speech)
>
> 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
Peter Hansen
>
> 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
Edward K. Ream
> 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++.
Dave Brueck
> > > > 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
> 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
Mark Roach
> 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
Peter Hansen
And by the way, I do appreciate your efforts on KitViewer and such... apologies
for the slight.
-Peter
Edward K. Ream
> 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...
Jarek Zgoda
> 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/
Paul Rubin
> 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.
Cameron Laird
Jarek Zgoda <jzg...@gazeta.usun.pl> wrote:
.
.
.
>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.
.
.
It surprises me that you write that. I regard Tcl as the
language which has gone the farthest in internationalization,
apart from Java, and the one which makes such delights as
<URL: http://wiki.tcl.tk/3145 > feasible.
Do you know what it is that's broken? There are several
people on both the Tk and Python sides who are eager to learn
of faults, so that they can fix them as soon as possible; I'll
be glad to help you direct your report so that it's resolved
without delay. I raised your comments with the head of Tcl
support at ActiveState; he replied, in part, "Tk was the first
of the open source cross-platform UI toolkits to have full
unicode support, end-to-end. There are no flaws in Tcl/Tk in
this regards, and AFAIK this works just fine in Tkinter as well"
[reproduced with permission].
I agree that wxPython is a fine toolkit. I think there's still
a place for Tkinter, and it sounds as though you have knowledge
about how to help it fit that place better.
--
Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net
JanC
> 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
Jarek Zgoda
>>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.
> .
> It surprises me that you write that. I regard Tcl as the
> language which has gone the farthest in internationalization,
> apart from Java, and the one which makes such delights as
> <URL: http://wiki.tcl.tk/3145 > feasible.
>
> Do you know what it is that's broken? There are several
> people on both the Tk and Python sides who are eager to learn
> of faults, so that they can fix them as soon as possible; I'll
> be glad to help you direct your report so that it's resolved
> without delay. I raised your comments with the head of Tcl
> support at ActiveState; he replied, in part, "Tk was the first
> of the open source cross-platform UI toolkits to have full
> unicode support, end-to-end. There are no flaws in Tcl/Tk in
> this regards, and AFAIK this works just fine in Tkinter as well"
> [reproduced with permission].
No, I don't mean "broken unicode support", the problem lies in Python
interfacing with Tk, when Python's unicode means something different,
than Tk unicode.
I'll try to produce some examples of erroneous behavior on both X11 and
Windows NT and file bug report on SF.
Paul Rubin
> > It surprises me that you write that. I regard Tcl as the
> > language which has gone the farthest in internationalization,
>
> interfacing with Tk, when Python's unicode means something different,
> than Tk unicode.
I thought python supported only 16 bit Unicode so it can't fully
interoperate with a 32-bit implementation.
Jarek Zgoda
>> Do you know what it is that's broken? There are several
>> people on both the Tk and Python sides who are eager to learn
>> of faults, so that they can fix them as soon as possible; I'll
>> be glad to help you direct your report so that it's resolved
>> without delay. I raised your comments with the head of Tcl
>> support at ActiveState; he replied, in part, "Tk was the first
>> of the open source cross-platform UI toolkits to have full
>> unicode support, end-to-end. There are no flaws in Tcl/Tk in
>> this regards, and AFAIK this works just fine in Tkinter as well"
>> [reproduced with permission].
>
> No, I don't mean "broken unicode support", the problem lies in Python
> interfacing with Tk, when Python's unicode means something different,
> than Tk unicode.
>
> I'll try to produce some examples of erroneous behavior on both X11 and
> Windows NT and file bug report on SF.
Whops! Seems like I missed totally a whole bunch of nice updates in
Python 2.3, like support for Tk 8.4 and Tcl/Tk 8.4.3 shipping with
Windows version. Scripts that produced some weird results on Python 2.2
now run smoothly...
I am sorry for burden.
Hans-Joachim Widmaier
> 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.
I've just more or less completed my first program using pyGTK (all my
previous programs used Tkinter). While I could have done this with
Tkinter as well, I decided to change when I was searching for
something like a terminal widget (for still another project, not yet
started) and there was already a nice example with pyGTK. My first
fears of pyGTK needing much more code (as there aren't zillions of
options for the widget creator but hundreds of methods) were
unfounded, and the early code ran quite well.
There are quite a few rough edges, though, predominantly with Windows:
- Under older Windows versions, the default font isn't found, which
causes endless warning assertions. It ignores the rc file so you can't
simply change the font. (Of course you could work around that, but not
trivially, as I understand.)
- The file selection dialog has no line for the floppy disk ('A:').
It's ok for Unix, but looks alien and ugly under Windows.
- I found no way to stack the windows like I want, i.e. my "file
exists, overwrite?"-dialog pops up _below_ the file dialog and isn't
seen. Despite my attempts to close the file selection first and raise
the other. Under Linux this works fine.
- When I create a button with a stock image, I always get a text
beside it. (Like "Open" for STOCK_OPEN.) It takes some hoop-jumping to
get rid of those.
- Under windows, there's no simple installation that just works. You
have to play with the path so the DLLs are found.
Maybe some of my problems are the result of my newbie status.
OTOH, I did try wxPython a few times, and it always crashed on me
while playing with the demo. Besides, I'm a bit reluctant to use a
framework -- I consider Python to be one -- instead of just a GUI
toolkit.
Just my personal experience and thoughts.
Hans-Joachim
Sridhar R
1. Great GTK/GNOME integration - Looks great under GNU/Linux and any
system with GNOME desktop.
2. Looks even great under Windows (also XP). If you don't believe
check out the Gtk-Wimp project.
http://gtk-wimp.sourceforge.net/
GTK-Wimp is a Windows GTK theme that mimicks a Windows native look and
feel by delegating the drawing to the Windows API, resulting in near
perfect desktop integration, especially when you run XP. GTK-Wimp
respects your system font and colors.
And see the screenshots here
http://gtk-wimp.sourceforge.net/screenshots/
Somebody in the thread said that Gtk code is lengthier. But in any
project, GUI contributes only few lines of code. So this doesn't
matters anyway.
Also PyGtk(GTK) API is nice for programmers. I am not happy with
wxPython's (wxWindows either) API. Also, for me the wxPython demo
application crashed in (Slackware) GNU/Linux.