GNOME Bugzilla – Bug 708037
Allow live updates on widgets implementing GtkColorChooser
Last modified: 2014-05-21 23:28:06 UTC
The purpose of this change is to introduece a synchronized property to propagate the changes from color selection widgets deep down another color selection widget. For example, you might want to live update the color changed on a GtkColorButton. Right now, you can't do that because objects are encapsulated this way : GtkColorButton -> GtkColorChooserDialog -> GtkColorChooserWidget -> GtkColorEditor If you modify the color within GtkColorEditor, there is no way for the developer to know about the changes. This patch proposes cascading the changes live by listening to appropriate signals and saving the previously selected color in case of cancellation.
Created attachment 254874 [details] [review] colorchooser: introduce synchronized property
I'm a bit puzzled as to why this shouldn't be the default, instead of requiring a property, two virtual functions, implementations of those virtual functions, and two public functions wrapping the virtual function.
That's a valid argument, I'm ok to rewrite this without all the virtual stuff. I just tried to keep the default behavior unchanged.
I'm not entirely sure this is right - conceptually, the editor shows temporary, unsaved state until you click 'select', at which point the constructed color is added to the palette and saved.
I've done something slightly different now: When the color editor is visible, you get notify::rgba on the color widget as the color is changed.