[Glade-devel] Property Binding Support: Present and Future

[tristanvb at openismus.com (Tristan Van Berkom)]

Hi,
   I haven't read the mail in full detail and will make a
statement soon, first I just wanted to clarify some things
in this response.

On Thu, 2011-09-01 at 17:32 +0200, Denis Washington wrote:
> Am 01.09.2011 10:32, schrieb Alexandre Mazari:
> > Hi  Denis,
> >
> > Thanks you very much for this amazing work.
>
> :)
>
> > I was wondering if the current code allows the binding of a 'model'
> > instance property to a widget's one. By model I mean non-graphical
> > non-glade-handled GObject. Is there some way to expose some arbitrary
> > GObject in the GtkBuilder context so we can bind its properties ?
>
> This is currently not supported. It would also be problematic, as we 
> could not check if the property binding is valid (that is, whether the 
> type is correct etc.) when an external object is involved. Also, one 
> would still have to match any referred-to placeholder objects with real 
> ones in code, so I'm afraif that declaring bindings with external 
> objects in the UI file wouldn't by you much.
>
> A special case, however, is bindings to GSettings objects, which might 
> be supported in the future.

Alexandre: you should know that GtkBuilder can create *any* gobject,
GtkBuildable interface is only used to extend GObjects to parse
custom xml.

Also, Glade allows you to include your own widgets/objects in Glade's
palette, so... What is very easily possible is:

  o Create your GObject that has properties
  o Create an entry point for Glade, this can be a full
    plugin or a simple xml catalog (some methods apply,
    if the GObject you write is in a library, Glade can
    introspect the possible properties you install on it,
    otherwise it's possible to declare it virtually and
    specify the properties and their types manually in the xml).
  o In Glade, you will be able to assign bindings for your
    own custom GObject that you exposed in Glade's palette.

So with this technique you really need to create the GObject
in the GtkBuilder file (that might not be a problem if you
create it early and assign it some state at init time).

Other than that... I've had plans to add something like:
   gtk_builder_expose_object (builder, object, "name");

If we land that then you could "export" objects by name
after creating the GtkBuilder and before parsing a .ui file,
this will be useful equally for assigning GObject type
properties, connecting signals and could also be used
for bindings.

However even though it's a very simple patch to GTK+ I
haven't managed to land it yet. I had intended to land
that as part of the 'composite-containers' branch I was
working on.. but stopped working on... perhaps it's
a good idea to go ahead with that addition separately
since it's very easy to do...

> > Regarding transformation, would'nt providing default transformations
> > (int<->  string, percentage<->  double in 0...1, etc.. ) make you life
> > easier by not supporting user provided functs while covering 90%
> > percent of use cases ?
>
> That's a nice idea and would also benefit programmatic uses of 
> g_object_bind_property(). These functions would have to be in GLib, 
> though; otherwise, using them would require an external library where 
> they are defined in.

GBinding already defaults to using default transformation functions.

The application developer is also free to augment the GValue transform
functions in it's own environment.

The transform function is only really useful for doing custom
transformations... for example you want your label to update
to the value "5 bottles of milk", when the 'milk_amount' integer
value is 5... or "1 bottle of milk" when the value is 1.

The transform function can be very useful for that type of case
where you need a specific transformation in context with the said
binding.

It's my opinion that the bindings integration will still be a big
win in this first iteration... without the transform functions.

Cheers,
       -Tristan