Re: Design Considerations...

[Suboner aol com]

> have you had a look at GLE?

Oh, Ive seen that before but I never have looked at the source code before.

> it's in gnome cvs, cvs checkout gle, read its README then install.
> it lets you not only inpect widget trees of arbitrary applcations,
> but also modify them and already started out providing means for
> runtime alterable signal connections. unfortunately, i don't really
> have the time to maintain it regularly.

Hmm, that is interesting. It seems to be pretty big, maybe not as big as 
GLADE, but the one I am developing, I am hoping to minimize/simplfiy it as 
much as possible and depend more on a custom version of libglade I am working 
on to save and load widgets and their arguements, as well as place code in a 
special file for things I think should be in Gtk+ (like 
gtk_container_replace, etc).

> GLE doesn't really do that kind of special casing, for 1.2.x, it uses gtk's
> argument support. unfortunately, that hasn't been applied to all widgets
> yet.

I'll examine the code for that, but the reason I end up doing special casing 
is for the placeholder widget, when the user clicks on it, it should replace 
it with a widget and then I have to sit there and do special casing for 
replacement.

> right, enum and flag value names are already queryable, GLE uses that.
> for 1.3/2.0 we have GParamSpec in GObject that comes with MIN/MAX etc.
> it currently isn't used in gtk itself, due to shear lack of man power,
> if you want to look at working example code, check out http://beast.gtk.org,
> it auto-generates 90% of its GUI through property specifications (i.e.
> GParamSpec).

I was not aware GObject was in 1.3. I'll have a look see. 

As a side note, I've thought about also allowing for console based 
construction where a user can type in a consule to create an Glib/Gtk+ 
application, that would be interesting, I'm pretty sure it would not be 
prefered, maybe across networks it could be, hmm.

Thank you for the direction.