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 607812 - Unable to get events from "Stardates" Google calendar
Unable to get events from "Stardates" Google calendar
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
2.28.x (obsolete)
Other Linux
: Normal major
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[google]
: 609437 616543 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-01-22 21:17 UTC by Oleg Noskov
Modified: 2011-09-01 08:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
eds patch (1.04 KB, patch)
2010-02-03 19:42 UTC, Milan Crha
committed Details | Review

Description Oleg Noskov 2010-01-22 21:17:31 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.
Comment 1 Matthew Barnes 2010-01-22 21:32:09 UTC
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.)
Comment 2 Oleg Noskov 2010-01-22 21:56:28 UTC
Calendar type in Evolution is "Google". How do I configure Evolution to use CalDAV to access Google?
Comment 3 Oleg Noskov 2010-01-22 22:21:54 UTC
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/
Comment 4 Matthew Barnes 2010-01-22 22:28:49 UTC
Try the URI given here:
http://www.google.com/support/calendar/bin/answer.py?answer=99358
Comment 5 Matthew Barnes 2010-01-22 22:30:47 UTC
The Sunbird instructions appear to be more helpful for accessing non-primary calendars.
Comment 6 Oleg Noskov 2010-01-25 13:16:39 UTC
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.
Comment 7 Milan Crha 2010-02-03 13:30:11 UTC
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.
Comment 8 Milan Crha 2010-02-03 19:42:23 UTC
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.
Comment 9 Milan Crha 2010-02-03 19:45:02 UTC
Created commit ed729af in eds master (2.29.90+)
Comment 10 Oleg Noskov 2010-02-03 20:16:44 UTC
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.
Comment 11 Matthew Barnes 2010-02-03 21:38:59 UTC
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)".
Comment 12 Milan Crha 2010-02-04 10:11:59 UTC
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 :)
Comment 13 Milan Crha 2010-02-04 12:00:27 UTC
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.
Comment 14 Akhil Laddha 2010-02-10 10:57:25 UTC
*** Bug 609437 has been marked as a duplicate of this bug. ***
Comment 15 Milan Crha 2011-09-01 08:04:44 UTC
*** Bug 616543 has been marked as a duplicate of this bug. ***