GNOME Bugzilla – Bug 607812
Unable to get events from "Stardates" Google calendar
Last modified: 2011-09-01 08:04:44 UTC
1. In Web browser, login to your Google Calendar account and subscribe to "Stardates" calendar (by clicking on "Add" -> "Browse Interesting Calendars"-> "More" --> "Stardates"/"Subscribe" links). 2. In Evolution, add new Stardates Google calendar (by choosing "New Calendar" and entering the Google user name in the dialog). 3. Go to Evolution calendar and make sure "Stardates" calendar is checked for displaying events. Result: Evolution does not display any of the events from Stardates calendar. Note: this is not an issue with other Google calendars, such as "US Holidays" etc.
What's your calendar type in Evolution: Google or CalDAV? (Note, the Google calendar type is unfinished and deprecated. I don't think we're supporting it anymore, since Google learned to speak CalDAV.)
Calendar type in Evolution is "Google". How do I configure Evolution to use CalDAV to access Google?
I cannot enter this calendar's URL into CalDAV properties dialog. The URL is caldav://username@gmail.com@www.google.com/calendar/dav/#stardate@group.v.calendar.google.com/events and this URL is being cut by the in the dialog. Next time I open the calendar properties dialog, the URL looks like caldav://www.google.com/calendar/dav/
Try the URI given here: http://www.google.com/support/calendar/bin/answer.py?answer=99358
The Sunbird instructions appear to be more helpful for accessing non-primary calendars.
It looks like the URL validation code in the dialog does not like the pound sign in the URL. Other calendars do not contain '#', but this one does.
This calendar seems to be very special. At least for CalDAV. I would recommend you to enter a ticker to Google's issue tracker about that, because when I fix the URL handling in Evolution, then the calendar responds with a list of known items, but when I ask for them, then I get 404, Not found. Neither Evolution, nor Sunbird is able to access this calendar through CalDAV. Sunbird can access it with their Google calendar type, but Evolution is using CalDAV internally for Google calendars. Nonetheless, I can open that Stardate calendar in evolution, with a little tweaking of the URL, using the "On The Web" calendar type. When I enter to it: webcal://www.google.com/calendar/ical/%2523stardate@group.v.calendar.google.com/public/basic.ics then it's opened. Note the double encoding of a '#' in URL. When its properties are opened the URL is shown properly again, which on save breaks it. I'll do some fixes for it.
Created attachment 152958 [details] [review] eds patch for evolution-data-server; This is only to let CalDAV decode the URL properly. I'm working on an evo patch, which will make all the plugins work with URL consistently.
Created commit ed729af in eds master (2.29.90+)
Review of attachment 152958 [details] [review]: Hmm... In C language (unlike C++), statements like if (suri && suri->path) { can sometimes work not as expected. Since C does not have "bool" data type, if() statement expects "int". Thus you are casting gchar pointers ("gchar *") to "int". This works fine unless sizeof(gchar *) is different from sizeof(int). NOTE 1: I've actually seen this situation on 16-bit Windows in mid 1990s: sizeof(int) was 2 and sizeof(char *) was 4. Then pointer happened to look something like 0xcbfd0000 and when implicitly cast to int in the if() statement, it produced 0, i.e. "false". I have not seen this situation recently on current computing environments, but I can imagine that on 64-bit systems, the pointer size can be 64 bit and int can be 32 bit, so this issue can occur. NOTE 2: The same piece of code written in C++ program works correctly because implicit casting of pointer to bool works differently.
I don't think that's true. As I understand it, expressions ("suri" and "suri->path" being two separate expressions) are evaluated as a scalar type. Scalar types include both arithmetic types and pointer types. Arithmetic types are compared for inequality with the integer constant 0 after undergoing type promotion. Pointer types are compared for inequality with the null pointer constant, which can be cast to any pointer type. So given, for example: SomePointerType *p; if (p) { ... } the compiler implicitly expands the expression to: if (p != (SomePointerType *) NULL) Although, I will agree that writing "if (p != NULL)" is more readable than "if (p)".
a) We are 20 years forward from 1990's. Trying to be "compatible" with that time is kinda step backward, than forward. b) Similar expressions are used on tons of places not only in evolution code, but all around gnome. It's a common practice. Either it's expanded or compiler uses some kind of optimization or logic for such expressions is its problem, not mine, I only do not force it to do it one way. (imagine with != NULL you add to it a request for another register for storing NULL (without optimizations), whereas without it the comparison can be done without an extra register. (Note that I have no idea how exactly gcc deals with this.) c) assuming you are right, then expressions like GINT_TO_POINTER/GPOINTER_TO_INT would not work, but they do work. I believe since 32bit systems the sizeof(void*) equals with sizeof(int). d) Nonetheless, thanks for an information, I didn't know it :)
Created commit 9a8fa88 in evo master (2.29.90+) For the issue with URL. It's a cleanup work, making things more consistent between ESource plugins. Because that '#' letter is user to delimit path/query from a fragment, then to have this working one should write it as %23, which is a form Google is offering it, so shouldn't be any problem with that. I cannot do more with this, I'm sorry.
*** Bug 609437 has been marked as a duplicate of this bug. ***
*** Bug 616543 has been marked as a duplicate of this bug. ***