Re: [gtk-list] Glade - Suggestions

["Damon Chaplin" <DAChaplin email msn com>]

>* glade should be extensible
>
>it should be possible to easily extend glade by providing additional
>widgets, along with a little bit of linkage code, which can be plugged
>in at run-time, i.e. by loading a shared library.

>* widget parameters
>
>it should be possible for widgets to be customized
>not only by modification of properties (title, enabled/disabled, bg color,
...)
>of some predefined types (strings,
>ints, colors, ...) but by allowing the widget (or the linkage code) to
>specify a custom 'inspector' (itself a widget) allowing parameterization
>of the widget of almost arbitrary complexity in the easiest way (for the
>user). the java beans api as well as the NeXT (now Apple) interface
builder,
>for example, allow for this.


Yes. That would be the ideal situation. But it really needs support within
GTK.

We currently have the getArg/setArg functions for setting properties, but at
the moment these don't cover all widgets, and they're not particularly good
for enumerated values (there are no textual descriptions of values) or
constrained
ranges (I don't think there is a way of determining the range of a value).

Of course, I'd support any (complete) reflection/customization/dynamic
loading
facilities added to GTK :-)

For now I am thinking of adding a fairly simple method of using custom
widgets
- see the TODO file.


>* output format
>
>there has been some discussion going on about whether or not to use
>a lisp syntax for the output file and most people seem to be against lisp,
>for reasons i do not understand.


It seems to me we're all arguing about whether to use '( )' or '< >' !

There are tools which could take advantage of both lisp-like syntax and
XML. I'm leaning towards XML as it is likely to become a very popular
data format in future (though I don't like the fact that you need to add end
tags
for everything, as far as I am aware). I think a program to convert the
output
to/from a lisp-like syntax would be fairly simple, so we could satisfy both
camps.


Damon