Hi there; If you are able to read in german language there is a quite good book. Author is Michael Lauer, (German) title: "Python und GUI-Toolkits" (ISBN 3-8266-0844-5). (http://www.mitp.de/vmi/mitp/detail/pWert/0844/titel/Python%20und%20GUI-Tool kits)
The author compares Tk, Qt, wxWindows and gtk2 (1.99.14). I try to give a translation of his summary. --- With all toolkits you are able to create graphical applications. But each toolkit has a different main focus. Tk is a toolkit of a earlier stage, with no special application functionality. It is most flexible and available on most platforms. Qt and wxWindows are overall frameworks to program platform independently applications. But Qt is not only most common used, it has also the better technical design. Gtk catched up enormous in version 2 both in technical design and in look&feel. --- --maik./ :> "Somesh Bartakke" writes: :> :> > can you tell mw comparision points bet pygtk annd other gui tools ? :> I think you'll find several comparisons with a little googling, :> (some usefull bits might also be found in the paralell thread :> "IDLE-Gtk / Should PyGtk be proposed for the Python 2.4 :> release?") but here is mine: :> :> I have some (not much) experience with Tkinter, pyGtk and :> (even less) wxPython. :> :> IMHO, Tkinter is a really fine gui toolkit. The problem is :> that it is old. This means it won't really get new stuff :> (like new widgets) and it will look out-of place in modern :> desktops. If you only want a simple gui, like a couple of :> buttons and entry fields, Tkinter is really easy. If you :> need a toolkit for something bigger, choose pygtk instead. :> :> In comparison with pygtk, wxPython is really bad. When I :> fooled around with it, I could segfault it pretty easily. Of :> course, these segfaults where my fault (supplying a bad :> argument somewhere, using a wrong callback, etc.) but :> getting a verbose error message is _much_ more helpfull than :> getting a simple "Segmentation fault", which tells _nothing_ :> about _what_ you are doing wrong. One of the reasons I use :> python is because error messages and crashes actually make :> sense. So getting segmentation faults from a toolkit is :> really bad. It is especially bad when you would want to play :> around in the interactive interpreter. :> :> Apart from that, parts of wxPython look really ugly. For :> example, in wxMenu, you apparently need to use numerical :> constants to define menu options. That might be fine when :> you are coding in C or C++, but in Python it looks awfully :> bad. (an example: http://wiki.wxpython.org/index.cgi/DragAndDrop :> some selected lines: :> # Declare GUI Constants :> MENU_FILE_EXIT = 101 :> :> menu1.Append(MENU_FILE_EXIT, "E&xit", "Quit Application") :> EVT_MENU(self, MENU_FILE_EXIT, self.CloseWindow) :> :> Here, the code is using a numerical constant to refer to an :> object. Doing that in Python is truly stupid.) :> :> In fact, wxPython is so bad somebody created a :> "A friendly python-like wrapper for wxPython." :> (http://www.python.org/pypi?:action=display&name=wax&version=1.44) :> (Of course, with this he will have wrappers 3 deep (wax - :> wxPython - wxWindows - gtk)!) :> :> I have the feeling that wxPython is a great toolkit _if_ you :> are coming from C++ or MFC or somesuch. It might be great :> compared to windows gui programming, but its sure not better :> than pygtk. :> :> _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
