[Glade-devel] Libglade integration thoughts

[Tristan Van Berkom <tristan van berkom gmail com> (Tristan Van Berkom)]

On Wed, 05 Jan 2005 19:37:08 +0100, Richard Hult <richard imendio com> wrote:
> Hi all,
>
> I've been thinking a bit about the LIBGLADE_INTEGRATION branch and I
> have some thoughts about it.

For those who are interested, this is the meeting post where use
of libglade as a loader/saver was originaly brought up:
    http://lists.ximian.com/archives/public/glade-devel/2004-October/000844.html

I just re-read it to refresh my memory.

> Basically as I see it, there is one pro with using libglade to load the
> files: The parser doesn't need to be duplicated.
>
> Some cons:
>
> Libglade is really meant to be used for "runtime" operation, as used
> normally by applications. In order to be used to load glade files in
> glade, it needs to either be hacked to have two "modes", one normal mode
> and one for glade where it keeps more data around, or it will need to
> keep unneccesary data.

I wouldn't call it a hack at all, 
    the libglade api uses glade_xml_build_widget () to actualy construct 
the widget and add it to a hash table for lookups (and some other misc stuff), 
But the glade file is already parsed at that point and loaded into a
GladeInterface structure, we use the GladeInterface struct to build our widgets,
not a dual mode to glade_xml_new().

Note also that libglade dosn't need all that much extra code to be able 
to load files, the GladeInterface struct might grow a few bytes in
user applications
but if those applications are written properly, they'll g_object_unref (xml)
once they finished doing any glade_xml_get_widget() (since the GladeXML is
heavy and useless to have around after application startup anyway).

> An example of this is the i18n metadata (translatable, context, i18n
> comment) that is edited by the user in glade, but only used during
> parsing in normal use, or not used at all (the comment).
>
> Besides just storing the metadata, there are additional problems
> handling it. For instance, the i18n context: libglade optionally strips
> a context prefix from strings before translating them and this prefix
> needs to be kept when used in glade, since it's part of the original
> string that the user inputs.
>
> Translations also need to be special cased in some way. Right now, all
> strings that happen to be translated in glade itself, also are
> translated in the loaded files.
>
> Every time we need to add some kind of metadata, libglade would need to
> be involved. There would be an added constraint on what we can do with
> the glade UI, and also be more work to fit it into libglade's parser.

In 99% of these cases, namespaced custom properties can be used (which
are transperent to libglade), and in any other cases (such as:
    `<property name="bla" translatable=true>text</property>'
which forces us to add `->translatable' to the GladePropInfo struct) this
does two good things for us:

    1.) It forces us to reconsider this design (I'm still wondering why
          "translatable" isn't just a custom property on GtkLabel or any
          other translatable widgets, I have to admit I havent understood
          why "properties" are translatable directly.

    2.) It forces us to update GladeInterface structures in the 1% of the time
          when its really nescisary, this IMO is a good thing because it should
          reduce overall confusion (It should be a plus that the GladeInterface
          structures are a direct and complete replication of all
glade metadata)
          Since it would have to be updated somewhere in glade-3 anyway, why
          not do it in one centralized place ?

> Finally, there are plans for GTK+ to get an equivalence of libglade
> soon, in 2.8 if possible. Once that happens, there will be no
> possibility for glade special casing, additions or hacks inside GTK+ for
> glade specific stuff. If we have our own parser, we can handle
> everything inside glade.

I dont see why this should be a problem, we can still use an exposed
low level parser in gtk+ to get GladeInterface built from xml files, we also 
get the added gain of alot more people arguing for or against integration
of features (which are most likely hacks) such as "translatable" on properties
(and in normal cases, we just use custom properties).

There is this one major added gain in loading/saving glade files in our
own duplicated codebase: It allows us to dictate the functionality of glade 
without being forced to cooperate directly with other projects, I am not 
convinced that this is a valid plus.

Cheers,
                                                            -Tristan