GtkBuilder report

[Tristan Van Berkom <tvb gnome org>]

Hi all,
   As we discussed in the last meeting - here is my evaluation the 
state of affairs on the gtkbuilder front, it mostly includes all the
stuff I think is essentially needed before the code is production ready,
and a few unclear points I think need to be discussed before 
finishing up.

Showstoppers:
=============

  - Documentation, not all the gtk-doc statements are complete - and I
    think in an depth description will be in order for the GtkBuildable
    interface

  - Parse errors should be reported nicely; currently if your glade file
    is malformed - you'll get some assertion failure like "assertion
    object_info != NULL failed".

    Some work has been done already to improve this - by looking at the
    error_missing_attribute() function in gtkbuilderparser.c - looks
    like these assertions can at least be replaced with some more
    informative output.

  - The GtkBuilder::finish signal is flawed, the builder supports
    multiple parses and buildable objects connect to this signal to know
    when the parse is over (more elegant than using an idle handler).
    The bug here is that GtkBuildable objects that were parsed by the
    builder do not disconnect thier handlers after running the signal
    callback once - those handlers will be called again when the same
    GtkBuilder parses a separate hierarchy - causing random side 
    effects and; if the previous hierarchy is destroyed at this point -
    segfaults.

    I'd propose to add a ->parse_finished vfunc to the GtkBuildable
    interface that would be called on all objects after the parse (in
    the builder "finish" class handler) - this would eliminate the 
    bug and provide a nice api to the buildable objects (i.e. no
    connecting and disconnecting and recording signal ids).

  - Atk properties
    These are currently completely unsupported - supporting atk
    properties for me personally would represent an evening of serious
    work (maybe more because I always get lazy when it comes to the 
    atk stuff - just seems like I'm writing code that noone will
    ever use)... thoughts ? is this really a showstopper ?

  - Accelerators
    Accelerators built directly from the glade file are in conflict with
    those build by GtkUIManager & GtkActions - some code is needed to
    make them share the GtkAccelGroup on the toplevel concerned... is
    this really a showstopper ?

Unclear:
========

  - abort()ing on bad glade files

    In my opinion, we shouldnt abort just because a glade file was
    malformed (we dont abort on corrupt jpegs afaik) - so what is 
    the alternative ?

    How about printing an error message about the parse failure/reason
    and then destroying the hierarchy that was "created thus far" ? 

  - Old glade format

    The patch[1] I added adds support for all widgets that were ever
    supported by libglade (with the exception of GtkCList - which was
    just me being lazy). To this end - the patch also added versioning
    information on the glade file itself, glade files with a 
    version <= 1 will have thier GtkAdjustments and GtkPixbufs handled
    in the libglade style while newer versions will expect these objects
    to simply exist in the glade file and make references to them
    (exceptions are also made for the "type" packing property clause
    from libglade for notebook tabs and frame labels, which are handled
    more elegantly in the newer format).

    I think that the versioning information support is a must have -
    this will allow us to extend the way widgets are loaded from glade
    files while maintaining backwards compatability.

    I'd also like to see all that code supporting the depricated widgets
    go into gtk+ just because the code was so easy to write and works
    exactly like it did in libglade - in other words its a no-cost
    high-benefit trade-off as far as I can see.

  - Depricated widgets

    If people think that we should explicitly discourage the use of
    depricated widgets by unsupporting them - I wont disagree (not going
    to argument on that one) - I would still like to propose that we
    support the old fashioned libglade style of glade file for the
    widgets that we do decide to support.

  - Object References & parsing of subhierarchies

    Libglade allowed the user to provide a "root" argument to
    glade_xml_new(), the builder doesnt do anything like that.

    Is this a requirement ? if so - we'll need to make that argument a
    list or an array, since some widgets will now be makeing references
    to objects that stand outside the widget hierarchy - thos referenced
    objects would also have to be parsed and available (such as
    GdkPixbuf, GtkSizeGroup, GtkAction, GtkUIManager etc).

    We could easily steer clear of this feature at least for the initial
    release...

  - GdkPixbuf cant be buildable

    I remember discussing this with Johan before gtk+ 2.10 came out...
    Some hack in the gtkbuilder code will have to exist in order to load
    pixbuf objects properly (since they need some custom code for
    loading purposes) - this can be avoided by moving GtkBuildable -->
    GBuildable and implementing this code on the pixbuf object itself.
    
  - Packing properties are only introspected on GtkContainer objects

    Currently only GtkContainer derived objects can have thier packing
    properties recognized and introspected - any GObject that parents
    another GObject delagate must explicitly implement GtkBuildable and
    handle packing properties manually.

    I'd propose this (yeah it sounds wild but its really simple):
      - Create GContainerIface with add/remove get/set_child_property
      - Implement GContainerIface on GtkContainer itself
      - use the GContainerIface api from the builder

Thoughts ?

Cheers,
                    -Tristan

[1] http://bugzilla.gnome.org/show_bug.cgi?id=383035