On Thu, Aug 05, 2004 at 04:37:45PM -0500, Doug Quale wrote:
> An interesting question is whether a glade controller (or widget
> wrapper) class should automatically provide attribute bindings for the
> glade widgets or if they should be specified explicitly.

My feeling is that "it depends". For the simplest UIs, then it probably
makes sense to allow grabbing widgets transparently via the widget
wrapper -- you don't want the newbie to have to declare everything under
the sun up there.

However, for more involved interfaces, there are a couple of issues:

    - The documentation potential of indicating what widgets are special
      to your application. You have a hundred hboxes and vboxes, but
      that button and that entry and that label there are really the
      essential parts, and that's not always obvious -- you can have
      spacer labels, and content labels, for instance.

    - The potential of specifying additional special behaviour for these
      widgets.

    - The extensibility of the solution (which means adding behaviour --
      even unforseen behaviour -- to existing interfaces). For instance,
      you might want to start validating a certain widget in the future.
      That's easy -- implement a validation property and tie it into the
      "descriptor".

> Another possibility is to make the programmer create these bindings
> explicitly.  This could be done in __init__():
> 
>     class MyController(WidgetWrapper):
> 
>        def __init__(self):
>            WidgetWrapper.__init__(self, 'window1')  # window1 is in glade
>            self._treeview = self._xml.get_widget('treeview1')

This I feel lacks syntactic sugar. In Kiwi you just need to say

    widgets = ["treeview1", ... ]

and any GladeView attaches them for you. This doesn't need to be a class
attribute (it's probably better off not being, since mutable class
attributes are Bad Ideas<tm>), but it needs to be intuitive and easy to use.

> How do readers of this group use widget proxies?  I know the Kiwi
> framework uses them extensively internally.

Yep. Note that proxies need a model to be able to set their data to.

All we do in that case is prefix the widget name (in the widgets list)
with a colon -- that means it's "proxied". This is a fairly constrained
setup and I'd be much happier if you could say 

    Widget("entry1", proxy_for="name", validator=self.validate_name, ...)

but that's a bit more wordy. Maybe we could have proxy and proxy_for:

    Widget("entry1", proxy=1, ...)
    Widget("entry1", proxy_for="name", ...)

which would makes things quite easy to manage.

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331
_______________________________________________
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Reply via email to