Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 470719 - gnome-panel starts with all drawers open
Summary: gnome-panel starts with all drawers open
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-panel
Version: 10
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F10DesktopTarget
TreeView+ depends on / blocked
Reported: 2008-11-09 12:41 UTC by Leszek Matok
Modified: 2008-12-07 04:26 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-12-07 04:26:58 UTC

Attachments (Terms of Use)

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

Description Leszek Matok 2008-11-09 12:41:14 UTC
This system got upgraded from F9 to current Rawhide (almost-F10). With all the new GNOME bits, my desktop mostly survived (startup applications needed re-adding and the session splash doesn't move past the "file manager" icon, but those are minor issues).

However, on every login and every `killall gnome-panel`, the panel starts with all the drawers open. It's obviously a regression and I don't think there's a single user wanting this (if I wanted to have the drawers out, I'd just use more top-level panels).

Searching the web, wiki and release notes was fruitless. There's also no upstream bug, so in case this is specific to Fedora, I'll submit it here :)

Comment 1 Leszek Matok 2008-11-09 15:14:48 UTC
Ray, it's your patch that causes this. Recbuilding gnome-panel without gnome-panel-2.24.1-smoother-slide-in.patch fixes things for me...

Comment 2 Leszek Matok 2008-11-09 15:35:53 UTC
Instead of doing:
+		panel_toplevel_queue_initial_unhide (toplevel);
I propose:
+		if (!panel_toplevel_get_is_attached(toplevel))
+			panel_toplevel_queue_initial_unhide (toplevel);

It just worked after a kill, I'll go ahead and test a logout :)

Comment 3 Leszek Matok 2008-11-09 15:50:47 UTC
Err, wrong. The drawers are okay, but there was no animation at all. OK, I'm leaving this, as it's obviously not my area of expertise.

Please, disregard my previous comment and fix drawers your way with the next update.

Comment 4 Ray Strode [halfline] 2008-11-10 04:43:48 UTC
I think that patch is right.

From testing it seams like there's no animation only 

1) If the panel is a drawer
2) If it's the first time the drawer is opened.

In all other cases it seems to animate.  Does that correspond with what you're seeing?

Also, if I back out the entire smoother-slide-in patch I notice that same behavior mentioned above.  So the "no animation on initial unhide of drawer" seems like a separate bug that should get tracked separately.

Comment 5 Leszek Matok 2008-11-10 07:18:32 UTC
I was talking about the real panel animation. When I log in, the animation isn't smooth at all (I just tested logging in and it had like two frames - 20% visible and 100% visible). At first glance I thought there's no animation at all and that my patch broke it.

Maybe it was just slower with all the drawers out, making me perceive it as more smooth? I'll have to hack the panel to use RT priority and see what happens ;)

Of course you're right about drawer bugs. They just sit there for years and what you're seeing is the least disturbing of them. You can safely ignore it :)

Thanks for looking into this bug!

Comment 6 Ray Strode [halfline] 2008-11-10 18:46:08 UTC
well the smoother-slide-in patch makes the panel wait until the applets register before doing the slide in.

It could be that you have an applet that registers early but then does some really slow operation immediately afterward when the slide in happens.

Odd that you'd see a difference with the drawers open though (unless maybe it's an applet in the drawer that's behaving differently?)

Comment 7 Leszek Matok 2008-11-10 19:10:21 UTC
Maybe I perceived it as more smooth because of moving the drawers with the panel that "hosts" them. Maybe the programs that I've later re-added to the startup eat more CPU. Maybe adding window buttons to wnck-applet makes panel slow (and I've noticed things appearing there in the middle of the animation). Maybe all the activity going on presses hard on X itself. All this makes sense and can add to the animation's non-smoothness.

I can confirm it tries to slide in, though, so just ignore my comment where I said there was no animation. It's just not smooth on my computer, which is not a big problem. All I care about here are my drawers :)

Comment 8 Bug Zapper 2008-11-26 05:05:25 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 9 Fedora Update System 2008-12-07 04:26:53 UTC
gnome-panel-2.24.2-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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