Re: GtkBuilder status

["Tristan Van Berkom" <tristan van berkom gmail com>]

On 5/10/06, Johan Dahlin <jdahlin async com br> wrote:

Hi

Over the last couple of weeks Henrique Romano and I have been working on
GtkBuilder, a UI constructor intended for inclusion in GTK+.
I'd like to discuss the API and some of the decisions before making the
code available for public review.

This work has been sponsored by Nokia.

We've made a couple of important decisions:
* GMarkup based parser which parses and creates the object tree in one step
  go instead of saprving a whole tree in memory.
* breaking xml format compatibility with libglade
* not supporting any deprecated or broken widgets
* only supporting menubar and toolbar construction through GtkUIManager 

* custom/fake properties are not intended to be supported. Instead
  functionality relying on them needs to be rewritten.

We also intend to write a script which will help convert a file
saved by libglade into a file which can be loaded by GtkBuilder.

XML Format
==========
Versus libglade
<glade-interface> is renamed (to interface or builder, TBD)
<widget> becomes <object>
<object> has a new attribute, constructor
<object> can have type specific child tags after the <child> child tag.
<child> has a new attribute, type
<require> is removed
Support for atk is not implemented yet, but it will be different
from the way libglade does it.

GtkBuilder API
==============
Against the libglade api
get_widget becomes get_object
get_widget_prefix becomes get_objects and the argument is removed.
filename is no longer an attribute, instead a property is added
a domain property is added
a signal finish is added
the virtual method lookup_type is removed
set_custom_handler is removed
construct is removed

GtkBuildable
============
Is an interface which an object needs to implement if it wishes to have
a specialized behavior:
* set_name, to be able to reuse the name set by the builder
* add, for adding a child to a parent
* construct_child, for specialized construction, used by mainly by widgets
  created by a GtkUIManager
* custom_tag_start/custom_tag_finish: for custom tags, see below
* set_child_property, used to set child/packing properties in a container.

Type specific tags
==================
GtkUIManager
<ui> tag which embeds the normal GtkUIManager definition.

GtkListStore
<columns> which has a child tag called <column> with an attribute called
type which value is the type name of the column.

GtkTreeStore
<columns> identical to GtkListStore

GtkSizeGroup
<widgets> which has a child tag <widget> with an attribute called name
which is the name of the widget which is part of the sizegroup.
<widgets>
  <widget name="entry1"/>
  <widget name="entry2"/>
</widgets>

GtkTreeModel will add one or several tags to allow data to be specified in
the xml format.
GtkCellRenderer or GtkTreeViewColumn will gain an additional tag to allow
attributes to be set.

Comments, suggestions?

Hi,
     good to hear that the UI building code is heading towards gtk+... and it is
now more than just a plan :D

Here are my comments, questions and concerns:

 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. 

 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 ?

 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.

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

Cheers,
                  
               
                      
-Tristan