Re: GtkBuilder status

["Matthias Clasen" <matthias clasen gmail com>]

>   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.

I don't think such "fake genericity" will buy as much. The difference between
a new tag and a new value of the property attribute is not that big, when it
comes to doing the right thing with it...

>   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.
>
>  Building menus and toolbars and getting it right is complex, if man-power
> is the issue;
>  I will drop everything else for the time it takes to write IBuildable
> GtkMenuShells, GtkMenuItems
>  menubars, toolbars, toolitems etc myself
>  (since I am so demanding... I must offer to share in the bloodshed).

Nothing wrong with allowing buildable menus or toolbars, but how do
you propose that they should achieve what uimanager does, mainly
separation of ui and actions, and merging of uis ?

Matthias