GNOME Bugzilla – Bug 658835
[regression] Color Scheme off in calendar
Last modified: 2013-09-13 01:05:21 UTC
I'm running the git master as of Sept. 7. I have 5 local calendars, 2 on the web and 1 from contacts. Each has a different color. When I switch to the "work week" view (the one I normally use by default) the entries all seem to be there, but the colors I've chosen aren't displayed correctly. This can be fixed by turning off and on the affected calendars.
Thanks for a bug report. This seems to work fine for me. * Are only certain calendars affected by this, or all of them? * When you run evolution from console, what is there? * Is calendar colour shown in the source tree, only the work-week-view has an issue. * What cairo version do you use? * What are exact steps for the reproducer, please? Let's start with: - close evolution and e-calendar-facory/e-addressbook-factory - run evolution in view X ...
All of the calendars are affected, although usually one has the correct color. Here's what I do: I've been running evolution's mail from a console (right after logging in and starting X via startx). I then switch to the mailer (In work week view). Initially all the appointments are purple (the color of my second "On this computer" calendar, but after a second or so, they change colors. I now have two colors (I should have 3). The entries corresponding to my 1st local calendar are in the wrong color. The console shows: evolution:7724): calendar-gui-CRITICAL **: e_day_view_add_event: assertion `start < add_event_data->day_view->upper' failed (evolution:7724): calendar-gui-CRITICAL **: e_day_view_add_event: assertion `start < add_event_data->day_view->upper' failed (evolution:7724): calendar-gui-CRITICAL **: e_day_view_add_event: assertion `start < add_event_data->day_view->upper' failed (evolution:7724): calendar-gui-CRITICAL **: e_day_view_add_event: assertion `start < add_event_data->day_view->upper' failed I then moved forward a week. Now the colors for a webcal (gnome releases) are wrong, but the rest are fine. I see 2 more of the same console message (and indeed only 2 of the entries are wrong). If I cycle back and forth a week everything works properly. The problem is present in all the views (e.g., Month). I'm using cairo 1.10.2
I've the same cairo, and it seems to work fine for me, I do not see any color issue. I have enabled two local calendars and one webcal, and they are colorized as I expect them to be. I just tried under Fedora 16, which has more current versions of "everything", and it keeps colors as expected there too. I'll try to cook a debug patch for you, to see what it uses when drawing the item.
Created attachment 196481 [details] debug evo patch for evolution; This is for a day view and the work-week view. It's just a starter, to see whether the direction is right. This prints a message on console when the color for the event will not be found. If it prints it, then we then might just find why it failed for you. And if it prints it, could you give a try to valgrind, please? Something like: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt and then reproduce the issue. Maybe the log.txt will contain something useful.
Created attachment 196510 [details] Valgrind log I applied Milan's patch, but the console output is the same as what I intially reported. I then ran under valgrind (initially starting in the mailer and then switching to the calendar). To exit, I first switched back to mailer and then exited.
Thanks for the upload. The log doesn't seem to give much information regarding this issue, nothing I would expect as related to it, unfortunately. I'll update the test patch to print in both cases and let's see what colors are used.
Created attachment 196517 [details] debug evo patch ][ for evolution; slightly extended previous patch. It prints what color it is trying to use for respective events. It may print different numbers for broken colors and for correct colors. Please check.
I've tried Milan's patch. The colors displayed (right or wrong) are those being requested. I was able to catch the following sequence: start evo and switch to calendar. The first mapping has the right colors, but switched (almost instantly) to wrong ones. The log shows: day_view_main_item_draw_day_event: using 0000-0000-ffff (blue, correct) day_view_main_item_draw_day_event: using 0000-0000-ffff [snip] day_view_main_item_draw_day_event: using a0a0-2020-f0f0 (purple, wrong) [snip] day_view_main_item_draw_day_event: using a0a0-2020-f0f0 [snip] day_view_main_item_draw_day_event: using a0a0-2020-f0f0 So it looks like evo is asking for the wrong color. Although, as I mentioned initially, switching forward and back a week, leads to all the colors being correct. Also, why is it calling this multiple times? There were no focus/mapping changes AFAIK.
Hrm, probably not related at all, but could you try with a patch from a bug #659125, please? Also, are any of your events with incorrect color recurring events?
I tried the patch. Nothing changes. There are recurring events in my calendars; however, the one I showed in comment 8 doesn't recur. On the other hand, when I first switched to the calendar, all entries were purple, the color of entries that recur. It immediately switched to yellow (the correct color of 4 entries from the same calendar, two of which are instances of an entry that recurs). The purple entries that recur remain purple. Finally 2 nonrecurring entries from a 3rd calendar are in the wrong color (yellow). Could this be a problem counting the number of entries (and their colors), the count getting confused by the recurring entries?
I suspect the issue with recurrences, as they are received asynchronously now. That's why I asked about them.
Created attachment 196708 [details] eds debug patch for evolution-data-server; This adds some prints on EClient-s and ESource-s which might be useful.
Created attachment 196710 [details] evo debug patch ]I[ for evolution; Updated evo debug patch, it's still enough to make && make install in evo/calendar folder. It changes one thing in color assignments, though I still do not believe it'll fix the issue as such. But let's see what your console will tell us, together with the eds debug patch. Keep watching any finalize prints too, those would be most suspicious, but I didn't see any when trying similar steps as you wrote above, except when I was changing default calendar in the calendar tree on the left. I also do not believe that the ecm_get_color_for_component() would be called multiple times in parallel, because this function is supposed to be called from the main thread only, and because valgrind should show us such issue for sure.
I applied the evo patch (not the eds one yet). The problem remains, the calendar entries, corresponding to nonrecurring entries are wrong. Here's a sample of the console output: ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x833f9b0 source's color #00000000ffff ecm_get_color_for_component: assigning 0x833f9b0 source's color #00000000ffff [snip] day_view_main_item_draw_day_event: using a0a0-2020-f0f0 for 'Meet with Bruce' (source:0x833f970 col:'#a0a02020f0f0') day_view_main_item_draw_day_event: using 0000-0000-ffff for 'Go Home' (source:0x833f9b0 col:'#00000000ffff') [snip] day_view_main_item_draw_day_event: using a0a0-2020-f0f0 for 'Meet with Bruce' (source:0x833f970 col:'#a0a02020f0f0') day_view_main_item_draw_day_event: using 0000-0000-ffff for 'Go Home' (source:0x833f9b0 col:'#00000000ffff') [snip] ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 [snip] day_view_main_item_draw_day_event: using ffff-ffff-0000 for 'Meet with Bruce' (source:0x833f990 col:'#ffffffff0000') day_view_main_item_draw_day_event: using ffff-ffff-0000 for 'Go Home' (source:0x833f990 col:'#ffffffff0000') [snip] day_view_main_item_draw_day_event: using ffff-ffff-0000 for 'Meet with Bruce' (source:0x833f990 col:'#ffffffff0000') day_view_main_item_draw_day_event: using ffff-ffff-0000 for 'Go Home' (source:0x833f990 col:'#ffffffff0000') [snip] ecm_get_color_for_component: assigning 0x8340900 source's color #E2C6E1 ecm_get_color_for_component: assigning 0x8340900 source's color #E2C6E1 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x8340900 source's color #E2C6E1 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f9b0 source's color #00000000ffff ecm_get_color_for_component: assigning 0x833f980 source's color #0000ffff0000 ecm_get_color_for_component: assigning 0x833f9b0 source's color #00000000ffff [snip] day_view_main_item_draw_day_event: using 0000-0000-ffff for 'Go Home' (source:0x833f9b0 col:'#00000000ffff') ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f970 source's color #a0a02020f0f0 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f990 source's color #ffffffff0000 ecm_get_color_for_component: assigning 0x833f9b0 source's color #00000000ffff ecm_get_color_for_component: assigning 0x833f9b0 source's color #00000000ffff [snip] day_view_main_item_draw_day_event: using ffff-ffff-0000 for 'Meet with Bruce' (source:0x833f990 col:'#ffffffff0000') day_view_main_item_draw_day_event: using 0000-0000-ffff for 'Go Home' (source:0x833f9b0 col:'#00000000ffff') [snip] day_view_main_item_draw_day_event: using ffff-ffff-0000 for 'Meet with Bruce' (source:0x833f990 col:'#ffffffff0000') day_view_main_item_draw_day_event: using 0000-0000-ffff for 'Go Home' (source:0x833f9b0 col:'#00000000ffff') [These are the correct colors (yellow and blue) , I think] [One more observation: I started in the calendar and the colors were correct from the beginning, although trying it again resulted in the colors being wrong (all the same) and then switched to the correct ones without any action on my part.]
The eds debug patch is there to show what is going on with the ESource-s and EClient-s beign used, together wit their freeing. It's there to see what was read from the GConf and then evo patch shows what the UI uses. The view refreshes itself each minute, to show the Marcus Bain's line properly, thus that might be that, why it "fixed" color without nay action on your side.
I am seeing what appears to be similar color issues with my calendars in the 3.1.91 shipping with Ubuntu 11.10. I have 3 Google calendars, a local calendar and the contacts birthday calendar. Two of my three Google calendars change to the color of my second local calendar (contact birthdays). This seems to be very much the same observation in the reporter's second comment where colors are being set to the second local calendar. https://bugzilla.gnome.org/show_bug.cgi?id=658835#c2 For me the impact is all events for two of my Google calendars turn to the color of the birthday calendar. By toggling the calendar color in properties once or twice I can the incorrect colors to change back. At some point in the session or future session it finds its way back to the birthday contact calendar.
downstream link https://bugs.launchpad.net/evolution/+bug/853926
I was finally able to reproduce this, and it is nothing I though of with the above debug patches. The reason is that the ECalModel is receiving events from a view for one client, while it gets new events from another client, but as it's "in" already, then it caches these adds and serves them when the previous adding is done, but with the previous view, not with the view it was notified from. I like asynchronicity and this kind of race-condition which uncovers a bug in a code I wrote couple months ago, if not years.
Created attachment 197061 [details] [review] evo patch for evolution; This fixes the issue, there is used correct ECalClientView object when processing cached notifications.
Hi Milan, The patch in comment 19 works. Thanks. BTW you haven't committed it (yet).
(In reply to comment #20) > BTW you haven't committed it (yet). Thanks fro testing it. I cannot commit it yet, because sources are under hard-code freeze this week.
Created commit 75968ca in evo master (3.3.1+) Created commit 9899d83 in evo gnome-3-2 (3.2.1+)
This patch worked for me applied against 3.2.0