Bug 172234 - Improve integration of evolution and gnome-panel
Summary: Improve integration of evolution and gnome-panel
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 10
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 170891
TreeView+ depends on / blocked
Reported: 2005-11-01 19:47 UTC by Dave Malcolm
Modified: 2009-12-18 05:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-12-18 05:51:10 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
GNOME Bugzilla 270751 None None None Never

Description Dave Malcolm 2005-11-01 19:47:22 UTC
+++ This bug was initially created as a clone of Bug #170891 +++

Double-clicking on the panel clock's calendar brings up the evolution calendar,
but it doesn't show the day that was selected in the clock's calendar. It should.

Also, it should close the clock's calendar and use startup notification, since
it takes some time for evolution to come up.

-- Additional comment from dmalcolm@redhat.com on 2005-10-27 18:26 EST --
Yes, it seems to come up with a new window containing whatever view the last
calendar window had selected (e.g. week view, month view, etc).  I agree that it
should show the day view for the day you double-clicked on.

-- Additional comment from dmalcolm@redhat.com on 2005-11-01 14:43 EST --
Looks like the necessary work has already been done and is sitting unapplied in
upstream bugzilla; gnome-panel clock needs patching, evolution doesn't:

Changing component to gnome-panel and reassigning.

-- Additional comment from dmalcolm@redhat.com on 2005-11-01 14:44 EST --
Oops; didn't see the evolution patch as well...

So both evolution and gnome-panel will need patching...

This bug is to track the evolution side of this...

Comment 1 Vic Ricker 2006-09-05 14:59:03 UTC
Apparently, some work has been done with regard to this issue but it still has
some problems.  When double clicking on a date in the panel clock/calendar, it
now opens two copies of the Evolution calendar, one showing the current date and
a second showing the day before the date that was clicked in the calendar.  It
would be nice if it opened only one instance showing the correct date.

Comment 2 Vic Ricker 2007-07-05 13:03:29 UTC
This has been mostly fixed in F7, however, Evolution STILL opens the calendar at
the day before the one that was clicked in the clock-applet.  For example,
double-click July 5, Evolution launches showing July 4.

Comment 3 Milan Crha 2007-11-20 17:54:03 UTC
Works for me on Fedora 8, even each double click opens new calendar window, I'm
not sure if it's a question for gnome-panel or Evolution itself.
Can you try with Fedora 8 and tell us what do you think?

Comment 4 Vic Ricker 2007-11-21 02:07:40 UTC
I can confirm that the problem still exists in Fedora 8.  I don't know if it's a
problem with the panel applet or Evolution.

Evolution opens fine when you double click the applet.  The problem is that it
opens to the wrong date.

Comment 5 Milan Crha 2007-11-21 09:25:50 UTC
Weird, it works for me just fine. What is your locale? I mean, my
starts-week-day is Sunday, (as the first column in the panel applet calendar)
and when I click on November 15th, then it works as expected, new calendar
window with day-view is opened and I stay on November 15th.
Also, can you check what timezone you use? If it's same in Evolution
(Edit->Preferences->Calendar and Tasks) and in the system
(System->Administration->Date & Time). Thanks in advance.

Comment 6 Vic Ricker 2007-11-23 14:26:16 UTC
My calendar (panel) starts with Sunday also.

In Evolution, time zone is set to America/New_York, adjust for DST is checked.

System is set to New York Eastern Time and System clock uses UTC is checked.


Comment 7 Milan Crha 2007-11-29 20:01:46 UTC
Thanks for info, I can reproduce it even when changing time zone in Evolution to
that yours.

Based on my observation, Evolution expects date in UTC, so it converts date back
for 5 hours, which is the day before. Assigning this to gnome-panel, they should
convert passed date to UTC, before sending it to Evolution.

Comment 8 Vic Ricker 2007-11-30 16:21:29 UTC
Great!  Thanks!

Comment 9 Matthew Barnes 2007-11-30 17:24:42 UTC
I'm not entirely convinced this is gnome-panel's fault.  Seems like Evolution
ought to accept local times unless the time is explicitly expressed as UTC.  I
could be wrong.

Leaving this assigned to myself until I can take a closer look.

Comment 10 Matthew Barnes 2007-11-30 17:27:26 UTC
Assigning back to myself.  Sorry for the bug spam, Ray.

Comment 11 Matthew Barnes 2008-03-06 02:02:28 UTC
Bumping version to Fedora 8 per comment #4.

Comment 12 Matthew Barnes 2008-03-12 02:46:55 UTC
Still appears to be an issue in GNOME 2.22.  Bumping version again, and changing
component to Evolution.  I don't think gnome-panel is doing anything wrong.

Comment 13 Milan Crha 2008-03-12 10:24:29 UTC
Matt, isn't the problem when system timezone is other than Evolution's timezone?
In that case Evolution will compute time sent by gnome-panel wrong. If there can
be set the timezone explicitly in gnome-panel and send to Evolution, then let do
it in gnome-panel and everything will work as expected. There is not much to do
in Evolution without this. Not a real fix, from my point of view, because
Evolution expects time in UTC at the moment. (I do not know whether it is a
convention or not, though.)

Comment 14 Matthew Barnes 2008-03-12 12:16:22 UTC
The problem I'm seeing is after double-clicking a date in calendar view,
Evolution does not necessarily have Day View selected.

Also, my system timezone is the same as Evolution's timezone, and the date still
comes up as yesterday.  The fact that Evolution expects calendar URIs in UTC is
not documented anywhere that I can find.  I think it makes more sense for
Evolution to interpret the URI in the current timezone, unless the URI
explicitly indicates UTC (with a 'Z' character, or whatever).

Comment 15 Bug Zapper 2008-11-26 01:48:20 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:

Comment 16 Bug Zapper 2009-11-18 08:05:25 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 17 Bug Zapper 2009-12-18 05:51:10 UTC
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.