GNOME Bugzilla – Bug 407104
clock applet does not load evolution calendars
Last modified: 2013-09-13 00:50:15 UTC
That bug has been opened on https://launchpad.net/bugs/84554 "... My calendars defined in Evolution are shown properly when clicking on the clock applet. However, if I double-click on a date Evolution does not start (as earlier). ..." "evolution calendar:///?startdate=..." doesn't work neither, that looks like an evolution bug
side effect of bug 162305?
Using Evolution 2.10, I do not have access to the calendar: uri. While mailto: contacts: tasks: are working, calendar simply does not start (well something is loading, but gui does not open).
Seems like it is related to commit for bug #270751. Removing "<oaf_attribute name="evolution:uri_schemas" type="stringv"> <item value="calendar"/> </oaf_attribute>" from GNOME_Evolution_Calendar.server makes the calendar:// uri accessible via command-line (and therefore via clock-applet) again.
Backing out the "uri_schemas" changes from GNOME_Evolution_Calendar.server does indeed make launching Evolution from the calendar applet work again. This seems to be a result of the logic of impl_Shell_handleURI() in e-shell.c, which I'm having difficulty understanding. It goes something like this: 1) Lookup the URI's schema in the component registry. 2) If the schema was NOT found, look for an alias of the URI's schema in the component registry. 3) If step (1) failed but step (2) succeeded, open a shell window. 4) If step (1) OR step (2) succeeded, handle the URI. So it looks like the "uri_schemas" additions to GNOME_Evolution_Calendar.server are causing step (1) to SUCCEED, and therefore no shell window is opened (!?). I am baffled by this logic. Changing step (3) to read: 3) If step (1) OR step (2) succeeded, open a shell window. resolves the issue without having to back out the "uri_schemas" changes. Can someone with some historical perspective explain the rationale here?
I traced the origin of the handleURI() logic to bug #258827. Doesn't really provide much insight other than Michael mentioning the solution was a hack. Here's the diff: http://svn.gnome.org/viewcvs/evolution/trunk/shell/e-shell.c?r1=26098&r2=26137
Created attachment 86723 [details] [review] Proposed patch This patch changes the handleURI() logic as described in comment #4. I still feel like I might be overlooking something important here, so I'd prefer Chen or Srini weigh in on this before committing the patch.
Matthew, it looks like more of an bug to me. I might be wrong. But atleast I remember anything from this. " * e-shell.c (impl_Shell_handleURI): Fixed for api change. (impl_Shell_handleURI): check the component alias for an alternate uri schema path. 'quick hack' for activating components from command line. This may, or may not, continue to function. " This is zucci's revision log for the change. From this, I feel that it could be a bug.
Committed to Subversion trunk (revision 33514). Thanks for reviewing!
Matthew,srini I think it makes sense to not show the shell window if the uri schema is found. For example, you would need to be able to open a mail using the uri email:/// without opening the shell window. IIRC beagle uses the same. Though calendar requires the shell to be opened for opening the appointments through uri, it would be better in future to open the appoinment editor alone without opening the shell. Its better to remove the uri_shchema for calendar as it is not required. We need to add some schema's such as appointment:/// to open the individual appointments.
Chen, you are right. Beagle uses this heavily. I was thinking off the mailto: which use to launch shell. Ill reopen the bug and Matthew, can you revert your patch and add the other one which removes the two lines. NOTE: I would prefer to comment out the lines in server.in.in file along with a FIXME that it should have a interface to launch without shell. Sorry for the confusion and trouble.
Srini, I reverted my patch in revision 33523 but I'll let you commit the GNOME_Evolution_Calendar.server.in.in changes since I'm not entirely sure what you want the FIXME comment to say. Chen, thanks for clarifying the intent of the logic.
Done.