GNOME.org
 

[Glade-devel] Libglade integration thoughts

Tristan Van Berkom wrote:

On Wed, 05 Jan 2005 19:37:08 +0100, Richard Hult <richard imendio com> 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/
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]