Re: [[gtkmm] Alternate libglademm interface]



Yes. As a matter of fact I finished up all the suggested changes a couple of weeks ago - still need to do some more testing and wrap it up as a patch, but I should be able to do that in the upcoming weekend.

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








[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]