[kde-linux] Wandering panel (top of screen) in KDE-4.7.3 +

[Duncan]

Dag Nygren posted on Thu, 17 Nov 2011 11:43:49 +0200 as excerpted:

> torsdag 17 november 2011 07:42:58 skrev  James Tyrer:
>> I have had a panel at the top of the screen for some time now.  It is
>> one of the few things that I like about GNOME.
>> 
>> And now with 4.7.3, I find that if I set it to: "Auto-hide" that it
>> does not stay at the top of the screen when it unhides but rather takes
>> positions farther down the screen directly beneath other windows that
>> are open.  This includes the vertical panel on (my) right that contains
>> nothing but a clock and a spacer.
>> 
>> This is clearly some sort of REGRESSION, but I no longer report bugs
>> since the argument over fixing KDESU.
> 
> Yes. I have the same thing. The regression is earlier than 4.7.3 though.
> I also entered this as a bug in KDE bugs.

Confirmed here as well.  But for me and others, the bug first hit around 
4.6.2.  I actually bisected it down to a specific commit, and expected 
that since it appeared in a bug-fix only release and I had bisected it to 
a specific commit, the fix would appear within two such bugfix releases.

Seems I was wrong.  The bug survives into 4.7 and continues to affect new 
people.

That's actually a clue that something's triggering it, as is the fact 
that when I forced the location using the below workaround for awhile, 
eventually I could go without the workaround for awhile, until something 
triggered it again...

The basic problem seems to be that kwin and plasma are fighting over what 
X's "dock window type" means.  Panels are normally dock-window-type, 
which as the name implies, normally dock to a display edge.  Only for 
some reason, plasma seems to be overriding some property (they still say 
dock window type, but...), and kwin is attempting to use its default 
smart-window-placement for them.  Thus, if there's already an existing 
non-maximized window at the top left corner (which is the default 
placement for the first window, so this isn't unusual) when the panel 
appears (either at plasma startup or unhides if auto-hide was turned on), 
kwin will treat the panel as a normal window and try to smart-place it to 
avoid covering another window as much as possible, thus placing it below 
and/or to the right of already existing windows.

There's apparently quite a few related existing bug reports on the same 
general bug, in part because the behavior appears slightly different for 
different people.  As such, the same general workaround (as reported on 
at least two of the bugs) applies, but it too must be slightly different 
for different people, so some experimenting will likely be necessary.

Bugs:

(Someone else's)
Autohiding panel sometimes moves to middle of the screen when being viewed
https://bugs.kde.org/show_bug.cgi?id=272663

(Mine)
[Regression][Bisected]
4.6.1 to 4.6.2 libkdeinit4_plasma-desktop.so panel placement
https://bugs.kde.org/show_bug.cgi?id=271532

As you can see from the comments on mine, after I found the workaround 
(below) and discovered that it seemed to work fine without the workaround 
after awhile (so I thought it was fixed), I tried to close it, but others 
said it was still happening to them on current versions, so I reopened.

Workaround:

I'd like to claim this as my idea but unfortunately can't.  I don't 
(didn't) normally think of panels as windows, so the thought of using 
window rules didn't occur to me until I saw someone else post that it 
worked for them in a comment on IIRC that first-listed bug.  Never-the-
less, I had to modify the specifics to get it to work for me, so at least 
part of the solution is mine. =:^)

Create a new window rule (kde settings, workspace appearance and 
behavior, window behavior, window rules, or get to the same place using 
the window menu on a normal window, configure window behavior, window 
rules).  Hit the new button.

In the resulting edit window-specific settings dialog, click the detect 
window properties button, then click on the panel in question.  (Note 
that if you have the panel set to autohide, you may wish to temporarily 
change it to always visible in ordered to make clicking on it easier.)  

If you have multiple panels, you'll probably want the rule to only apply 
to one.  The distinction between panels is "Window Role", with 
"panel_N" (where N is a number) being the role.  Each panel has its own N-
number, so that's the critical bit to match if you only want it to apply 
to one panel but you have several.  So you want to match window class and 
window role.

OK out of the picker dialog and check the rest of the window matching tab 
(this GUI changed between 4.6 and 4.7, I'm describing 4.7, those still on 
4.6 will have to adapt the instructions somewhat as a result, it's the 
first two tabs, there, IIRC).  In particular, you probably want to make 
sure the rule only applies to the Dock (panel) window type, just in case 
you somehow get a normal window that would otherwise match the rule.  Set 
the description to something else if you like, as well.  (You may wish to 
label it so you know what panel the settings are for, for instance, if 
you have multiple panels.)

Once you have it setup to select the right window, you have to tell it 
what to do with the window.  In this case we'll be using the size and 
position tab for that.

Here's where the bit of experimentation comes in.  In the original bug 
comment reporting this as a workaround, they said that setting initial 
placement, force, no placement, worked for them.  That didn't work for 
me.  Instead, I set position, force, 0,0 (thus the top left corner).  
That's what worked for me.

That's the workaround.  OK the dialog, hit apply in window rules, and see 
if that fixes the problem for you.


Meanwhile, one caution.  Using window rules like this by definition 
overrides the normal application settings.  In particular, if you force 
the window position, as I did, attempting to move the panel to a 
different screen edge using the normal plasma panel settings method isn't 
going to work.  You'll need to remember that you used a window rule to 
force the position, and disable that first, if decide you want to move 
the panel elsewhere.  Because plasma isn't expecting to be overridden 
like this, attempting to move the panel to a different edge with the rule 
forcing the position may have "interesting" results.

Hope that helps.  The workaround works fine for me.  No more panels 
moving around when I didn't move them!  Just remember that you might need 
a bit of experimentation to get it right.  FWIW, no window placement, if 
it works for you, is probably a safer alternative to the forced 
positioning that worked for me, since the former interferes less with 
plasma's internal expectations.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman