Description of problem:
When trying to include additional google calendars the list of calendars stays empty.
Version-Release number of selected component (if applicable):
$ rpm -qa evolution\*
$ rpm -qa libgdata\*
Steps to Reproduce:
1. Start evolution
2. Open the "New calendar" dialog and choose "Google" as source
3. Enter the name of the calendar and your Google username
4. Click on the button to retrieve the list of calendars
Evolution asks for calendar password and then nothing happens. The opening dialog is empty
Evolution should fetch the list of accessible calendars
My Google account is configured to use two-factor-authentication.
Thanks for a bug report. Your version is using a CalDAV interface, which may have issues with your two-factor authentication. there might work an application specific password, if you are asked for a password at all.
I used an application specific password for that with no success
I had another user facing the same issue as you do with 3.16.0. He told me that it works fine for him with current git master, where were done changes in this regard, but those changes cannot be backported to 3.16.x, due to involved API changes. I can see my calendars, even I do not use 2-factor authentication. We did some debugging and the debug log showed that the server returned an empty list of calendars, which evolution showed in the UI. I suppose it's the same for you.
Could you try to:
b) choose CalDAV type
c) into URL write: https://www.google.com/calendar/dav/
d) into User your Google user name (I use it without the @gmail.com suffix)
e) click "Find Calendars" button and enter the password
This gives me the list of calendars. The difference between the URL being used by the Google calendar type and this test is that the Google type uses concrete calendar URL, which can avoid lookup of other calendars. I still get the list of my calendars when I choose "Google" type at step b) above.
I'm sorry but with evolution 3.15.92 this doesn't work. I still get an empty calendar-dialog. Maybe there's something changed between 3.15.92 and 3.16.0 that makes that way a workaround.
I see. The 3.15.92 and 3.16.0 has no code changes, there landed only translations. I found the issue, here, there was used an uninitialized variable, which avoided list population, regardless the provided password being correct. There is currently no workaround for it. I fixed this for 3.16.1 of evolution. You can also use a test build I made . Interesting is that the same code in Fedora 21 works fine, but not in Fedora 22. Might be related to that uninitialized state of the variable.
Created commit 6b8c717 in evo gnome-3-16 (3.16.1+)