New Strut Behavior on Auto-Hide Panels (upstream) is Undesirable for Users (and annoying)

[K. Lange]

Binary package hint: gnome-panel

(reported upstream by someone else here: http://bugzilla.gnome.org/show_bug.cgi?id=546835)

The new strut behavior for auto-hiding panels causes the available desktop space to update as they animate, squishing full screen windows as the panel appears. DO NOT WANT. This is annoying, undesired, and impossible to turn off without recompiling. The behavior was added to fix a bug that "doesn't exist" such that it does not present itself in the top 90% of usage scenarios and is a "tough luck" deal for those who may actually see it (has to do with setting auto-hide size > 1/2 the panel size, which clearly defeats the purpose of the auto-hide).

The request here is to either ignore this change from upstream and add in the two-line exception for auto-hide panels, or to add an option available through gconf to disable/enable this change.

gnome-panel: 2.23.6
Ubuntu Intrepid

Steps to reproduce:
- Set a panel to auto-hide
- Full screen a window
- Show the panel
Expected results:
- Nothing happens to the full screen window, as it's been for the past 8+ years.
Actual results:
- My entire machine slows down as Firefox is forced to re-render all of its contents thirty different times as the panel resizes it during its animation phase. Compiz also makes it jump in strange ways (and we're not going to fix it).

So, in conclusion, DO NOT WANT, please, Ubuntu packagers, ignore this horrible commit from upstream!

[Dylan McCall (dylanmccall)]

If this is turned into a gconf option, the functionality is still broken. The strut should only need to change once; to the end point. While it means we don't get a nice smooth animation, it will probably feel smoother anyway because resizing windows is a very costly operation for the time being.

In addition, I think this may give us some serious usability problems. If the struts are changing when the user opens the panel, this means that everything on his desktop is unexpectedly changing position as well! What if he decides to close a window after opening the panel? User moves mouse off the panel, onto the close button, and holds there for a bit. Suddenly the panel closes and everything goes back to where it was, all before the user can react. He accidentally clicks the "format my hard drive" button instead.

Lame example, but the only things which should move are those that the user directly tells or expects (within reason) to move. Anything more causes immense confusion.

[K. Lange (k-lange)]

In response to Dylan McCall, should the animation behavior be changed, there is a slim (but possible) chance that I would accept this. Probably not, but it's a start.

It seems like the following should be done:
1. Add an option to gconf, bool, 'update_autohide_strut', default = disabled (because users don't like change forced upon them as default values, this is a known fact of creating a new release)
2. Change current behavior to update after animation cycle. (which would improve performance when the option is enabled)
3. Add in original exception when gconf option is disabled. (because that's the entire point of this bug report)
4. ...?
5. Profit.

On another note, the last bit of my original report is a simple joke, and no hard feelings are meant towards Vincent Untz for what he did, even if I am a bit ticked off about it. It's not like this is a closed-source app I'm forced to use - I can go and 'fix' it for myself, just as I did.

I also have a forum topic running for any less-pertinent discussion of the bug: http://ubuntuforums.org/showthread.php?t=885625

[Gilberto Olimpio (golimpio)]

When I first install Intrepid I thought that this panel behavior was a bug, not a fix. That's the most "odd fix" I had saw.

[Sebastien Bacher (seb128)]

the bug is fixed in gnome-panel 2.23.92 in intrepid now