GNOME Bugzilla – Bug 373116
Migrate from GnomeColorPicker to GtkColorButton
Last modified: 2013-09-13 00:51:26 UTC
Evolution is still using the deprecated GnomeColorPicker widget from libgnomeui [1]. GTK+ 2.4 introduced GtkColorButton [2] as a replacement, and the GTK+ documentation even provides a tutorial for migrating from GnomeColorPicker [3]. In the course of migrating the Evolution code I found ESource's way of storing colors to be cumbersome, so I've proposed a change to the libedataserver API. See below for the bug number. [1] http://developer.gnome.org/doc/API/2.0/libgnomeui/GnomeColorPicker.html [2] http://developer.gnome.org/doc/API/2.0/gtk/GtkColorButton.html [3] http://developer.gnome.org/doc/API/2.0/gtk/gtk-migrating-GtkColorButton.html
This bug depends on bug #373117 ("Change how ESource stores colors").
Created attachment 76300 [details] [review] Proposed patch This patch utilizes the ESource API changes described in bug #373117.
Created attachment 76393 [details] [review] Revised patch This revision fixes a few bugs in the original patch and polishes the code a bit more. ecmt_value_to_string() in e-cal-model-tasks.c has a somewhat ugly hack (marked with XXX) which I plan to follow up on in a different bug.
Please see my comments on bug #373117.
This bug requires clarification of Evolution's library requirements. Please see bug #380354.
Sorry, that was supposed to be bug #380534.
Created attachment 78449 [details] [review] Revised patch Updated for evolution-2.9.3 as well as the latest revision of the ESource patch in bug #373117.
For future reference: GTK+ 2.12 will have a new function called gdk_color_to_string() (bug #373856). There are several places in the patch where such a function would be useful, so we should remember to re-visit these changes for Evolution 2.11/2.12.
Harish: Ping
Harish or Srini: Could one of you review this and bug #373117 please?
Looks fine Matthew. Will this have any migration impact on filters? Just check that up. Fine otherwise to trunk.
Migration of filters is handled in filter/filter-colour.c:xml_decode(). First I try to read the new XML property "spec", and if that fails I fall back to reading the old "red", "green", and "blue" properties (ignoring "alpha").
Thanks for reviewing, Srini. Committed to Subversion trunk, revision 33349.