[Glade-devel] Libglade integration thoughts

[richard imendio com (Richard Hult)]

Hi all,

I've been thinking a bit about the LIBGLADE_INTEGRATION branch and I
have some thoughts about it.

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.

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.

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.

In my opinion, the code duplication involved here (pretty small, the 
parser isn't that big), is worth the gains.

Any comments on this would be appreciated.

Regards,
Richard

-- 
Imendio AB, http://www.imendio.com/