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