2.5 The Widgets List

GladeView, BaseView and SlaveView provide an interesting feature: the widgets list specification. It is a list of strings, each string corresponding to the name of a widget. In a high-level sense, the list describes what widgets are attached to your view. The list is processed in the following manner:

  1. All the widgets specified in self.widgets are converted to Kiwi widgets automatically. You can use Views.register_widget() to change the conversion targets. This step applies for all View classes. For SlaveView and BaseView, of course, the widget must already be an instance variable of your View (which is why you should create the interface variables before running the parent class' constructor). The matter of widget conversion and signal callbacks is discussed further in the Controller section.

  2. For GladeView, the widgets in the list are pulled using libglade and attached as instance variables of your View. In other words, if you define a widget foo in your glade file, and you specify "foo" as a member of the widgets list, it will automatically be set as self.foo (and converted to a Kiwi widget if a corresponding widget is registered). A caveat: since the toplevel window is attached to the view with the special name "toplevel" (as well as "win", for historical reasons, and "gladefile"), these names are reserved and should not be used for widgets in your glade file.

  3. For Proxy, the widgets list has a further association, which is specified by prefixing the widget name by a colon in the widgets list (using ":foo", for instance). Since we haven't discussed Proxy yet, I'll leave this to be mentioned when we get there.

As an example of how widgets should be specified and used, let's change heyglade.py to heyglade2.py:

Of course, it is often useful to subclass GladeView to be able to customize the behavior that you want for that view. I recommend changes that are to be done to the widgets at startup time (like set_bold() and set_size() for a label) should be performed in the class constructor, right after GladeView.__init__()4. If you subclass, you can skip passing widgets to the constructor by creating a class variable with the same name.

An example of a subclassed GladeView using widgets as a class variable follows (in the Kiwi tarball in Kiwi/examples/HeyPlanet/heyglade3.py):



Footnotes

...GladeView.__init__()4
Yes, in a way this is the opposite of the procedure in SlaveView and BaseView. It has to be this way because the parent constructor for GladeView is who attaches the widgets to the view, whereas the constructors for the other Views expect them to be already attached