S
Steve Lamb
However wxWindows (and by extension wxPython) does use Windows
native on Windows and GTK Unix.
However wxWindows (and by extension wxPython) does use Windows
native on Windows and GTK Unix.
J
John J. Lee
David M. Cook said:
Not sure what design features you're referring to by "framework".
Perhaps Qt's signal/slot system? I think that works particularly well
as an integrated part of the GUI system, although it's certainly
possible to graft something very similar on top of GTk (as Bernhard
Herzog did in sketch; kiwi looks broader and heavier, at a glance).
None of that seems inappropriate in a GUI toolkit (not referring to
kiwi here, just Herzog's publisher/subscriber stuff). What does seem
like bloat to a Python user are Qt's XML, SQL and threading libraries
-- at least you don't have to import them or know about them.
It's not whether it can be done, it's how painful it is. There seems
to be a constant procession of people who have trouble using GTk, but
not for wx. I certainly had trouble with GTk, just due to lack of
docs. If you already know GTk, I guess, that's not a problem. And
maybe I'll discover more reasons for using GTk when I try wx...
John
J
John J. Lee
David M. Cook said:
I guess this is because X toolkits work at a lower level than the
win32 windowing API?
Having looked at some of the Xfree code and documentation, I'm glad
that I know next to nothing about X.
John
J
John J. Lee
JanC said:
Well, I suppose I really don't know whether or not Qt uses, say, the
native Windows tree control. In the end, that's the point of
interest: both Qt and wx were designed from the ground up to be
cross-platform (unlike Tk -- I presume -- and certainly unlike GTk).
Without reading the source code, you'd be hard pushed to figure out
which things Qt reimplements, and which it reuses.
Qt has never been slow or looked bad on Windows (or unix).
John
T
Ted Holden
John J. Lee wrote:
I've just been putting myself through a sort of a crash course in pygtk,
basically a text indexing and retrieval application which already existed
in several Windows and KDE versions as well as a Tcl/Tk version which
nobody had used in several years. The idea is to have some sort of a
version of the thing which integraters could work with, i.e. written mainly
in a scripting language, and python appears to be several levels of
advancement above Tcl.
Tk appears to be more functional at this point, nonetheless there was no way
to avoid having Tk code twisted and wound in and around app code in the Tcl
version of the thing whereas the glade/gtk version of the thing produces a
gui in an XML file and an absolute minimum of anything related to guis in
my own code. The difference between the two is about 400 lines of very
readable code versus about 2500 lines of code which was marginally
readable. I'd MUCH rather deal with pygtk, and assume anything I might
miss from Tk will be there in a year.
The LINUX community appears to have developed a sort of a magical nexus of
things including gcc, swig, python, pygtk, glade, and zope which, taken
together, amounts to a new sort of programming paradigm. The really big
piece of magic in the picture is swig. This says that you you can write
library code in c++ and call it from a python program with a gui produced
by glade sitting there in an XML file, and all you'd ever need to
distribute to customers would be the .so file which swig produced, one or
two .py files, and the xml file. That also says that if a customer wasn't
totally happy with some aspect of the interface, he could screw around with
it until he was.
I don't see an easy way to beat all of that.
I've just been putting myself through a sort of a crash course in pygtk,
basically a text indexing and retrieval application which already existed
in several Windows and KDE versions as well as a Tcl/Tk version which
nobody had used in several years. The idea is to have some sort of a
version of the thing which integraters could work with, i.e. written mainly
in a scripting language, and python appears to be several levels of
advancement above Tcl.
Tk appears to be more functional at this point, nonetheless there was no way
to avoid having Tk code twisted and wound in and around app code in the Tcl
version of the thing whereas the glade/gtk version of the thing produces a
gui in an XML file and an absolute minimum of anything related to guis in
my own code. The difference between the two is about 400 lines of very
readable code versus about 2500 lines of code which was marginally
readable. I'd MUCH rather deal with pygtk, and assume anything I might
miss from Tk will be there in a year.
The LINUX community appears to have developed a sort of a magical nexus of
things including gcc, swig, python, pygtk, glade, and zope which, taken
together, amounts to a new sort of programming paradigm. The really big
piece of magic in the picture is swig. This says that you you can write
library code in c++ and call it from a python program with a gui produced
by glade sitting there in an XML file, and all you'd ever need to
distribute to customers would be the .so file which swig produced, one or
two .py files, and the xml file. That also says that if a customer wasn't
totally happy with some aspect of the interface, he could screw around with
it until he was.
I don't see an easy way to beat all of that.
H
Harry George
Don't know about others, but I do it (run gtk-not-gnome apps) because
GTK...
a) Is easy to install on a variety of commercial *NIX systems, and
getting better on MS Win** (contrast to gnome).
b) Is fast loading (contrast to wx).
c) Is GPL on all platforms (contrast to QT/KDE).
d) Is rich enough/attractive enough (contrast to tcl).
e) Is less painful to bring up than a gnome or kde app if you happen
to be starting from somewhere else (e.g., fvwm2).
So while I run pretty much everything on my trusty Linux boxes, I tend
to focus on gtk for multi-platform.
J
John J. Lee
[...]Steve Lamb said:
Yep: that's exactly what I don't understand! *Why* did you do that?
John
J
John J. Lee
Ted Holden said:
Tcl, maybe, but what about wx and Qt?
(A side issue given the point below, but I certainly dispute that.
Even if you don't have a "GUI painter", you can separate GUI interface
from "business logic" implementation).
Certainly a big reduction in code size like this is very worthwhile.
wx and Qt both have equivalent functionality, though, so the mere
existence of such a tool seems an irrelevance in comparing GTk, wx and
Qt.
What does this have to do with the comparison between GTk, wx and Qt,
all of which are all GPLed?
[...]
Sorry for my repetitiveness, but: wx or Qt!
John
S
Steve Lamb
What, run GTK apps that don't touch Gnome? Simple reason: Gnome
sucks. I run KDE. I wouldn't want to load the full gamut of gnome libs
but the GTK libs are ok.
P
Peter Herndon
Well, pyGTK and wxPython are Python-language wrappers or bindings
around two separate GUI toolkits, GTK+ and wxWindows. As such, the
code details will wind up being different. I suspect, though I have
no experience with pyGTK, that differences will be mostly syntactic
and that overall coding thought processes will be mostly similar. Can
anyone else confirm/deny?
See above answer.
I know that wxPython relies on wxWindow's internationalization
capabilities, which seem to be centered around gettext and friends. I
do not see anything in the documentation that suggests support for
bidirectional font support. Seeing as how gettext and GTK+ are both
GNU apps, it should come as no surprise that GTK+ also uses gettext.
There is a comparison of wxWindows, Qt, GTK+, FOX and fltk at:
http://freshmeat.net/articles/view/928/
which provides an overview of the differences between the various
toolkits. I know there is a comparison on the wxPython site between
itself and Tk, though you can guess the conclusion from the source. I
don't know of any comparisons between the Python bindings for the
above toolkits.
Boa-Constructor is a fully-fledged IDE that includes a code editor,
debugging, and a GUI designer tool. Boa is based around wxPython, and
also includes substantial support for development for the Zope
application server. Boa-Constructor is not yet fully mature, but
shows much promise.
Glade is a GUI designer only, that generates XML resource files used
by GTK+ to generate the GUI interface. As such, it is not directly
comparable with Boa. PyGTK has support for working with such resource
files.
Interestingly enough, wxGlade is a more-or-less copy of Glade, but for
use with wxPython rather than GTK+, and it generates "cleaner" code
than Boa-Constructor.
Very well suited. Python has a standard database interface module
available which makes it easy to connect to just about any database.
Typically there are multiple drivers available for any given database
from which to choose. Python itself is extremely easy to write, and
Python wrappers for many different GUI toolkits are available.
I've found that wxPython works well cross-platform, and is easy to
use. I've heard good things about pyGTK and pyQT, but have no
experience with them.
CPU-intensive applications -- maybe. Python is not as efficient as C,
so you would be better off writing the application in Python,
profiling it to determine the areas that make the application slower
than is acceptable, and rewriting those modules as C libraries and
calling them from Python. For what it is worth, I'm currently writing
an application in Python using wxPython that retrieves simple data
from a Sybase Adaptive Server Anywhere database over ODBC, and formats
the data into a report page in generated HTML. By many orders of
magnitude, the slowest part of the application is the connection to
the database -- the ODBC connection itself. The Python and wxPython
parts are whiz-bang fast.
J
John J. Lee
Steve Lamb said:
Sorry, misread that as saying you *wrote*, not *run*.
John
J
JanC
(e-mail address removed) (John J. Lee) schreef:
According to their website they use native Windows API, but when I tried
some Qt-programs I've seen those subtle differences with normal Windows-
applications, which is very annoying at times. When something looks
similar, you expect it to behave similar. :-(
(A good example of this is dialog boxes with No/Yes while that should be
Yes/No on Windows.)
The rather simple Qt applications I have tried (one of them was Psi) took
about 25-35% of system & GDI resource handles on Win98 (resource handles
going below 5-10% is almost always "good" for a system crash in Win9x...)
and they reacted a little slow at times. Until now I never got this
problem with wxWindows programs (e.g. Audacity) on Win98.
All this gave me the "I don't like Qt" feeling, but maybe it's just that I
tried the wrong applications. ;-)
Thinking about it, this might just be a Win9x <-> WinNT issue.
According to their website they use native Windows API, but when I tried
some Qt-programs I've seen those subtle differences with normal Windows-
applications, which is very annoying at times. When something looks
similar, you expect it to behave similar. :-(
(A good example of this is dialog boxes with No/Yes while that should be
Yes/No on Windows.)
The rather simple Qt applications I have tried (one of them was Psi) took
about 25-35% of system & GDI resource handles on Win98 (resource handles
going below 5-10% is almost always "good" for a system crash in Win9x...)
and they reacted a little slow at times. Until now I never got this
problem with wxWindows programs (e.g. Audacity) on Win98.
All this gave me the "I don't like Qt" feeling, but maybe it's just that I
tried the wrong applications. ;-)
Thinking about it, this might just be a Win9x <-> WinNT issue.
U
Ubaidullah Nubar
I will appreciate some more clarification regarding the GUI framework.
If they both have a similar style, then that would be good as it will
be easy to convert from one to the other easily. Otherwise, one would
have to be extra-cautious before selecting the framework for large
projects.
The article that you mentioned below states that GTK+ has bidrectional
support. Doesn't mention anything similar for wxPython. But there are
references in wxWindows docs about right-to-left. Anybody knows how it
compares to GTK+?
Thanks for the link. It is quite informative.
I have been working through some wxPython examples. When external
resources like icons or images are used on a control, is there a way
to embed it into the freezed executable?
Thanks & Regards,
Ubaidullah Nubar.
If they both have a similar style, then that would be good as it will
be easy to convert from one to the other easily. Otherwise, one would
have to be extra-cautious before selecting the framework for large
projects.
The article that you mentioned below states that GTK+ has bidrectional
support. Doesn't mention anything similar for wxPython. But there are
references in wxWindows docs about right-to-left. Anybody knows how it
compares to GTK+?
Thanks for the link. It is quite informative.
I have been working through some wxPython examples. When external
resources like icons or images are used on a control, is there a way
to embed it into the freezed executable?
Thanks & Regards,
Ubaidullah Nubar.
L
Lothar Scholz
JanC said:
Thats what they say: native Windows API, not native Widgets.
Maybe you should finetune your text reading precision level.
P
Paul Winkler
I don't know what "system side softwares" means...
The one real drawback that comes up a lot when discussing python is
speed, since it's quite a lot slower than C.
Usually that's actually not a problem. When speed matters, good
results can be had by A) profiling and fixing your algorithms, B)
using psyco, C) replacing slow pure-python stuff with third-party C
extensions, D) replacing any remaining slow pure-python slow stuff
with your own C extensions.
However, there is at least one case when that's not likely to be
enough. An application that has critical realtime deadlines should
probably not have the python interpreter running in the realtime part.
Example, realtime DSP. Say you're processing audio in a live
performance setting. If the interpreter decides to do a bunch of
garbage collection or otherwise slows down for a moment, you could
easily miss a deadline and get very nasty dropouts in the output.
Even in this case, python can be a useful part of the application as
long as the interpreter is kept away from the time-sensitive parts of
the app.
Here's a REALLY cool project with a C DSP engine controlled by the
movement of physical objects whose movements are detected and refleted
by a Python / OpenGL UI:
http://web.media.mit.edu/~jpatten/newaudiopad.html
J
JanC
(e-mail address removed) (Lothar Scholz) schreef:
If you read both of my messages you can see that I doubted they were using
the Windows GUI (which is part of the Windows APIs), even if I didn't say
that explicitly (that happens at 4:11am
If you read both of my messages you can see that I doubted they were using
the Windows GUI (which is part of the Windows APIs), even if I didn't say
that explicitly (that happens at 4:11am
J
JanC
(e-mail address removed) (Ubaidullah Nubar) schreef:
Look at img2py.py in the wxPython/tools directory.
Look at img2py.py in the wxPython/tools directory.
C
Christian Reis
Well, I can speak of Kiwi at least, which I designed to help us write
large GUI applications in Python, here at Async Open Source.
Kiwi is different from most of the other frameworks you'll find in the
sense that it encourages you to move beyond the string manipulation
that's so common in GUI programming (read a string from an entry,
write a string to a label, etc etc). In Kiwi, you're expected to work
with objects holding data and low-level domain semantics (want to
display objects as a list? define the columns, and load the objects in
the list with one call; no more worrying about string/numeric/date
conversions).
Kiwi *really* cuts code length down; you could probably write a
phonebook application like you've asked initially in less than 40
lines, if using libglade.
The intention when writing Kiwi was to allow you to be truly object
oriented while coding; it's not a simple wrapper around a C/C++ API as
most of the other GUI libraries are (of course, Kiwi hijacks James'
PyGtK library to its own evil purpose)
Kiwi is fundamentally different, though you can use as much as you
like (just the base view classes, the proxy, the widgets, etc).
I think you'll find that the more you use a framework, the harder it
is to switch (as with any library).
GTK+2 has this pretty much solved; pango is a very nice
implementation.
Glade, when associated with libglade, is a *great* way to write the
GUI. All Glade does is generate XML, which libglade reads at runtime
-- the rest is real code, version-controllable code that you can work
with in your preferred editor.
There's nothing that offers comparable reuse and long-term
productivity, IMHO, but others will differ.
B
Bruno Desthuilliers
Ubaidullah said:
I'm not sure that such a conversion would be that easy... But anyway why
converting, since (at least on most linux distros) wxWindows uses GTK+ ?
just my 2 cents
Bruno