Re: GtkBuilder status

  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 ?
       <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
     - 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
     (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 ?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]