Sorry this took so long to reply to. Busy :(.
Damon Chaplin wrote:
> Andrae Muys wrote:
>
> > > Glade was one of the first GTK+/Gnome projects to use XML. I don't think
> > > libxml was around then. I'd like to switch over to it now, though.
> >
> > So it is a historical reason, and the reason is no longer relevant. In
> > that case would you accept a patch to support libxml? OTOH, I know that
> > hp would like to see libglade made a part of Gtk+,
>
> Really? I don't remember hp saying that.
> I think if GTK+ includes a way to load XML interface definitions it should
> use GParams, and so would use generic code to load all widgets.
> I don't think they should include libglade for this.
> (This is one of the reasons GParam support is important. It makes dynamic
> loading of interface definitions trivial, and supports any widgets.)
>
He mentioned it to me in conversation on irc. I suspect then that it's
a personal desire of his that hasn't been proposed formally yet.
GParams' aren't a silver bullet that solves all our problems. They only
provide improved introspection of GObjects. For instance, in the above
GParams and libglade are orthoginal. GParams does allow libglade/glade
to interrogate unknown widgets and thereby support them dynamically,
however it dosn't provide any facility for defining an actual UI.
That's GladeXML's job. I can see why hp might be keen to see libglade
in Gtk proper, as it does make component based programming (read GNOME)
much easier. In fact the bonobo developers have had to define their own
XML format for mergable menus in bonoboui. I would be surprised if this
approach dosn't spread.
> > for this to happen we
> > would need to use GMarkup instead. Now I have had a look at the Glade
> > XML format, and I don't think we would have to change anything to
> > support GMarkup instead of libxml. However GMarkup dosn't support
> > attributes. I don't think Glade uses attributes anywhere, but if I've
> > missed something that would require a format change. The advantage of
> > using GMarkup over libxml is that GMarkup is a standard part of Glib2.0,
> > while libxml will always remain a seperate library.
> >
> > Any thought's on this?
>
> That may be a bit of a limitation.
>
While naturally there are situations where use of Attributes would be
prefered, they are actually syntactic sugar. There was some discussion
within the W3C of abolishing attributes altogeather, there is nothing
they can do that entities can't. (of course they can be more
convenient)
> > > > My specific question is this: Can I rely on _set_properties() being
> > > > called once for each property, or do I have to always set ALL the
> > > > properties of a widget EVERY time it's called?
> > >
> > > No. When loading all the properties are set in one go.
> >
> > Would you accept a patch to fix this? I am really uncomfortable with
> > having two modules assuming a different contract with the same function.
>
> Why is it causing a problem?
> I wouldn't want to change it unless it was really needed.
>
It is mainly a design issue. We have one module that assumes that it is
called once per changed property and another that assumes it is called
once for all properties. This is probably not the best arrangement, and
may be better rationalised. If this was to be done, I would prefer the
once per changed property myself.
> > mmm that wasn't what I meant. I still consider this compile-time, as
> > the properties concerned are still compiled into glade, even if they're
> > in a different module. What I meant was the ability to add and
> > specifically *delete* properties from the properties dialog in response
> > to user actions.
>
> What is this for exactly? What kinds of user actions?
> Aren't the property_add_*() functions enough for adding properties?
> There isn't a function to delete properties but you may be able to add it
> by basically doing the opposite of property_add().
>
> Are you trying to support external libraries containing all the GbWidget
> functions, or with GtkArg/GParams?
In this case I am just writing a new custom widget to support libglade.
The current custom widget is too limited. There is a need to allow the
user to add new properties and give them both a name and a value.
Naturally the user should also be able to remove properties if they
prove unnecessary.
As far as the plugin support is concerned I am still trying to support
the current GbWidget format in external libraries before I try and do
the introspective GParam trick. (for which I would expect to wait until
Gtk2 anyway).
Anyway, I ended up having a number of very busy weeks and I've only just
tonight got an opportunity to do some coding again.
Andrae
_______________________________________________
Glade-devel maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/glade-devel
