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 :)
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...
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 :)
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.
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.
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!
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?)
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 :)
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.