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 ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
