On Sun, 2004-07-25 at 21:50, Thomas Mills Hinkle wrote:
> On Fri, 23 Jul 2004 15:27:33 -0500
> Skip Montanaro <[EMAIL PROTECTED]> wrote:
>
> > I like the concept behind the WidgetSaver script Thomas Hinkle posted the
> > other day. We're a Glade shop though, so I fear that adding the boilerplate
> > necessary to hook up each widget of interest to the WidgetSaver would cause
> > a small revolt among the developers. At the very least they'd avoid using
> > it for more than toy applications.
> >
> > So I modified it slightly. ;-) I added a GladeSaverManager class that knows
> > how to set up widget saving for a number of widget classes. The full test
> > program is now
> >
> > if gtk.gtk_version < (2, 4):
> > print >> sys.stderr, "Need gtk >= 2.4 for this demo (uses gtk.Expander)."
> > sys.exit(1)
> >
> > wtree = gtk.glade.XML("widgetsaver-2.4.glade", 'widgetsaver')
> > saver = GladeSaverManager(wtree, ["widgetsaver", "pane", "expander",
> > "check", "tog", "spin", "quit"],
> > "widgetsaver")
> >
> > quit = wtree.get_widget("quit")
> > quit.connect('clicked', saver.exit)
> >
> > gtk.main()
> > sys.exit(0)
> >
> > Full details here:
> >
> > http://www.musi-cal.com/~skip/python/WidgetSaver.py
> > http://www.musi-cal.com/~skip/python/widgetsaver-2.4.glade
>
> Very nice. I use glade as well and will implement your improvements shortly -- it's
> a much more efficient way to handle setting up multiple savers. In fact, part of me
> wants to automate this further -- for example, to hand a class a toplevel widget,
> and have all of its descendents given WidgetSavers according to a default-list of
> attributes saved for given widgets.
>
> <snip>
> > having the saver also
> > handle exiting the app seems a bit suspicious.
>
> Indeed. I have windows that load from separate glade files and need to close
> themselves without calling main_quit()! There must be a cleaner way to have the
> WidgetSaver's save themselves whenever their parent windows are destroyed.
My application has an exit callback manager that I register some things
with that gets called by the GTK exit callback. That way I can do stuff
like disconnect cleanly from network connections, kill children, etc.
The callback manager is pretty simple. Manage a list of methods via
add/remove calls. That would make it pretty simple to have WidgetSavers
do their work. I tried tying cleanup type code to unmap, hide, delete,
destroy, etc callbacks but they weren't reliably called on widgets
throughout a tree. e.g. I might have a CList that needs to update itself
when it receives a notification from a network service. When it is time
to shutdown, it should disconnect from the service. I would try using a
callback that I thought should happen but the associated signal was
never received. The dialog the CList was part of, might get unmap, or
destroy, but...
>
> > Skip Montanaro
> Tom Hinkle
> _______________________________________________
> pygtk mailing list [EMAIL PROTECTED]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
--
Steve McClure <[EMAIL PROTECTED]>
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
