On Wed, 05 Jan 2005 19:37:08 +0100, Richard Hult <[EMAIL PROTECTED]> wrote:
Hi again,
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().
Yes, I know. It needs to parse and handle any glade specific metadata at the parser level, data that has nothing to do with libglade. This is not necessarily too bad, just a reflection if we want to take all aspects in consideration.
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).
Indeed, although I was thinking of the parser code rather than the GladeXML parts. Also not necessarily bad, but it adds complexity to libglade. Like above, just another point to show that there isn't only gains in using libglade for this.
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.
We need to update the libglade patch to handle this if we are going the libglade route. The i18n metadata needs to be handled differently when running in "glade mode" and "normal mode". Maybe this can be done by deferring the translation and stripping GladeXML layer instead and keeping the original string in the GladeInterface layer, like you suggested on IRC.
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:
If all additions can be handled with new properties rather than parameters on exisiting properties, it can be done this way. I don't know if that's the case.
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.
You need to be able to set this on a property-by-property basis. If the widget has more than one string, not all of them needs to be marked for translation. The context and comment are also properties of each string, not the whole widget. In short it's not the widget that is translatable, it's each individual string.
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 ?
If libglade isn't used and therefore doesn't need changing due to glade changes, we already have one centralized place which would be glade... Or maybe I misunderstood what you meant.
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).
If this will follow the rest of the patterns in GTK+ recently there probably won't be much interface exposed here. The exposed interface would not be changable as a semi-public API in libglade either. It might be possible to design the API to be very generic and useful for all glade needs though.
Anyway, since the non-libglade parser is currently nonfunctional, and since there are no huge problems with the libglade way, and the libglade maintainer is on track with us, I guess libglade is the way to go. I was just very concerned that nobody seemed to have thought about the issues I saw, and wanted to make sure that they were considered.
Regards, Richard
-- Imendio AB, http://www.imendio.com/ _______________________________________________ Glade-devel maillist - Glade-devel@lists.ximian.com http://lists.ximian.com/mailman/listinfo/glade-devel
