Re: [[gtkmm] Alternate libglademm interface]

[Christer Palm <palm nogui se>]

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