panel

[Duncan]

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.