Re: [[gtkmm] Alternate libglademm interface]

[Christer Palm <palm nogui se>]

Hi!

I have created bug 134161 for this.

Unfortunately it is not in the form of a patch as I simply wasn't able
to get all prereqs needed to build the latest CVS, and I obviously
didn't want to make a patch that I can't even verify that it builds
correctly.

As we're close to deadline I'd rather post what I have now and hope that
perhaps someone who already has the environment up and running would
have the time to look at it...

Murray Cumming Comneon com wrote:
> We must freeze the libglademm 2.4 API on February 16th
> http://www.gnome.org/start/2.5/bindings/#ApiFreeze
>
> Are you likely to have a patch for me to look at soon?
>
> Murray Cumming
> www.murrayc.com
> murrayc usa net
>
>
> > -----Original Message-----
> > From: Christer Palm [mailto:palm nogui se] 
> > Sent: Dienstag, 7. Oktober 2003 20:54
> > To: Murray Cumming
> > Cc: gtkmm-list gnome org
> > Subject: Re: [[gtkmm] Alternate libglademm interface]
> >
> >
> > Hi!
> >
> > Murray Cumming wrote:
> >
> > > >  - Allow arbitrary constructor arguments for derived 
> >
> > widget classes.
> >
> > > This could be nice. Obviously it would be impractical to typedef an 
> > > Adapter for every possible class, so I think that the example code 
> > > should use the Adapter template without a typedef.
> >
> > The typedef's are just there for convenience, of course.
> > The Adapter should stay visible to enable it to be used directly for 
> > other classes. And yes, the example could be much better.
> >
> >
> > > >  - Straightforward creation of derived widgets, no Xml::create(),
> > > > get_derived_widget(), etc.
> > >
> > >
> > > By putting the glade filename in the constructor, yes. But 
> >
> > would this 
> >
> > > allow us to have 2 derived child-widgets that have been 
> >
> > layed out in 
> >
> > > the same container widget in a .glade file. I think the existing 
> > > get_widget_derived() method allows us to reuse an existing 
> > > Gnome::Glade::Xml instance, but this one creates a new one for each 
> > > class.
> >
> > This could quite easily be fixed by adding additional XmlWidget::Base 
> > constructors for building the widget from an existing 
> > Gnome::Glade::Xml 
> > instance.
> >
> > The other way around, the internal Xml instance should 
> > probably also be 
> > made accessable in some way.
> >
> > A version intended for general use should probably also have 
> > constructors for building from a memory buffer, specifying the root, 
> > etc., just as with Gnome::Glade::Xml.
> >
> > I didn't put it in there because I didn't need it personally...
> >
> >
> > > >  - Hides more (most) glade stuff from the user.
> > >
> > >
> > > See above. This might be a problem if the top-most class is 
> >
> > not one of 
> >
> > > your derived classes. Maybe that is not a common case.
> >
> > It appears that it is not. Most gtkmm code I've seen so far 
> > only derives 
> > top-level widgets such as windows and dialogs.
> >
> >
> > > >  - Makes it easy to catch runtime errors when, for 
> >
> > example, making a
> >
> > > > bunch of get_widget() calls by using exceptions.
> > >
> > >
> > > I don't see a need to create a new exception class. 
> > > Gnome::Glade::Xml::Error should be enough. Also, I don't 
> >
> > think we use 
> >
> > > throw() declarations in our *mm stuff.
> >
> > Well, I wasn't planning on throwing the actual 
> > XmlWidget::Exception, but 
> > more detailed exceptions derived from it, but I got a little 
> > lazy on the 
> > way and just put in throw(Exception):s for now.
> >
> > The idea is to give the user a flexible choice of what level 
> > he (she?) 
> > wants to provide error handling. If you just want to know if 
> > _anything_ 
> > went wrong, catch Glib::Exception. If you want to know if 
> > something went 
> > wrong with XmlWidget, catch XmlWidget::Exception. If you specifically 
> > want to know when a widget is missing from the glade file, catch 
> > XmlWidget::MissingWidgetException. You get the idea...
> >
> > throw specifiers are actually used in Glib, so they shouldn't 
> > cause any 
> > porting issues that are not already there. Personally I love 
> > them - they 
> > definitely help to improve your code quality.
> >
> > Both mechanisms are practically free from a runtime resource 
> > perspective. Just too bad that they aren't very frequently used, in 
> > gtkmm or elsewhere.
> >
> > All this of course subject matter to each and everyones 
> > personal taste 
> > and level on conservativism :-)
> >
> >
> > > > Please keep in mind that this is a quick proof-of-concept hack. I'd 
> > > > like
> > > > to hear your comments, as I suspect that the approach I'm 
> >
> > using may not 
> >
> > > > be 100% flawless.
> > >
> > >
> > > I don't see where you are instantiating the gtkmm GTypes. This code 
> > > just seems to instantiate the GTK+ Gtype:
> >
> > :-)
> >
> > The instantiation is well hidden inside libglademm thanks to the fact 
> > that I pass xml->gobj() to glade_xml_get_widget(), and xml is a 
> > Gnome::Glade::Xml instance (providing the virtual function 
> > for looking 
> > up the proper GType).
> >
> >
> > > In general, I would prefer patches (although new files 
> >
> > generally need 
> >
> > > to be tarballed up separately) in bugzilla. You can put the URL in 
> > > emails.
> >
> > Yes, of course. As I wrote, this wasn't meant to be an "official" 
> > submission to libglademm in any way (at least not at this stage), but 
> > merely a simple way to demonstrate the concept and gain some 
> > comments on it.
> >
> >
> > > This is interesting. I particularly don't like that the 
> >
> > classes used 
> >
> > > with the current get_widget_derived() are forced to all 
> >
> > have the same 
> >
> > > constructor parameters.
> >
> > Yes. That's actually the main reason to why I cooked this up. 
> > It was a 
> > showstopper in my case.
> >
> > --
> > Christer Palm