RE: [[gtkmm] Alternate libglademm interface]

[Murray Cumming Comneon com]

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
> 
>