Re: [[gtkmm] Alternate libglademm interface]



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







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