On AnyGUI Core
"Peter Damoc" <[email protected]> Fri, 05 Aug 2005 11:56:09 +0300
| Newsgroups | gmane.comp.python.anygui.devel |
|---|---|
| Message-ID | <op.su01rvxarbdvmk@media> |
Hello list, I've been looking around at python GUI toolkits just for fun and I came =20 across AnyGUI. It is very impressive but I think it solves the wrong problem. Let me =20 explain myself: People want to create GUIs but there are very few people that want "just"= =20 an user interface, most of them want their GUI to work flawlessly. The =20 fact that it can run on different platforms on different toolkits might =20 not be such a great thing if the developers of the app will have to =20 continuously "fix" the app for some esoteric combinations of OS =20 versions-toolkit versions-python versions. This distracts them from =20 solving the real problem: what the app should do. AnyGUI tries to unify the API and use existing toolkits BUT in this it =20 opens not one but many cans of worms, not only will the end user have to = =20 deal with the quirks of one toolkit but with the quirks of many. As a programmer I would like to have is an OSS python GUI toolkit that =20 looks great everywhere and acts the same on all platforms without custom = =20 hack in the app code. There is currently no such thing and my little mind cannot understand why= . Ok... so its a lot of work to create such a thing BUT I could not find an= y =20 project that aims to create such a thing. PyUI looked like it could be =20 something in the lines of what I'm looking for but from what I can see...= . =20 the people creating it have a different target. Here is how I see such a toolkit approached: - defined the windowing (Frames and Panels) - defined the layout (Layout managers, for starters something like =20 BoxSizer and GidBagSizer from wxpython should do) - defined the basic events/event loop - defined the basic widgets (label, textfield, button, list, etc.) - defined the renderer (this is the thing that actually creates the visua= l =20 part of the widgets based on their attributes) - the renderer should contain some kind of mechanism for rendering =20 individual widgets, for starters a bitmap based one would be enough) thin= k =20 of something that could take a archive of PNGs and mimic the appearance o= f =20 Windows, Mac, different themes of GTK or QT. Advantages: - once past the basic implementation of the windowing and event system =20 people could test it and help implement the widgets (let's say the follow= =20 the implementation guidelines for let's say Button) - this is a top-down implementation so in theory it should be less =20 buggy.... maybe for starters we could use part of an established toolkit = =20 for the windowing and drawing only to replace it with a custom system =20 written specifically for the job. Every time I look at a toolkit I try to see how well the developers =20 learned from their predecessors. For example... one of the best help =20 systems I've come across is the wxPython Demo. In my view this should be = =20 present in each and every toolkit out there. Most of what I know today I = =20 learned from the Demo. Now to the real question of this email. What should a crazy enough person do to try and build such a toolkit? How= =20 could he reuse the work that went into AnyGUI? Thanks for reading so far. :) Peter. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= es Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= A Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf