Re: [kde-linux] Wandering panel (top of screen) in KDE-4.7.3 +
- Date: Thu, 17 Nov 2011 14:50:47 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] Wandering panel (top of screen) in KDE-4.7.3 +
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
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.
Autohiding panel sometimes moves to middle of the screen when being viewed
4.6.1 to 4.6.2 libkdeinit4_plasma-desktop.so panel placement
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.
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
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
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.