Someone asked on the PyGTK mailinglist if it is possible to reuse certain parts of a libglade window several times within an application.
It certainly is, and it's not even hard to do!
I've quickly written a demo application to show how it's done.
The user interface designed in glade is really simple, a textbox with two toggle buttons underneath. Activating one button will display a second, disparate textbox beside the original one. Deactivating it will remove that second textarea.
The other button will display and remove a copy of the first textbox which was there from application startup.
The full widget tree of this interface is shown in
the first screenshot.
The actual code to the demo application is rather brief.
The main point to keep in mind is that you can't actually reuse the same widget, more than once, at one time. You could reuse it if you'd make sure it's never used more than once at the same time, and keep track of it (you also have to make certain it doesn't get accidentally destroyed along the way!)
What the demo really does, and what libglade allows you to do, is use (parts of) the same interface definition over and over again to build
distinct PyGTK objects and add them to the existing interface. At least the PyGTK implementation of libglade, and possibly the native C libglade as well, actually caches the interface definition in case you'd want to reuse parts of it for additional object creation.
Let's have a closer look at how it's done:
import gtk, gtk.glade
class ReuseDemo:
def __init__ (self):
self.gladefile = 'glade-reuse-demo.glade'
self.xml = gtk.glade.XML (self.gladefile)
self.win = self.xml.get_widget ('firstWindow')
self.theContainer = self.xml.get_widget ('theHBox')
self.xml.signal_autoconnect (
dict (gtk_main_quit=gtk.main_quit,
btn1_toggled=self.toggle1,
btn2_toggled=self.toggle2))
self.buttons = (self.xml.get_widget ('tbtn1'), self.xml.get_widget ('tbtn2'))
self.childTree = None
self.win.show_all()
First step is to import the gtk and gtk.glade modules.
The actual demo is in a little class; it's constructor starts by storing the name of the glade file, because it's needed later to construct the additional objects from (even if the caching should mean it isn't really re-read anymore). The xml tree from this file is parsed by pyglade and the window object is retrieved from the first of the two windows defined in it. At this point the window is already a PyGTK object!
The container that needs to have objects added to and removed from is also retrieved and stored as a class attribute. The signals for the two toggle buttons and to allow a graceful exit by means of the windowmanager close button are connected to their handlers, and the two togglebuttons' objects are also retrieved and stored away for later reference. Finally, a variable to hold a reference to the secondary textbox objects is initiated, and the window is shown.
def toggle1 (self, btn):
self.toggle (btn, 'txtContent', 1)
def toggle2 (self, btn):
self.toggle (btn, 'txtOther', 2)
The two toggle button callbacks call a single method, with the gladeXML tagname for the respective textbox object each one needs to display or remove and an index number for arguments (in addition to the togglebutton object reference that the callback received as it's first argument).
def toggle (self, btn, tagname, idx):
self.buttons[(idx%2)].set_sensitive (not btn.get_active())
if not btn.get_active():
if self.childTree:
self.theContainer.remove (self.childTree)
self.childTree = None
else:
objXML = gtk.glade.XML (self.gladefile, root=tagname)
self.childTree = objXML.get_widget (tagname)
self.theContainer.pack_end (self.childTree)
The important logic is in the final method. First, the button which is
not toggled is disabled or enabled for user interaction, depending on the activated state of the toggled button. Because the indices passed on by the two toggle buttons' callbacks were one-based, while the python tuple that holds references to the toggle buttons is zero-based, the remainder of a division by two of the callback index will automatically point to the button that was not toggled. Alternatively the values 1 and 0, in that order, and thus pointing directly to the tuple indices could also have been used as index arguments for the two callbacks.
The necessity of disabling the other button when one is activated, and therefore two textboxes are displayed, is because the demo isn't written to support displaying more than two textboxes at the same time, but especially removing the correct textbox when three would be visible. If it were extended in that sense, the need to disable the other button would disappear.
Next the activated state is tested; if the button is deactivated, the second textbox is removed from the container and the reference to it removed, while if it's activated, a new object is instantiated from the gladeXML description and added to the container.
Here's where the gladeXML tagnames come in: to recreate only part of the widget tree, and retrieve the actual widget from the parsed tree. Note that you must reconstruct the parse tree here; retrieving the same object from the original parsetree and trying to add it a second time to the container will result in a GTK+ warning (on the console) and nothing being added at all.
That's all there is to it, really. All that is left is to instantiate a class instance and start the GTK+ mainloop:
if __name__ == '__main__':
ReuseDemo()
gtk.main()
The second screenshot is an example of how the application might look in one specific state.
A tarball with the glade and python code is available from the
sysfs download area.
Yes, it’s DPL election time again. On the good side, we’ll spend less time this year than we used to thanks the constitution change. On the bad side, it seems that almost nobody is interested to run for DPL (even HE is not sure yet!).
I’ve been relatively satisfied by the work done by sam (although one can always do better) and it looks like many share this feeling… and when this is the case, we just expect the DPL to run again. But sam clearly said that he won’t run again. What a pity.
I also don’t plan to run this year[1] but I’m always interested in leadership issues and I’d gladly be part of a DPL team. Hopefully someone will provide such an alternative on the ballot this year.
Right now, I’m more in the mood of implementing some real changes (like the symbol based dependencies that I added to dpkg-shlibdeps) instead of trying to convince others to do them. When you associate this to some support of the leadership in place, it can give very good results.
Now back to real work, I still have to test and polish the dpkg-source rewrite which adds support of several brand new source package formats. Feel free to check out our progress in the sourcev3 git branch.
[1] Feel free to convince me otherwise by adding some comments here.
Partagez cet article / Share This
Like 
So, 
I’ve finally got enough information to complete the MacBookAir1,1 support, it’s been tested and it works.
I’ve also got the information I needed for the new MacBook Pro and MacBook released in February 2008, but there I’ll need some feedback. I have some doubts on which machine uses which keyboard+trackpad assembly.
A few months ago, I asked a set of questions on development mailing lists of a few GNU/Linux distributions. This resulted in very interesting discussions. As promised back then, all the answers from all distros I contacted can be read 
My FOSDEM talk didn't go entirely as planned. I tried to run a demo
of the beid packages, but unfortunately they decided to play up
again. This isn't the first time; they sometimes have this. It has
something to do with OpenSC or OpenCT, I believe, but it's hard to
figure out what, exactly. When I got back at the office with the machine
that failed to work properly, and tried again, it did work.
Heisenbugs suck. 
Since 4 hours, the planet of ocamlcore.org is online.
This is the first service provided by ocamlcore.org to the OCaml community. In fact, ocamlcore.org team has decided to release it today, because Erik Castro de Lopo ask a question about another OCaml planet in China. The one in China seems to be gathered through google search...
Putting online the planet is also the occasion to test a little application to manage feed subscription: ocaml-planet. This script is quite trivial but it was a good first experiment of managing CGI/sqlite through OCaml. The application should help us to control subscription of feeds. I think this is a better way to subscribe than letting people commit changed planet.conf in some kind of SCM (like we do for planet debian). Once the forge of ocamlcore.org will be online, we will publish the source code of this application.
I hope that this planet will be of some help for the OCaml community...
I'm going to be traveling and giving talks quite a bit this spring.
Here's what my schedule looks like now. I don't think much will be added
to it: