GNOME Bugzilla – Bug 460649
Meeting UI Needs To Show Color Of Selected Calendar Source
Last modified: 2007-11-05 01:24:54 UTC
When you do New->Meeting the UI needs to show the color of the source that is selected. The widget currently shows the name of the source, but often the users miss this and schedule to the wrong calendars. This is especially bad with GroupWise because resources are not marked busy. I propose adding a small section on the widget where you can see the color of the sources. This would give the users a stronger visual cue that it's correct. Other information:
Created attachment 92472 [details] Note yellow box on source selection widget, to show colors of calendar.
Created attachment 92559 [details] [review] partial patch for evolution-data-server; This is partial patch only, it add colors for expanded state (when selection source), but for collapsed state the color is hidden. i could not persuade GtkOptionMenu to show both label and color.
Milan, you might try defining a GtkTreeModel with a text column and image column and then attaching it to a GtkComboBox. GtkOptionMenu is deprecated anyway. Here's a tutorial on migrating from GtkOptionMenu to GtkComboBox: http://developer.gnome.org/doc/API/2.0/gtk/gtk-migrating-GtkComboBox.html#migrating-GtkOptionMenu
Either ways, this breaks UI freeze on Monday. I would let this go for 2.11.6 (2.12) and future for later.
Partial patch committed to trunk and status changed to "New". Committed revision 7892.
Created attachment 94043 [details] [review] proposed eds patch (improved) for evolution-data-server; I rewrote it as Matt suggested, added there my own GtkCellRendererColor (who cares about GdkPixmap) :) so it works like Dave need. However, this is my first component in Gtk so I will be glad if you look at it deeply, I'm not confident much about it (even it seems working). Btw, I store sources in tree model too, but as gpointer-s, not gobject-s, just to be sure about reference counters, which depend only on me. I'm not sure if it's necessary. Also when drawing, I always call gdk_colormap_alloc_color, also not sure if it's necessary. To Dave: I finally placed colors to the left, it looks a bit better, but there is no problem to swap them. (Left if better for left-to-right reading people, I think) :)
Milan, lets target this for 2.13.1.
I know, that's ok, I realized I will not get it before the freeze, so it is fine after 2.12. We can improve it afterwards.
Milan, unfortunately you can't just change the base class of a widget. It would break libedataserverui's API and also break code that expects that widget to be a GtkOptionMenu. Instead, have a look at bug #417999 where I've proposed deprecating ESourceOptionMenu in favor of a new widget called ESourceComboBox. I'm marking the patch as rejected but I'm sure much of your work could be applied to the ESourceComboBox widget. Also, your GtkCellRendererColor looks pretty cool and might be something to propose for inclusion in GTK+. For now though I suggest renaming it to ECellRendererColor (so as not to step on GTK's namespace) and splitting it into its own file (e-cell-renderer-color.[ch]) as a new libedataserverui object. There may be other place in Evolution/E-D-S that could use this.
You have right, I didn't go through the sources to look on usage of this widget, but I've a bit luck, because I didn't find any problem with this widget at all. As I supposed, it's using e_source_option_menu_* "API" to interact with the widget, so the change was "safe". GtkCellRendererColor, I did steal that widget from Gtk's GdkPixbuf renderer, just make it a color, not pixbuf :) If I got it right, my work was a waste of time, because all the project will use ESourceComboBox as a replacement for this? Sounds good, even I should know it a bit earlier. ;)
(In reply to comment #10) > You have right, I didn't go through the sources to look on usage of this > widget, but I've a bit luck, because I didn't find any problem with this > widget at all. As I supposed, it's using e_source_option_menu_* "API" to > interact with the widget, so the change was "safe". Signals are part of the API too, and GtkOptionMenu uses a different set of signals than GtkComboBox. So code may compile fine but will likely encounter run-time errors when it tries to connect to non-existent signals, or connect signals handlers with the wrong signatures. > If I got it right, my work was a waste of time, because all the project will > use ESourceComboBox as a replacement for this? Sounds good, even I should know > it a bit earlier. ;) Certainly not a waste of time! Much of your work can probably be pasted into ESourceComboBox with little modification.
Created attachment 97779 [details] [review] proposed eds patch ]I[ for evolution-data-server; Because Matt finally committed his changes into trunk, then here's a patch to let this work as expected.
Mbarnes, can you review this and get it in asap?
Nice job, Milan! I made a few modifications to your patch: - Cleaned up the boilerplate code a bit in ECellRendererColor. - Added a "visible" column to the ESourceComboBox model, which gets bound to ECellRendererColor's "visible" property. The values in the column are always equal: TRUE if any of the sources in the model have a color, FALSE otherwise. If all the values in the column are FALSE, the column is not rendered. We want this behavior for combo boxes with address book sources, which do not use colors. It prevents the text from being needlessly indented if there are no colors to show. - Added new symbols to the API documentation. Committed to trunk (revision 8179).
i'd like to remind you that when adding new files to SVN that include translatable string, you also must add them to POTFILES.in (or POTFILES.skip) in the /po subdir, otherwise they cannot be translated, and you get a nice notice here: http://l10n.gnome.org/module/evolution-data-server . feel free to fix. :-)
Fixed.