GtkBuilder syntax for property bindings
Hello, My name is Denis Washington, and I was selected as a Google Summer of Code student this year (yay!). My project is to add support for GObject property binding (a.k.a. GBinding [1]) to Glade; see [2] for my complete proposal. A core component of this work is a new bit of GtkBuilder file syntax to encode property bindings. I have deliberately not proposed a concrete syntax in my original proposal as I believe that this is a point that really needs consensus with the GTK+ community. This is why I would now like to discuss this with you. I hope we can agree on something worthwhile before the official coding period starts (May 23). My initial proposal is to allow tags to contain a new element describing a binding to a source property instead of a concrete value. For instance, the following would make the value of property "prop" dependent on the "prop2" property value of object "source": If "prop" should have an initial value before the value of source::prop is changed the first time, that value could be nested inside of , with the same semantics as putting it into directly: initial-value The advantage of this syntax is that it fits naturally into the existing syntax, is right at the target site - which is where a property binding actually does anything, anyway - and could be extended for other types of bindings in the future, e.g. GSettings bindings (with type="settings" ...> or something similar). It is also easy to implement the way that GTK+'s GtkBuilder parser is written. The main issue with this approach is what to do with two-way bindings. One approach would be to make this a property of , but then, wouldn't appear in every property it influences anymore. Alternatively, the parser could be required to recognize direct cyclic binding declarations (A binds to B, B binds to A) and collapse them into a single two-way binding, which retains the -only-affects-the-property-it-appears-in property; the parser would be complicated by this, though. I would love to hear your feedback on this matter! Regards, Denis Washington [1] [2] http://www.google-melange.com/gsoc/project/google/gsoc2011/denisw/12001 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder syntax for property bindings
Am 07.05.2011 00:48, schrieb Matthew Barnes: On Fri, 2011-05-06 at 12:42 -0700, Christian Hergert wrote: Since GBinding, is itself, an object, why not just have the GBinding instance represented in the GtkBuilder XML. The normal object syntax might work as well: object1 object2 I think this would mean the majority of work is how to make it easy to manage from within Glade. +1, and don't forget GBindingFlags. I have discussed this with Tristan van Berkom (who maintains Glade) before and he thinks this is a bad idea; IIRC, his argument was that it requires a lot of special casing for GBinding objects and doesn't work well with Glade's internal data model. I guess he should answer this himself, though; Tristan? Denis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GSoC 2011 branch: gtkbuilder-gbinding
Hi, I have just pushed a new gtk+ branch named "gtkbuilder-gbinding" for my Google Summer of Code project "GObject property binding support in GtkBuilder and Glade" [1]. It adds support for a tag in GtkBuilder object definitions which lets you define bindings between properties. Only the simplest form of bindings offered by GLib's GBinding API [2] is currently supported, but support for all features offered by g_object_bind_property_full() is planned. Regards, Denis Washington [1] http://live.gnome.org/DenisWashington_GtkBuilder [2] http://developer.gnome.org/gobject/unstable/GBinding.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[GSoC] GtkBuilder + GBinding: Connecting transformation functions
Hi, As you might know, I have created a GTK+ branch on git.gnome.org (named "gtkbuilder-gbinding") which adds a element to the GtkBuilder syntax for my GSoC project [1]. Now I would like to add support for specifying a transformation function from the source to the target property value for a binding. Like signal handlers currently, such tranformation functions should be automatically connectable by a GtkBuilder object. The question now is where to put this connection logic. There are essentially two options: * Do this in gtk_builder_connect_signals(). This lets me reuse the code that's already there, which, given that the needed operations are almost exactly the same, would be nice. However, this makes connect_signals() kind of a misnomer, as it would then connect signals *and* tranformation functions. (A gtk_builder_connect() alias could be introduced to alleviate this.) * Introduce a new gtk_builder_connect_bindings() (or similarly named) function. This would have the advantage that connect_signals() would continue to do only what the name implies. However, this will probably mean some duplication of work and would require GTK+ users to call two instead of one connection function with the exact same arguments. As I naturally would like to have my branch merged into GTK+ master eventually, I am asking you for your thoughts on this matter. Regards, Denis [1] http://live.gnome.org/DenisWashington_GtkBuilder P.S.: The branch already contains support for reading simple elements without transformation functions and automatically creating the corresponding GBinding objects from them. I would be thankful if someone from the GTK+ developer team would review the branch and give his feedbacK; I have created a bug on b.g.o to track this. ( https://bugzilla.gnome.org/show_bug.cgi?id=654417 ) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [GSoC] GtkBuilder + GBinding: Connecting transformation functions
Am 20.07.2011 18:09, schrieb Denis Washington: Hi, As you might know, I have created a GTK+ branch on git.gnome.org (named "gtkbuilder-gbinding") which adds a element to the GtkBuilder syntax for my GSoC project [1]. Now I would like to add support for specifying a transformation function from the source to the target property value for a binding. Like signal handlers currently, such tranformation functions should be automatically connectable by a GtkBuilder object. The question now is where to put this connection logic. There are essentially two options: * Do this in gtk_builder_connect_signals(). This lets me reuse the code that's already there, which, given that the needed operations are almost exactly the same, would be nice. However, this makes connect_signals() kind of a misnomer, as it would then connect signals *and* tranformation functions. (A gtk_builder_connect() alias could be introduced to alleviate this.) * Introduce a new gtk_builder_connect_bindings() (or similarly named) function. This would have the advantage that connect_signals() would continue to do only what the name implies. However, this will probably mean some duplication of work and would require GTK+ users to call two instead of one connection function with the exact same arguments. As I naturally would like to have my branch merged into GTK+ master eventually, I am asking you for your thoughts on this matter. As I didn't receive any feedback yet, I went ahead and moved all property binding creation code to two new public functions gtk_builder_create_bindings() and gtk_builder_create_bindings_full() for now (all in my "gtkbuilder-gbinding" branch, naturally). They work exactly like gtk_builder_connect_signals*(). The code is pushed to git.gnome.org and ready for review. (There most probably won't be any other feature that will be added to the GTK+ branch, so I consider it feature-complete.) Regards, Denis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Patryk Zawadzki wrote: On Fri, Sep 19, 2008 at 10:39 AM, Vincent Untz <[EMAIL PROTECTED]> wrote: If this is a major issue, we should either reach consensus that GTK+ should revert this ASAP or decide to fix all our .glade/.ui files now. The latter won't help with applications we don't maintain, though. Fixing seems like a better idea, these apps were already broken in the first place (exploiting a bug in GTK against the documentation) What about delaying the GtkAdjustment change to GTK+ 3.0, where ABI compatibility is broken anyway? Seems better than throwing it into one of the last 2.x releases if it causes so many problems. Regards, Denis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
