András Csányi posted on Mon, 08 Aug 2011 09:50:55 +0200 as excerpted:
> Dear All,
>
> This is my first letter here. I have been using KDE more-less 4 years
> and I like it very much. Easy and good for me. :)
> Now I have a question and the answer could be obvious.
>
> I'm using KDE-4.7.0 - gentoo release with "~amd64" keywords.
=:^) Same here.
> I have to monitors and I set up the panel the right side of the left
> monitor.
FWIW, two monitors here, too. Both 22-inch full-HD (1080p aka 1920x1080)
LED-lit LCDs (same brand and model, too, viewsonic vx2250).
Except I have mine stacked, for a 1920x2160 overall desktop. The bottom
one is my "working" monitor, only a small auto-hide panel at the lower
left, with only kickoff and a classic menu set to show bookmarks.
Browsers, etc, get drag-to-edge half-maxed so I can have two side-by-
side, while three-pane mail (claws-mail, I got tired of the resources the
newly akonadified kmail requires so just switched to claws about a week
ago), news (pan), and feed-reader (a second claws-mail instance with
different settings and the feed-reader plugin, no mail actually setup in
it, FWIW, the plan is to akonadify akregator too, and I needed to dump
all kdepim in ordered to kill the semantic-desktop USE flag and
associated dependencies entirely, so I ended up dumping akregator as
well) set to almost-max use kwin window-rules to force-horizontal max,
almost vertical-max, positioned at the bottom of the monitor when open so
there's just enough room for the half-maxed title-bars of a browser or
konsole window to show above it, thus allowing me to switch between them
reasonably easily. The only plasmoid I have on the lower monitor desktop
is comic-strip, which can be covered without issue most of the time since
the comics normally only change once a day.
The top monitor is my "system and overflow monitor". Across most of the
top of it I have a superkaramba theme plotting user/system/nice/wait/
total CPU usage for each of my four cores, app/cache/buffer/total memory
usage, 1- and 5-minute load averages, disk-temps for the four drives in
the RAID, the four core temps plus graphics temp, system temps at five
different locations within the system, fan-speed for four fans, four
successive net-speed plots of Rx and Tx, each one maxing at 2^3 (=8)
times more than the previous one so I can see even minor traffic at idle,
but still reasonably graph full-bore maxing-out-the-pipe-bandwidth, and
text-list the last 20-odd lines of the system messages log, time and date
in both the current time zone and UTC, plus sync and boot dates, the top
five CPU using and top three meory using apps... basically a very nice
system status dashboard. =:^)
That takes most of the top, but I left enough room for a system-tray and
notifier to the left, on a short always-visible panel. Both the systray
panel and the (top-docked) superkaramba are 165 px high, thus leaving
1080-165=915 pixels height (at full 1920 width) for additional "overflow"
windows that won't fit on my bottom/working monitor. However, I normally
keep a good portion of the top monitor desktop accessible and I have a
probably 150ish px wide by full-915-height folderview to the left on the
desktop, a yawp-weather plasmoid at the top right, and a couple quick-
access plasmoid icons, set to the same place but one left and one right
so one should always be accessible. The other reason I nearly always
keep part of the top monitor's desktop clear is that I have the mouse-
scrolling event set to scroll thru the virtual-desktops, that being the
way I normally switch desktops, so having part of the desktop clear to do
so definitely helps. =:^)
FWIW, here's a (slightly bugged early 4.6 era, thus the upload to kde
bugzilla) 1/3-size screenshot of how things looked back when I was using
the yasp-scripted plasmoid instead of superkaramba for my system
monitors. Superkaramba is somewhat more flexible than yasp-scripted,
however, allowing me to reduce the system monitor panel height from 360 px
(1/3 monitor height, the largest a panel would go) to the 165 px I'm
using for superkaramba, without loss of graphing resolution.
http://bugsfiles.kde.org/attachment.cgi?id=59229
Anyway, to your problem:
> Basically the panel is in the center of the whole screen. The
> strange thing is that if I put an application on the left monitor full
> screen the application goes under the panel. I've took a look the panel
> settings and it set up "always visible". I remember there was an option
> the application can go under the panel - I'm sorry I don't remember the
> exact expression. This option is not set up. It looks like the panel
> doesn't behave according to the setup.
>
> Can you tell me how I'm able to reach that the applications don't go
> under the panel? Is it possible?
Since 4.6.2 or so, there have been quite some issues with panel
behavior. It seems kwin and plasma have been out of sync with each other
in their ideas about how the panels work, and while there continue to be
various tweaks to try to fix the problem, somehow, they're not quite
coordinated, and while the problems might change a bit from release to
release, they're evidently still there in 4.7, altho I have a workaround
for the issue I was seeing in the form of a window rule, so I'm not
exactly sure if my original issue is still there in 4.7.0 or not, and
I've not happened to see your issue.
Here's the two apparently very closely related bugs I and someone else
filed, back on 4.6.2 (the screenshot linked above is from mine):
https://bugs.kde.org/show_bug.cgi?id=271532
https://bugs.kde.org/show_bug.cgi?id=272663
As I said, I don't know if those were fixed for 4.7 or not, since I'm
using the suggested window-rules workaround, which effectively corrects
the problem for me (but won't work at least as I implemented it here, for
you). If it was fixed or the code tweaked for 4.7 to try to fix it
(whether they succeeded or not), it may be that tweak that triggered your
bug. Otherwise it might be the same one, just showing up differently.
Either way, the base issue for all of us seems to be that kwin is trying
to treat the panel window rather like a normal window in some respects (x/
y positioning here, apparently z-order stacking for you), instead of
treating it as the docking-class window it is, with appropriate docking-
class placement exceptions.
The simplest workaround, if it works for you, is to use window-rules to
enforce for that window the treatment kwin /should/ be giving it, but
isn't.
Here, the x/y positioning was screwed up, so simply forcing the position
was what I had to do.
In Dmitri's bug, he reported (thus giving me the idea, tho I had to
change it for me, I regularly use window rules for other things but
hadn't thought to try it for this... because I didn't think of panels as
windows, I guess) that setting placement, force, no-placement, worked for
him (but it didn't for me).
Your case is rather different, it's Z-order stacking, and that you don't
want other windows in that area AT ALL, and have it set for that, but
it'd not doing it, that's the problem. Certainly, my workaround, forced
positioning, wouldn't seem likely to work. However, it may be that
Dimitri's original workaround, forcing no-placement for that window, will
work for you. I'm not sure tho as I'm unsure whether window-placement
"per se" is the factor involved here or not.
Try it and see, I guess.
If that doesn't work, I'd suggest playing with some of the other options
to see if you can get something that works. In particular, play with the
ignore requested geometry and obey geometry restrictions options, which I
admit I don't really understand, but I can note that from my experience,
it occasionally takes setting BOTH of those (to opposite values, forcing
ignore on and obey off, or the reverse, obey on and ignore off), in
ordered to get the settings I want honored. Also try playing around with
the window type. Docking-class is what it /should/ be, but as I said,
kwin seems to be treating them like normal windows. So maybe forcing it
to override or some such, will help? I've never gotten window type
forcing to do anything useful here, but perhaps that's just because I
don't really understand the implications of most of them, and haven't had
the right problems for that to solve. (I only learned what docking meant
due to these panel bugs.) Perhaps you'll have better luck, as your
problem is certainly one I've not had, at least in that exact form, but
then, I don't put panels in the middle of my desktop, either. =:^)
If nothing you do playing with window rules seems to help, then maybe
something else will. I mentioned superkaramba, and that it has
optionally docking windows too. As I was learning to work with it here,
I discovered that while plasma panels and superkaramba widgets can both
be docking class, their behavior in regard to how other other windows
(really kwin, as the window manager) treat the borders and avoid going
under or over them is slightly different. I don't understand it well
enough to properly explain, but it's worth noting that I found it useful
to have BOTH the systray plasma panel and the superkaramba docking window
set to top-dock, always-on-top, one positioned to the left, one to the
right, because the behavior with both of them set that way over the same
area at the top of the screen is slightly different than either of them
alone, and something I've found useful.
The trick I have in mind is this: superkaramba can be transparent by
default, so it may be possible to create an empty and thus fully
transparent superkaramba window docked to the same position as your
misbehaving panel. As I said, I don't quite understand the interactions
between the two, but with a bit of experimenting, it may be possible to
arrange it so the plasma panel is on top (if the superkaramba dock-window
was, you could see the plasma panel underneath but not interact with it
since superkaramba would be catching all the actions), but with the
superkaramba panel at the same position underneath it, enforcing the
normal-window-free zone that you want, but that the plasma panel isn't
giving you on its own.
One more alternative to consider, probably easier than messing with
superkaramba, but the effect won't be quite what you are currently trying
to do. Perhaps it'll be close enough, tho, depending on your needs...
Set the panel to "windows can cover" mode, but set a hotkey for one of
its plasmoids. That way, it can be covered, but by pressing the hotkey,
you invoke the plasmoid, thus bringing the panel to the top. If you're
mainly worried about accessing it, that could be workable, if not ideal,
but if you have for example system monitoring plasmoids on it that you're
trying to keep always visible, letting other windows cover it, even if
you can bring it back up with a hotkey, may not be acceptable.
I hope some idea in the above works. Because I know how frustrating it
is to have the panel suddenly behaving way different than you have it
configured for! But even if none of them do, at least you know others
are having similar issues, and you're not alone in your frustration!
--
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 mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
