Re: GtkBuilder status

[Johan Dahlin <jdahlin async com br>]

>  o first of all, GtkBuilder & GtkBuildable is a nice api and seemingly
> covers
>    the api that in libglade allowed you to provide a constructor
> function and
>    a "build_children" function... this will be important for people to
> port any
>    custom libglade extentions that were using these somewhat more
> powerfull and
>    advanced features of libglade, good show.

Thanks

>  o Out of curiousity... since IBuilable objects must be registered in
> the type system
>     for the build code to be available... how do you ensure this ?

One way is to ensure that objects are registered before calling the
GtkBuilder constructor, not very optimal since more work than needed has
to be done.
I think I'll add an api to to register a type lazily which third party
code can add to map name -> GType.

>  o One concern I have is about the format, the way it seems... oddball
> cases are being
>    treated by introducing new tags in the format specificly for those
> cases. Is there a
>    reason they cant be handled as properties ?
>    example:
>       <property id="colunms">STRING, INT, INT</property>
>       <property id="widgets">entry1, entry2</property>
>    My feelings here are that introducing these new tags in a way removes
> freedom from
>    the implementing IBuildable (if GtkSizeGroup implements a "widgets"
> property of
>    GParamSpecObjectList type, it will still need taillored load code to
> deal with the hard-coded
>    special casing tags found in the glade files). Furthermore;
> implementing every parameter
>    as a property allows (forces) all special-case code to be implemented
> with the same prototypes
>    (i.e. libglade's _register_custom_prop() ), probably resulting in
> IBuildable code that is in the
>    long run; more maintainable.

Yes, these simple cases would be possible to handle somewhat, it would
prevent you from using the delimiter character in object names, which
wouldn't be a too big deal.
However, specifying model data for GtkListStore and GtkTreeStore is not
really possible using properties, unless you want to embed CDATA which
has a defined internal structure. And is that the road we want to go?

>  o My real concern is about supporting menus and toolbars built by
> UIManager.
>     - Is the motivation here only a "time-to-market" thing ?
>     - If so, do you have any plan or stratagy to take baby-steps and
> eventually get
>       all the ui building code into the IBuildable ?
>     From what I've seen, the IBuildable architechture provides exactly
> what is needed to
>     generate menus and toolbars directly, and more powerfully than the
> UIManager
>     (does UIManager allow you to set properties on every object in its
> heirarchy individually ?
>     ... can you refer to an object in the UIManager from the rest of the
> glade file ? for a
>     random example: Say I want the mnemonic widget on a label somewhere
> in the UI to be
>     a GtkToolItem).
>     Ofcourse I'm not saying that UIManager is bad, its provided some
> convenient apis to build
>     complex menus and get all that GtkAction stuff in order, but now
> that we are introducing a
>     complete builder into gtk+, it should be time for UIManager to die.

GtkUIManager is not going to die, it has important features which are
necessary for complex applications (gnumeric, nautilus, evolution).

Adding support for deprecated widgets is wasted time, they are
in practice unmaintained and the functionality is duplicated in newer
variants.
There should be only one obvious way of doing a specific task.
GtkUIManager is the currently the obvious way of creating menus and toolbars

If you have any problems with GtkUIManager itself, start a dialog about
that, but it's a separate discussion unrelated to this.

-- 
Johan Dahlin <jdahlin async com br>
Async Open Source