[maemo-developers] New project idea, pygtk questions, and a toolkit

[From: Daniel Amelang]

On 2/19/07, Sean Luke <sean at cs.gmu.edu> wrote:
> ...
> Last, partly in response to irritation with GTK, I've been at work
> making a lightweight cover library on top of pygtk.  The goal is to
> provide a minimum amount of functionality that's easier to use, but
> to let you dip down into pygtk when you need to.  Some items done:
>
> - All stateful widgets (including gtk.Paned) have persistent state
> across application executions.

Very cool.

>
> - A number of widgets provide the functionality of several gtk
> widgets at once.  Box provides both HBox and VBox functionality and
> also has a built-in gtk.Frame.  And Pack combines Alignment and
> Frame.    Button provides togglebuttons, regular buttons, and check
> buttons (that may be dumb, I may break them out).  Label allows for
> images as well.

This is nice, too. Sometimes GUI programming feels to "close to the
metal", and this helps solve that problem.

> - I'm replacing some widgets (SpinButton, Slider) with modified
> versions which have more functionality.

Another sorely needed improvement.

> - Hooks are handled through method calls, not signals/events.  This
> permits both subclass hooks and cleaner MVC calls (through lambdas).

This is interesting, too. As I've used gtk with various bindings
(pygtk, ruby-gtk, etc), I've also wondered why the signal mechanism
wasn't wrapped in some cloakery that made it more natural to use in
languages with lambda/closure capabilities. It might be constructive
to ask the pygtk community why they didn't take the approach that you
have, as they may have good reasons behind the decision. If you argue
a good case (and submit some patches :), I could see future versions
of pygtk adopting this method.

> - [planned] a customizable button bar, stateful and column-modifiable
> treeview, and thicker scrollbars and split pane dividers.  And
> bigger, easier to read icons.

Yes, yes and yes :)

It would be nice to see your work integrated into the hildon framework
(not the strictly python-related stuff, of course), since that's the
layer in the software stack that (I think) should capture most of
these improvements. Although you do mention some low-level widget
improvements that could go all the way down to GTK itself. Are you
planning on making the code public? Even if you don't plan to
integrate it yourself, others might do the work in merging it
upstream.

Exciting stuff!

Dan