Re: Property Binding: Fixing the big blocker
Denis Washington <[email protected]> Wed, 08 Feb 2012 07:25:08 +0100
| Newsgroups | gmane.comp.gnome.glade.devel |
|---|---|
| Message-ID | <[email protected]> |
Am 18.01.2012 02:20, schrieb Juan Pablo: > Hi Denis, ok good, I will take a look at it next week when I get back from vacations. > > Greets > > Juan Pablo Did you get to that yet? Regards, Denis > > Enviado desde mi iPhone > > El 17/01/2012, a las 14:50, Denis Washington<[email protected]> escribió: > >> Hi, >> >> I have finally commited all code to fix the bug in the "gbinding" property binding branch that I described earlier (see below). Now all GladeEditor subclasses in plugins/gtk+/ call the newly introduced glade_property_invalidate() function when a property is disabled, which causes all properties bound to the disabled property to be unbound automatically. This means that all situations where the user changes the sensitivity of a property with the inspector are handled correctly now from property binding standpoint. >> >> If there are any other cases where glade_property_invalidate() needs to be called, please let me know. >> >> Regards, >> Denis >> >> Am 15.11.2011 18:45, schrieb Denis Washington: >>> Hi, >>> >>> After an unfortunate longer period of inactivity, I am happy to tell you >>> that I started to work on bringing GObject property binding support to >>> Glade again where I left off last summer after GSoC [1]. (By the way, I >>> passed final evaluation! Thanks to everyone involved! Thank for >>> mentoring me, Juan! :) This message is intended as a quick update what I >>> am doing now. >>> >>> In my last message to this list [2], I mentioned that the current Glade >>> codebase doesn't record changes to the sensitivity of properties (such >>> as, e.g., making the "label" property of a GtkButton insensitive when >>> that button is set to have a custom content widget) in its command >>> (undo/redo) system, and that this makes it impossible to cleanly >>> auto-remove property bindings that become invalid this way. Tristan >>> identified this problem as a blocker to the adoption of the property >>> binding branch [3] into master, so this is what I'm starting to tackle now. >>> >>> For this purpose, I created a new branch named "command-set-sensitive" >>> to convert all relevant property sensitivity changes to undoable >>> commands. (I am not doing this in the "gbinding" branch directly to >>> allow for easier isolated reviewing and testing.) The branch introduces >>> the following (as loosely discussed with Tristan): >>> >>> - A new command function, named glade_command_set_property_sensitive(), >>> which sets the sensitivity of a single property undoably. Being more of >>> a side effect, this command is always group with other commands (such as >>> switching the content type of a GtkButton) and should never stand on its >>> own. >>> >>> - A new virtual function of GladeWidgetAdaptor, >>> glade_widget_adaptor_adjust_property_flags(), which can be overridden >>> for each type of widget to provide a property sensitivity policy. It >>> accepts a "use_command" boolean parameter which tells the function >>> whether to use the command system for sensititivity changes or call >>> glade_widget_property_set_sensitive() directly. (The latter is required >>> when the widget is first created, or when it is loaded from a file.) >>> >>> - A port of a small portion of the GTK+ plugin to the new functions as >>> an example. (Currently, only the GtkEntry-related port is ported.) >>> >>> I hope that this work enables me to fix the last remaining big blocker >>> bug before the property binding branch is ready for prime time. Any >>> feedback is very welcome! (@Tristan: Please review when you find the time!) >>> >>> Regards, >>> Denis >>> >>> [1] https://live.gnome.org/DenisWashington_GtkBuilder >>> [2] http://lists.ximian.com/pipermail/glade-devel/2011-September/001902.html >>> [3] http://git.gnome.org/browse/glade/log/?h=gbinding >>> _______________________________________________ >>> Glade-devel maillist - [email protected] >>> http://lists.ximian.com/mailman/listinfo/glade-devel >> >> _______________________________________________ >> Glade-devel maillist - [email protected] >> http://lists.ximian.com/mailman/listinfo/glade-devel _______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel