Ubuntu

Gnome drawer applet delays and unresponsiveness

Reported by Ari on 2007-04-22
178
This bug affects 22 people
Affects Status Importance Assigned to Milestone
GNOME Panel
Won't Fix
Medium
One Hundred Papercuts
Undecided
Unassigned
compiz (Ubuntu)
Undecided
Unassigned
gnome-panel (Ubuntu)
Low
Ubuntu Desktop Bugs

Bug Description

The drawer applet in the panel behaves weirdly.

When first added to a panel (either the panel in the top of the screen or the one in the bottom of the screen), everything looks good. But after adding to the drawer a link to a simple text file (so that, when clicked, gedit opens with this textfile), opening the drawer requires up to three clicks in the applet (the applet wont open until the third click). And even then, the drawer opens just a bit and then some three seconds later it fully opens showing its contents.

I have a feisty fresh install. Exactly the same thing happened to me with Edgy and Dapper before. Hopefully it can get fixed for the next release :)

thanks

Sebastien Bacher (seb128) wrote :

Thank you for your bug. That works correctly on my desktop. Do you have the bug with any text? Does it happen with an another user?

Changed in gnome-applets:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Unconfirmed → Needs Info
Ari (ari-reads) wrote :

Hi,

 I could reliable reproduce this in my office laptop. It also has a Feisty fresh install, same as my desktop.

Steps to reproduce:

  - right click in the top panel, select "add to panel", add a drawer.

  - right click in the drawer, select "add to drawer", select "Custom Application Launcher", then:

     - select Type = File
     - click Browse; go to your home folder and select a .txt file; put a name on the launcher and click close
         In my case the file location looks like:

                 file:///media/sda6/User/Program%20Data/My.Notes.txt

 - click on the drawer in the panel: Nothing happens!
 - click again on the drawer in the panel: Nothing happens!
 - click a third time: now the drawer open a bit but still does not show the contents. Two or 3 seconds later, it opens itself and shows the contents.

A bit weirdy behavior :)

Thanks a bunch for your support!

Ari (ari-reads) wrote :

Forgot to comment that: my initial report was based in my desktop PC. As mentioned above I ran into the same problem in my office laptop too, different user, totally different hardware and installed applications.

Also it I can reproduce this 100% of the time following the steps above, in both machines.

Sebastien Bacher (seb128) wrote :

I've just tried on a new 7.04 installation and the bug doesn't happen there

Changed in gnome-applets:
status: Needs Info → Unconfirmed
Ari (ari-reads) wrote :

Hi, I made some more testing. The three-click-to-open and the slowness when opening happens when using Beryl as window manager. When using Metacity all is good. So this looks like a Beryl interaction problem. Again, reproducible 100% of the time in different machines.

Should I open a bug against Beryl?

Thanks!

Sebastien Bacher (seb128) wrote :

no need, bugs can be reassigned, changing the current one

Changed in gnome-panel:
assignee: desktop-bugs → nobody
ZeroFill (launchpad-zer0fill) wrote :

I have almost exactly the same problem in 7.04

I have a drawer with the Internet icon (Applications > Internet) and has the three IEs4Linux links in there.

The difference with my case is that it always delays.

Ari, you may have to click several times because of focus stealing.

Go to Beryl Settings Manager
> General Options
> Main
> Level of FOcus Stealing Prevention
=> None

Ari (ari-reads) wrote :

Thanks ZeroFill! you also solved one long standing problem I had in all feisty computers: uresponsiveness when clicking the clock/calendar in the panel, or the "hide all windows" button.

I don't know what the beryl folks intended with this "focus stealing prevention" but something has gone wrong with it :)

Beryl is replaced by Compiz Fusion, so has been removed from Gutsy.

  status invalid
  subscribe

Changed in beryl-core:
status: New → Invalid
Ari (ari-reads) wrote :

Hi William, I've been running Compiz-Fusion for about a month now (nightlies, updated every couple of days). The problem still persists exactly the same with Compiz-Fusion.

I'll change the affected package.

Ari (ari-reads) wrote :

Changing affected package from Beryl to Compiz (compiz-fusion)

Changed in beryl-core:
status: Invalid → Confirmed
Tuttle (marianhermann) wrote :

I experience the bug (delayed (about 1 sec.) reaction of the drawer applet) currently with compiz 1:0.6.0+git20071004-0ubuntu2.

Interestingly the drawer worked correctly together with compiz before an update, i think, the compiz version it worked with was 1:0.5.2+git20070928-0ubuntu1 .

Andrew Oakley (andrew-aoakley) wrote :

This bug is still present in Ubuntu Hardy Alpha 3.

Changed in gnome-panel:
status: Confirmed → Triaged
Changed in gnome-panel:
assignee: nobody → desktop-bugs
Andrew Oakley (andrew-aoakley) wrote :

Is this related to bug #12040 "Gnome menu is slow when clicking for the first time" ?

Ari (ari-reads) wrote :

No, it is not, at least from the user perspective they are totally unrelated.

This one only affects drawers, and happens only when using compiz (up to and including Hardy A3, per the above report). The other one only affects the panel menu and is a pain with or without compiz.

Changed in gnome-panel:
status: Unknown → New
Pedro Villavicencio (pedro) wrote :

marking compiz task as confirmed since two different people are experience the same issue, thanks.

Changed in compiz:
status: New → Confirmed
qwuery (qwuery) wrote :

(disclaimer: new to Linux)
Same for Hardy Alpha 5 (creating new drawer, opens fine the first time, opening the second time = 1 sec delay before fully expand)-- makes drawers unusable =(

Playing around in gconf-editor... unchecking enable_animations gets rid of the delay, but then the drawer always pops up in the very upper-left corner of the screen (instead of directly under the drawer icon) (see screenshot). Playing around with all the x/y variables doesn't seem to move it at all. (under /apps/panel/toplevels or /objects). ??

Upon rechecking enable_animation, the drawer disappears altogether (to clarify, the drawer icon remains on the main panel but the mini-panel doesn't appear anymore)... won't open no matter how much you click it (that's be the drawer with the X in the screenshot). Great...

(I know this doesn't belong in a bug report, but is there any way to more easily figure out what key corresponds to what menu item in gconf-editor? It's kind of trial-error right now... thanks.)

Tuttle (marianhermann) wrote :

qw1,
the wrong position of the drawer's panel is another bug which I think is discussed here:
https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/140992

Nevertheless it is perhaps useful to have a workaround for the drawer-delay-bug, if the wrong-position-bug gets fixed so that disabling animations can be used for drawer-panels.

qwuery (qwuery) wrote :

*beta, sorry not alpha 5.
Thanks, that's exactly what was happening.

Jim J (morlockhq) wrote :

I can confirm that the delay aspect of this drawer bug still is affecting Hardy Heron. I have Normal Visual Effects checked (compiz-fusion) under the Appearance Preferences. when I click on a drawer applet that I have added to the gnome-panel, there is a slight pause before the drawer extends and then a slight pause before all the icons are painted into the open drawer.

This behavior DOES NOT happen with the gnome-menus (Applications, Places, System). They appear near instantaneously.

It is a very annoying bug as I make heavy use of drawers in order to clean up my screen real estate.

qo_ (imtimt) wrote :

Yes, this is a particularly irksome bug.

One clue:

1. Add the System Monitor applet to your panel and configure it to display disk usage in a graph.

2. Reboot (to clear out disk cache)

3. Make sure disk usage is low (wait for bootup to settle down, have a lot of memory :-)

4. Click on a Drawer and a distinct spike is seen in the Disk graph

After several clicks on the same Drawer you won't see the bump since the
icon is cached by (guessing) the disk cache, file sytem driver or OS or ???

Anyway, try that and see if you get the same results. I could be imagining it...

Thanks,

qo

qo_ (imtimt) wrote :

Naw, nevermind. I think I was imaging it or it was just coincidence :-/

Sorry!

qo

russlar (rgillette0) wrote :

I have the exact same symptoms as Jim J. Any word on this bug being fixed on 8.10?

Dave Vree (hdave) wrote :

Can confirm this bug in Intrepid -- very annoying 2-3 second delay before opening. We're coming up on its 18 month anniversary....

Danilo Costa Viana (dcviana) wrote :

I also confirm this bug is in Intrepid, minus the three chicks necessary t open the drawer. Here the only problem is the delay.

Same setup: Drawer + compiz-fusion

Jebtrix (jebtrix) wrote :

I don't have to click 3 times to open the drawer but I do have the 3sec delay in 8.10. Its ashame because it makes it unusable imo.

I can confirm the issue with the long (2 seconds in my case) delay between clicking the drawer and completely expanding the drawer.

My system:
* interpid
* drawer
* compiz for advanced desktop effects

opening other panel items (tomboy, menu, right-click, ..) does not give any problems.

Disabling the desktop effects resolves this issue.

cccccccc (cccccccc) wrote :

I confirm this bug too. I use compiz (like everybody does), Ubuntu 8.10.
I hope this will be fixed sooner than standard half year Ubuntu period.

George Talev (gtalev) wrote :

I also confirm
My notebook is pretty powerful - Dell Latitude E6400, Intel Core 2 Duo T9400/2.54 GHz/ 4 GB RAM, NVIDIA Quadro NVS 160M 512 MB/
Ubuntu Intrepid (8.10), Compiz
Running on AC power, power profile configured for full performance.
Clicking on a drawer icon (in my case I do not have shortcuts to files, just launchers) leads to the following:
the drawer pops up a little (e.g. 30 pixels), then 2 seconds delay after which it is fully expanded.

Jeremy von Hoff (jvonhoff) wrote :

Confirming, but with some info.

1. open gconf-editor and go to /apps/panel/toplevels/panel_0(for me)/
2. uncheck "enable_animations"
3. click the drawer and you'll get a normal popup of the drawer, but it's located in the top left corner of the screen
4. check "enable_animations" again
5. click the drawer. Nothing pops up.
6. uncheck "enable_animations" again.

7. click the drawer. Now, it pops up quickly, and in the correct place... but only once.

Perhaps this is some help? This bug is sneaking up on 1 year...

I notice similar behavior - the first time I open the drawer after
booting up/logging in, it's as fast as it should be. Subsequent times,
however, are slow like it's got molasses in its rails.

Eric Burgess (ericdb) wrote :

Same here, although disabling animation had no effect, either on the animation or the location of the drawer.

Intrepid, Compiz

Matt_H (matt-heimbach) wrote :

I just started using a drawer to save some space in an attempt to go from two panels to just one at the bottom. I'm getting the same behavior.

I have always had compiz disabled.

I read a recommendation to put a file in the home directory that sets the panel_delay to zero, but that only changes the speed of the drawer after the initial delay. Since it also has the bad side effect of expanding all of the menus even when I'm just moving my pointer past them to get to another menu item, I got rid of that file.

I'm experiencing the same thing as Jordan Erickson in that the very first time after a reboot or log out/in, the drawer expands perfectly, without any delay. All subsequent times it has the initial delay.

Raumkraut (raumkraut) wrote :

I get the same experience with Jaunty (9.04).
However, there even seems to be a delay/pause in opening the drawer after Compiz is turned off. The delay without compiz is much reduced though - less than a second, I'd guess.

peter pan (clarcraft) wrote :

I can confirm this for Jaunty too.
About one second delay before drawer opens.
Compiz is activated.
This is not nice.
If anyone needs further information to solve this, just ask.
-pan

Travis Watkins (amaranth) wrote :

As stated in the upstream (GNOME) bug report this is a bug in the panel and working around it in compiz would break the whole purpose of the sync request protocol.

Changed in compiz (Ubuntu):
status: Confirmed → Invalid
Martin Albisetti (beuno) wrote :

Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.
A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10

Changed in hundredpapercuts:
status: New → Invalid
Jordan Erickson (lns) wrote :

So I think we've narrowed this down to gnome-panel (Ubuntu at least)...?

Can we get people to comment on whether this affects more than Ubuntu? I don't have any other distributions as virtual machines (I will soon, but...) so if anyone is using Fedora, Debian, openSuSE, etc. can you quickly add a drawer to the Gnome panel, add some items to it, then open/close it and report whether this bug is present there as well? Let's get this thing taken care of, it's been way too long since this bug has been reported. I'd rather see no drawer at all than having a broken/sludgy one! =)

Andrew (andrew-machinedyn) wrote :

Martin Albisetti wrote:

"Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.
A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10"

This reduces the functionality/purpose of drawers to near 0 for me as I can't wait for the delay. I think if a poll was done, that probably upwards of 50% of people would abandon using drawers for the same reason. Why don't you just remove the drawer feature from ubuntu?

Jordan Erickson (lns) wrote :

I can confirm myself that this happens in Fedora 11.. If everyone can comment on the Gnome Bugzilla report at http://bugzilla.gnome.org/show_bug.cgi?id=514298 maybe we can get some more heads in the game.

Jim J (morlockhq) wrote :

I partially agree.

This drawer delay has been around FOREVER and no movement whatsoever
has been made on it. It seems as if the bug is well documented with
various cases where the behavior does and does not appear (seems to be
tied to compiz as the drawers behave as expected when compiz is turned
off).

As drawers are used by a lot of people and compiz as well, it affects
all those people.

A seemingly small fix would affect a lot of people.

This bug has been open for a long time and gets a lot of comments.
There is interest here.

On Thu, Aug 6, 2009 at 11:59 AM, Andrew<email address hidden> wrote:
> Martin Albisetti wrote:
>
> "Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.
> A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10"
>
> This reduces the functionality/purpose of drawers to near 0 for me as I
> can't wait for the delay. I think if a poll was done, that probably
> upwards of 50% of people would abandon using drawers for the same
> reason. Why don't you just remove the drawer feature from ubuntu?
>
> --
> Gnome drawer applet delays and unresponsiveness
> https://bugs.launchpad.net/bugs/108951
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The GNOME 2 Panel: New
> Status in One Hundred Paper Cuts: Invalid
> Status in “compiz” package in Ubuntu: Invalid
> Status in “gnome-panel” package in Ubuntu: Triaged
>
> Bug description:
> The drawer applet in the panel behaves weirdly.
>
> When first added to a panel (either the panel in the top of the screen or the one in the bottom of the screen), everything looks good. But after adding to the drawer a link to a simple text file (so that, when clicked, gedit opens with this textfile), opening the drawer requires up to three clicks in the applet (the applet wont open until the third click). And even then,  the drawer opens just a bit and then some three seconds later it fully opens showing its contents.
>
> I have a feisty fresh install. Exactly the same thing happened to me with Edgy and Dapper before. Hopefully it can get fixed for the next release :)
>
> thanks
>

Jordan Erickson (lns) wrote :

@Jim: This bug is not tied to Compiz. I have experienced this bug on numerous releases of Ubuntu as well as a 'stock' F11 install without Compiz enabled.

Adam Bolte (boltronics) wrote :

I stopped using drawers a long time ago due to this bug. It's a real shame that netbook users (which place a high value on screen real estate) have been unable to use this feature due to the unrealistically slow performance. If the sliding animation is the problem, why not remove it completely and have it appear instantly just like the main menu?

Daniel Castro (castromd) wrote :

I confirm this on 9.04 as well. Very annoying. If I have to choose between compiz and drawer I stick with compiz and ditch the drawer. Which is a shame as it is a very nice and useful feature when it works.

thefluxster (buy-ikentech) wrote :

Confirmed. Annoying indeed - delay here is definitely NOT desirable in terms of usability.

Jordan Erickson (lns) wrote :

I'm giving up on this personally. Obviously no Gnome devs give a sh*t about it, even with the triaged bug report on Gnome Bugzilla.

Daniel Castro (castromd) wrote :

Obviously we are all very annoyed by this and it looks like it won't be fixed. So... has anyone found an alternative?

Jim J (morlockhq) wrote :

This is actually really sad.

It seems like the nature of the problem is well understood. There is a
ton of confirmation. The exact area that needs to be fixed has been
identified, but the responsible parties just point fingers at each
other.

Oh well.

If they have another Paper Cuts jam, I am definitely submitting this
bug report. It is HUGE now.

On Tue, Oct 20, 2009 at 3:23 AM, Daniel Castro <email address hidden> wrote:
> Obviously we are all very annoyed by this and it looks like it won't be
> fixed. So... has anyone found an alternative?
>
> --
> Gnome drawer applet delays and unresponsiveness
> https://bugs.launchpad.net/bugs/108951
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Desktop panel for GNOME: New
> Status in One Hundred Paper Cuts: Invalid
> Status in “compiz” package in Ubuntu: Invalid
> Status in “gnome-panel” package in Ubuntu: Triaged
>
> Bug description:
> The drawer applet in the panel behaves weirdly.
>
> When first added to a panel (either the panel in the top of the screen or the one in the bottom of the screen), everything looks good. But after adding to the drawer a link to a simple text file (so that, when clicked, gedit opens with this textfile), opening the drawer requires up to three clicks in the applet (the applet wont open until the third click). And even then,  the drawer opens just a bit and then some three seconds later it fully opens showing its contents.
>
> I have a feisty fresh install. Exactly the same thing happened to me with Edgy and Dapper before. Hopefully it can get fixed for the next release :)
>
> thanks
>

Ryan Thompson (rct86) wrote :

This will likely not be fixed, with GNOME 3.0 on the way, with GNOME
Shell and such.

sn0re (ferrigno) wrote :

For anyone who still cares, I've come across something of a workaround. As was said above, if you disable animations through gconf-editor, the drawer shows up, just in the wrong place. To solve that problem, I've taken to forcing the drawer to the right place using Compiz's force window feature.

Jason McVetta (jmcvetta) wrote :

I think we all still care; we've just given up hope of anyone fixing it.

My workaround is to create a "Quick Start" folder in the Gnome menu, populate it with the same apps I would have put in the drawer, then put that folder into my toolbar. The look is quite a bit different than the drawer, but it provides similarly easy access to frequently used applications.

Daniel Castro (castromd) wrote :

Jason - can you elaborate more?
What do you mean under Gnome menu? Under applications?
When you say 'put that folder into my toolbar', do you mean into the panel?

Thanks!

qo_ (imtimt) wrote :

Hi Daniel,

Yes, that's what he means. I'm not sure if I can add an attachment, but I'll try:

If you can see the attachment, here's how you go about it:

1. Right-click on the Gnome Application menu
2. Select "Edit Menus"
3. Edit to taste
4. Now, from the Gnome Panel, right-click and select Add to Panel
5. Select the Application Launcher option
6. You'll now see the menu item as one of the options you can add to the panel

Regards,

Allen

On Jan 7, 2010, at 6:47 AM, Daniel Castro wrote:

> Jason - can you elaborate more?
> What do you mean under Gnome menu? Under applications?
> When you say 'put that folder into my toolbar', do you mean into the panel?
>
> Thanks!
>
> --
> Gnome drawer applet delays and unresponsiveness
> https://bugs.launchpad.net/bugs/108951
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Desktop panel for GNOME: New
> Status in One Hundred Paper Cuts: Invalid
> Status in “compiz” package in Ubuntu: Invalid
> Status in “gnome-panel” package in Ubuntu: Triaged
>
> Bug description:
> The drawer applet in the panel behaves weirdly.
>
> When first added to a panel (either the panel in the top of the screen or the one in the bottom of the screen), everything looks good. But after adding to the drawer a link to a simple text file (so that, when clicked, gedit opens with this textfile), opening the drawer requires up to three clicks in the applet (the applet wont open until the third click). And even then, the drawer opens just a bit and then some three seconds later it fully opens showing its contents.
>
> I have a feisty fresh install. Exactly the same thing happened to me with Edgy and Dapper before. Hopefully it can get fixed for the next release :)
>
> thanks
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/gnome-panel/+bug/108951/+subscribe

Daniel Castro (castromd) wrote :

Ha! Yes!
Nice... exact same functionality but works as expected. Thanks!

Jordan Erickson (lns) wrote :

FWIW, it looks like Gnome 2.29.91 (tested in Ubuntu Lucid) fixes this issue. It has a very small delay but it isn't anywhere near as bad - looks like it just takes a second to slide out (probably making it actually look like an opening drawer - very smooth).

thefluxster (buy-ikentech) wrote :

*If* Gnome 2.29.91 fixes the problem, has anyone confirmed if it's slated for for Lucid Lynx? I saw some forum posts saying it was accepted, but it'd be nice to know if it's confirmed. If so, has anyone tested this out in the Beta?

Jeremy von Hoff (jvonhoff) wrote :

I just tested this with a fully-up-to-date Lucid install (Gnome 2.29.92), and it is *not* fixed. The attached film should show that.

Ryan Thompson (rct86) wrote :

I'm getting the feeling that drawers are, for all intents and
purposes, deprecated. If anyone more informed than I has knowledge to
the contrary, please speak up.

On Wed, Mar 24, 2010 at 3:49 PM, Jeremy von Hoff <email address hidden> wrote:
> I just tested this with a fully-up-to-date Lucid install (Gnome
> 2.29.92), and it is *not* fixed.  The attached film should show that.
>
> ** Attachment added: "gnome drawer still lags when opening"
>   http://launchpadlibrarian.net/41884197/out.ogv
>
> --
> Gnome drawer applet delays and unresponsiveness
> https://bugs.launchpad.net/bugs/108951
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

tc7 (theocleminson) wrote :

I've reverted to no visual effects after Lucid upgrade (I'd forgotten the reason I'd disabled this in Jaunty - but remembered after I went digging to resolve the reluctant draw open issue).

Would be nice to get this one fixed at some point - it's amazing how even a simple usability issue like this can cause frustration for everyday users (close/min/max icons on the left is another - but at least that can be reversed).

manatlan (manatlan) wrote :

Yeeeeeeeeee ! I've got this bug for years ...
Very very annoying ... I thought I was the only one ;-)
It' not usable ! It's sad ;-(

(Drawers worked well in Gnome1)

Changed in gnome-panel:
importance: Unknown → Medium

I worked around the drawer opening delay by hardcoding the animation time to 0 in gnome-panel sources. I don't think this can be considered a proper fix, but at least it makes drawers usable again. Patch attached.

How to build the patched .deb file (Ubuntu 10.04, gnome-panel 2.30.2):

sudo apt-get build-dep gnome-panel
apt-get source gnome-panel
cd gnome-panel-2.30.2
patch -p1 < ../gnome-panel.drawer.patch
dpkg-buildpackage

Chris (xtoast) wrote :

Here is another video of the bug, present in Ubuntu 9.10/gnome 2.28.1.

Worth noting: the first drawer expansion immediately after creating a new drawer has no delay. All following drawer expansions have a delay.

tags: added: patch
Changed in gnome-panel:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.