Bug 1029105
| Summary: | evolution calendar colour setting for owncloud calendar breaks on each load | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | J <buggy> | ||||
| Component: | evolution | Assignee: | Matthew Barnes <mbarnes> | ||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 19 | CC: | d.fedora, lucilanga, mbarnes, mcrha | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | evolution-data-server-3.12.2 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-04-22 11:25:08 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
I've noticed this appearing: (evolution:2138): Pango-CRITICAL **: pango_color_parse: assertion `spec != NULL' failed When I move to the calendar could it be related to the issue? Thanks for a bug report. The color chosen in Calendar Properties should stick, maybe the thing that you have it configured through GOA makes the difference. I would even try Fedora 20, with evolution 3.10.x, which might have this fixed (though I do not have on mind any particular fix). I have the same problem on Fedora 20 (under gnome 3.10 and 3.12). As Milan suspected, I also use the calendar via GOA (owncloud). Ah, I see from the code that the ownCloud calendars use color as defined on the server, it tries to keep the calendar color consistent with the server side, thus the color changed locally is dropped on a resynchronization. I'd guess from the comment #1 that your ownCloud calendar doesn't have assigned any color on the server. It would be interesting to see what color your server supplied, as the parsing routine failed to decode it, but there is currently no extra debugging for ownCloud discovery. Anyway, I think I can handle the issue with incorrect/unknown color format. I do not want to disable calendar color sync with the server, because I think it's a nice feature to get the color synchronized with the color being set on the server and being used in the web UI of ownCloud. I made some changes in evolution-data-server to address this, though it would be still interesting to know what colors are returned by the server, whether the claim is correct or not. My ownCLoud server returns correctly encoded colors, they look like #rrggbb, where rr, gg, bb are 2-digits hexadecimal numbers. Created commit 02cf0bb in eds master (3.13.1+) [1] Created commit 546cd59 in eds evolution-data-server-3-12 (3.12.2+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=02cf0bb Milan, you are right! After picking colors in owncloud calendar, evolution correctly set the colors as well. For me that is good enough! In case you want me to hunt down your remaining question: How can I check which colors are returned by the server? Still, (a part of) the original bug persists and has not been fixed: color changes in evolution are not synced with the server. (In reply to Dominik Grafenhofer from comment #6) > Milan, you are right! After picking colors in owncloud calendar, evolution > correctly set the colors as well. For me that is good enough! In case you > want me to hunt down your remaining question: How can I check which colors > are returned by the server? That's OK, the information that you had not chosen any color for the calendar on the ownCloud server is sufficient. > Still, (a part of) the original bug persists and has not been fixed: color > changes in evolution are not synced with the server. Evolution doesn't "upload" the calendar color change, to be honest, I do not know how to do it. Let's have this done this way for now. |
Created attachment 822498 [details] Broken colour settings - three different colours being used for same calendar? Description of problem: The colour tag as part of evolution for a calendar view is lost on first loading of evolution for an owncloud calendar added via Gnome online accounts. Version-Release number of selected component (if applicable): evolution-3.8.5-2.fc19.x86_64 evolution-data-server-doc-3.8.5-6.fc19.noarch evolution-data-server-devel-3.8.5-6.fc19.x86_64 evolution-data-server-3.8.5-6.fc19.x86_64 evolution-bogofilter-3.8.5-2.fc19.x86_64 evolution-rss-0.3.93-3.fc19.x86_64 How reproducible: This behaviour has been present since I linked my owncloud server to Gnome. Steps to Reproduce: 1. Link owncloud server to Gnome 2. Open evolution go to calendar, set default colour for calendar by right-clicking and selecting properties 3. Close evolution and shutdown workstation or do evolution --force-shutdown 4. Start workstation and evolution or just start evolution if --force-shutdown used 5. Go to calendar find calendar entries being shown with faint pink colour. 6. right-click on calendar select properties calendar colour shown as black (different to small square shown in calendar list) but the calendar entries are not given black colour nor was black the selected colour previously. 7. Select a new colour "purple" Actual results: Loss of calendar colour selection which effects the calendar entries and the properties menu. Expected results: Calendar colour does not change once selected. Additional info: Closing and restarting evolution does not lead to colour loss. However closing evolution and then doing evolution --force-shutdown from the cmdline does.