Re: Some introspection on GtkContainer children.



Damon Chaplin wrote:
[...]
I think you guys should probably give up on the idea of handling
standard GTK+ widgets generically. There are so many special cases that
it is almost impossible.

I definitly agree that some compromises are needed, but I dont think that
just because special cases have to be handled, an overall generic aproach
isn't envisionable.

In glade3 (I'm sure your a little familliar with the design anyway) we
try to handle anything that cant be handled genericly through an XML
widget catalog & special-case code backend; example, if a property isn't
implemented as such in gtk+, then a custom accesor function can be
provided through the backend (libglade also has this functionality).

 - Construct-only properties are handled genericly in glade-3
   (glade_widget_rebuild() will be called for construct properties,
    all children will be transported and the widget will be re-parented
    without errors).

 - Non-widget objects *are* implemented in the glade-3 core; with the
   concept of container relationships (Any GObject may parent any other
   GObject through distinct relationships) and this functions perfectly
   through libglade as well when applying our patch:
       http://bugzilla.gnome.org/show_bug.cgi?id=161903

The only real problems I'm running into in regards to introspection which
cant be easily special cased outside of the glade-3 core, is composite
children.

Note: In case your wondering, the company I work for originally paid me
to get glade3 working so that we could use it for our custom toolkit, I
know this stuff works because this toolkit/glade3/patched libglade has
been in use extensivly for over 6 months now, glitches with container
relationships & GObject parenting issues, construct only properties
are ironed out and work properly (I know thats a big claim and I have
some proving to do, dont worry; I'm on it ;-p ).

(You could also add hints to the widget description catalog files to
support things like Dan's gtk_container_get_max_children() idea.
It doesn't all have to be introspection if its just for GUI builders.)

There are more than one benefit to having a generic introspection based
approach in the builder;

    - This week I implemented GBoxed types G_TYPE_STRV & GDK_TYPE_COLOR,
      I had to add a little generic code (about an hour's work) and now
      all properties of those types are implicitly handled on all widgets.

    - Adding a new widget to the builder is usually a matter of adding one
      line to the widget catalog (special cases are complicated containers
      etc...)

    - Implementing wacky features all of a sudden is alot easier, for example:
       - I implemented a "Reset properties to default values" feature completely
         based on the GladeProperty object, no need to consider what object the
         property belongs to, its all handled implicitly by the generic property.
       - Style properties will be a sinch to implement, and will be available
         automaticly for all objects which derive from GtkWidget.
       - Undo/Redo stack is also imensly simplified because of generic properties.
       - Versioning info on widget properties & widgets is simply a matter of
         maintaining the widget catalog (i.e. any widget or property could be
         easily marked "Since 2.4" or similar), making it easy to implement
         a feature that allows the user to limit her options depending on the type
         of project she wishes to create.

All of these features (and a whole lot more I'm sure I havent though up yet)
are IMO made possible and eased by a generic - introspection based approach of
the builder, all of these points make me vary weary to "give up on the idea of
handling standard GTK+ widgets generically".

Ofcourse, maybe I misunderstood your point; the amount of work that I've
put into this project in my own time makes me little defensive on this front,
I'm sure you can understand that :)

Cheers,
                                                -Tristan




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