Graham Ashton <[EMAIL PROTECTED]> writes:

> On Wed, 2004-07-28 at 16:54, Doug Quale wrote:
> > Christian Robottom Reis <[EMAIL PROTECTED]> writes:
> > 
> > > The issue I raised was "fear of namespace conflicts" that would be
> > > introduced by this, but I think it's rather minor.
> > 
> > I don't actually have a strong opinion whether that change would be
> > good, bad or indifferent, so I was hoping someone smarter than me
> > could give some good arguments one way or the other :)
> 
> Smarter? Not me. But I have experienced it both ways. At work we've got
> a rather large app (80k lines of Python), a fair chunk of which is GUI
> code. We use libglade and some classes that wrap it up in a similar
> manner to many of the examples posted here. The basic principle is that
> your GUI class inherits from our own GWidget type thing, in which you
> write lines like this:
> 
>    list_store = self._widget.treeview.get_model()
> 
> We had minor disagreement when we initially started with these classes
> as to whether that was more sensible than the aesthetically cleaner:
> 
>    list_store = self._treeview.get_model()
> 
> We approached it conservatively and ended up with _widget everywhere. A
> year later I can confirm that it's a right pain in the arse.

Thanks.  This is valuable experience.  I agree that name collisions
seem like an unlikely problem.

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.

I think Sridhar is automatically providing bindings to the widgets.
You can automatically provide the bindings by looking up the widgets
in __getattr__() in the WidgetWrapper base class:

    class WidgetWrapper:
        def __init__(self, ...):
           ...

        def __getattr__(self, attr):
            widget = self._xml.get_widget(attr)
            if widget is None:
                raise AttributeError, attr
            setattr(self, attr, widget)
            return widget

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')

or you can use a Python data descriptor

    class GladeWidget(object):
        "Data descriptor to bind glade widgets within a WidgetWrapper subclass"

        def __init__(self, widget_name):
            self.widget_name = widget_name

        def __get__(self, ob):
            return ob._xml.get_widget(self.widget_name)


    class MyController(WidgetWrapper):

        _treeview = GladeWidget('treeview1')

Christian pointed out the possibility of using different data
descriptors for different widget types.  This provides an easy way to
proxy the widgets. The proxy can decorate the widget with extra
methods and attributes.  It can also take extra arguments specific to
the widget type to specify radio button groups or other things.

        _treeview = TreeViewProxy('treeview1', ...)
        _up = ButtonProxy('up1', ...)

How do readers of this group use widget proxies?  I know the Kiwi
framework uses them extensively internally.
_______________________________________________
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