After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 479753 - applet clock uses wrong color for birthdays in appointments section
applet clock uses wrong color for birthdays in appointments section
Status: RESOLVED DUPLICATE of bug 503581
Product: gnome-panel
Classification: Other
Component: clock
2.18.x
Other All
: Normal minor
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-09-24 09:35 UTC by Hans de Graaff
Modified: 2008-11-29 09:16 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Description Hans de Graaff 2007-09-24 09:35:21 UTC 
The birthday should display the correct color next to the birthday, identical to the color used in evolution itself. Right now it seems to use the same color as the first appointment in the list. Since these color swatches are really useful to scan the list, it would be great to use the correct color for them. It would have saved me from a good bit of confusion as to why my co-worker had my father's birthday in his calendar. :-)

Other information:
Comment 1 Gil Forcada 2008-04-07 14:18:49 UTC 
+1 here

I have 6 (and growing) calendars in evolution and it's a PITA that the clock doesn't display the correct color for each appointment

bump version to 2.20 since I haven't tested it in a 2.22
Comment 2 Hans de Graaff 2008-04-07 18:22:25 UTC 
In 2.22 the colors are still wrong, but at least birthdays are now clearly marked.
Comment 3 Sebastian Keller 2008-05-25 23:40:26 UTC 
Could you try the patch from http://bugzilla.gnome.org/show_bug.cgi?id=503581

I think this bug is a duplicate of that bug.
Comment 4 Hans de Graaff 2008-11-29 09:15:56 UTC 

*** This bug has been marked as a duplicate of 503581 ***
Comment 5 Hans de Graaff 2008-11-29 09:16:50 UTC 
I agree that this is a duplicate and I've just confirmed that it is indeed fixed in gnome-panel 2.24.x