the calendar of the clock applet is slow

[Bogdan Butnaru]

Binary package hint: gnome-panel

The gnome panel has a clock applet that displays a clock on any panel, in several different display modes. When clicked, the clock displays a calendar view of the current month, with the 'today' date selected.

The problem is that the display is slow. The first time I open the calendar in a session, it takes several seconds to display the window. After that, it's a bit better, but it still takes around a second to show the calendar window. It takes about a second to hide it, too. This on a Centrino Duo with hardly any CPU load...

It's not a show-stopper by any means, but it creates a very strong sensation of unresponsiveness. I also have the impression that the first, longer, delay actually freezes the panel for a few seconds, but since it only happens once per session I can't tell with certainty. Considering that things like Gaim display their much larger window without any noticeable delay, this is a bit embarrassing.

(This is on freshly-updated Ubuntu Feisty.)

[Chris Rose (chris-vault5)]

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here:

http://bugzilla.gnome.org/show_bug.cgi?id=413107

[Joncheyne (joncheyne)]

I confirm this too

A single click does nothing. A single click every 5 or more seconds does nothing.

A triple click always works with a single click to close. Further single clicks of less than 5 seconds apart can then open and close the calendar drop down.

If, however I select Metacity as my window manager it works fine, if I select Beryl then I get the above. So it seems to be Beryl that is in the way.

Is this the right place to post this?

[Sebastien Bacher (seb128)]

Joncheyne, no, you want to open a bug on beryl

[zerwas (zerwas)]

Now, a few months have gone and there is still no reaction. Is this due to other problems that are more important?

[Joncheyne (joncheyne)]

Hi there - I searched around at the time and couldn't quite find the
exact problem anywhere else. I also use this feature so often that for
the time being I have disabled beryl, nice as it is.

I must go and see if there has been progress ...

Thanks for getting in touch!

Jon

On 16/06/07, Peter L. <email address hidden> wrote:
> Now, a few months have gone and there is still no reaction. Is this due
> to other problems that are more important?
>
> --
> the calendar of the clock applet is slow
> https://bugs.launchpad.net/bugs/87796
> You received this bug notification because you are a direct subscriber
> of the bug.

[Sebastien Bacher (seb128)]

is that still an issue on hardy?

[Joncheyne (joncheyne)]

Not installed yet ...

2008/5/8 Sebastien Bacher <email address hidden>:
> is that still an issue on hardy?
>
> ** Changed in: gnome-panel (Ubuntu)
> Status: Confirmed => Incomplete
>
>
>
> --
> the calendar of the clock applet is slow
> https://bugs.launchpad.net/bugs/87796
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Bogdan Butnaru (bogdanb)]

I've just tried it and the problem seems to have gone away. Perhaps when adding the weather part the devs also fixed my problem.

For my part feel free to close the bug as fixed.

[Sebastien Bacher (seb128)]

closing the bug since the speed is correct now

[Jim Kirkpatrick (jim-kirkpatrick)]

This has started happening for me under Hardy: very long wait first click, then just a long wait from then on. This did not happen under previous versions back as far as Edgy, but then my usage was different...

I tried a few things and can remove the delay:
* It appears that using a Google calendar under Evolution makes this slow...
* Once I deleted the calendar entry for my Google calendar, the delay is now gone.

So it appears the use of online calendars makes the clock applet slow to the point of embarrassment. Smells like a bug to me - can't the remote calendar be queried/updated asynchronously?

Anyway, hope this info helps Ubuntu/Gnome.

Jim

[Jim Kirkpatrick (jim-kirkpatrick)]

Using online/Google calendars appears to be the cause - reopening so that someone wiser than I can check.

[Sebastien Bacher (seb128)]

the new comments describe a new issue, don't reopen closed bugs only because you have a similar bug

[Eric Work (ework)]

I'm also observing this behavior. I think in my case it's because I use evolution to access an exchange server over a VPN connection, which is not always available. Clicking the clock freezes the panel for about 30 seconds, sometimes less. Is there someway to tell the applet to only show calendar events from my personal (local) calender?

[wrowell (william-rowell)]

For me this is due to subscribing to a Google Calendar. When clicking on the clock/calendar applet, the gnome-panel becomes unresponsive for several minutes. I cannot use any launcher or menu. Running 'top', I see evolution-data-server flash to the top for a few seconds, then disappear from the list. The gnome-panel will still remain unresponsive after it evolution-data-server falls from the 'top' list. Opening evolution and removing my Google Calendar subscription allows the clock/calendar applet to open immediately.

[wrowell (william-rowell)]

I'm sorry, the problem seen by blueglow and myself is bug #194505 (https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/194505/). Please disregard my message.

Sorry again.

[Zoubidoo (zoubidoo)]

Running Clock 2.30.2 on Ubuntu 10.04, I can confirm that opening the calendar
is still slow (several seconds)

[Antono Vasiljev (antono)]

Confirm this behavior.

This only correct when Google Calendars enabled in Evolution. It seems that plugin makes query on each click.

[homayoun (amirhomayoun26)]

Confirm here. Ubuntu 10.10 using Google calendar.

It improves if you choose the type "on the web" instead of "Google" when you create it. For the URL you should use the ical link which you can find in your settings page of your Google calendar. This will be a read-only calendar though.

Still a process called "e-calendar-fact" causes the lag. every time you click on the clock applet (for showing or hiding) this process uses up to 100% of CPU.

I have marked the check mark for "Copy calendar contents locally for offline operation" for all my calendars (5-6 on the web cals). I have all the calendars in different folders in:

~/.evolution/cache/calendar

But there is only one "calendar.ics" file in:

~/.evolution/calendar/local/system

This file is related to only one of my calendars and as long as I only leave that calendar enabled everything works smoothly with no lag. As soon as I enable my other (on the web) calendars that "e-calendar-fact" causes the lag. (Renaming the file "calendar.ics" also results in lag). It seems as if the program only checks the file in "~/.evolution/calendar/local/system" and not the ones in"~/.evolution/cache/calendar". For the rest each time it grabs the information from web I guess, that's why it takes a sec after each click.

For now I'm living with only one calendar enabled trying to figure out what's wrong!

[ropic (roberto-pineda-c)]

I have the same problem with 10.10, and without using web calendars

[AlexHofbauer (alex-derhofbauer)]

It gets even worse when you enable more than one Google calendar (using caldav).

[Keith Drummond (kd353)]

Is it confirmed as being the subs to external calendars? I have been using evolution to subscribe to multiple google calendars since at least 9.04 but this slow down has only occurred to me with 10.10.

[homayoun (amirhomayoun26)]

It is definitely trying to grab information each time you click on the clock applet. (I checked my network usage.)

If you set evolution to work in "offline mode" (File>Work Offline) everything is as fast as before. Right now I have 5 calendars enabled and have no lag!

Not a big deal for me because I don't use it to check email. It's nice to see it get fixed though!

[PJSingh5000 (pjsingh5000)]

Since this bug is marked with "Fix Released" in 2008 (!), I opened a new bug (Bug #684538) to track this issue. Would someone please confirm that bug.