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. I don't know of a single situation where the _widget has protected us from a name space collision. You could reasonably point out that I wouldn't be likely to notice as nothing is going to go blow up in my face. Still, I attribute the lack of evidence to support _widget to the fact that we try and keep our classes fairly small and directed, and put business logic and UI control code in different classes (so there's nothing more than widgets and callbacks in the GUI code in the first place). I recently started an open soure app of my own and decided to experiment with a different style. In my own app I would do this: list_store = self.treeview.get_model() So far I'm enjoying the extra simplicity, but then my OS app is still less than 1k lines. My classes aren't coming out larger or smaller than they do at work though, and that's surely a more important issue. If anybody wants a really simple implementation to this kind of wrapper class feel free to rip off the WidgetWrapper class hierarchy that I've knocked up here (it's tiny): http://cvs.sourceforge.net/viewcvs.py/bandsaw/bandsaw/src/bandsaw.py?view=markup It's small and clean and plenty good enough for small projects. Apart from the automatic attribute access I'm a fan of being able to write multiple classes to manage different parts of a GUI that just happen to have been layed out in a single glade file. Band Saw's WidgetWrapper allows you to do this: class Window(WidgetWrapper): def __init__(self): WidgetWrapper.__init__(self, 'window1') # window1 is in glade menu = Menu(self) ... blah blah ... class Menu(WidgetWrapper): def __init__(self, window): WidgetWrapper.__init__(self, 'menu1', window) The thing to note is that the Menu is passed the window, which already has a glade.XML object within it. The Menu just re-uses the one that the Window has already made, saving you the overhead of loading the glade file twice (and saving you from having two windows pop up in the event that your top level window is visible by default). Not rocket science, but very handy. It's by no means as clever as the one we've got at work, but that's proprietary and I can't rip it off. It supports clever stuff like window stacking (i.e. transiency), object tracking (to catch memory leaks) and other nice goodies. None of it has been that hard to do. -- Graham _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
