KDE panel showing above some fullscreen applications

[Duncan]

Dotan Cohen posted on Thu, 01 Mar 2012 18:40:58 +0200 as excerpted:

> On second thought, setting "Always on top" did not work. Virtual Box is
> still shown (sometimes) below the panel. This is rather indeterminate, I
> cannot figure out under what conditions Virtual Box will be below and
> under what conditions Virtual Box will be above the panel.
> 
> Might this be a bug in Virtual Box?

FWIW, always-on-top is a togglable (binary-state) window flag.   A panel 
set to cover windows has that flag set, as does an app set to always-on-
top.  Thus, while both the window and the panel with the always-on-top 
flag set will appear above ordinary windows without that flag set, which 
one is on top of the other depends on other factors like raise-on-click 
(if that's the behavior you've set in window behavior), etc, generally 
the same ones that govern which normal window is on top of the normal 
window stack, only this stack always appears above normal windows, but 
it's still a stack, too.

So it's not so much a bug in virtual box, as an inability for a binary 
always-on-top flag to store more than a binary "stack-topness priority".  
If anything, it would be a bug in either X, which defined that flag as a 
binary, or kwin, which could in theory define its own non-binary stacking 
rules, and expose them as a user-configurable option as it does with 
other "window rules".

> As a workaround, is there any way to remove a panel from a particular
> desktop. I considered using a different activity for Virtual Box, but I
> found that cumbersome for my usage profile.

FWIW, with dual monitors (stacked, FWIW, since they're widescreens, MUCH 
wider than they are high and I have the height to spare but not the 
width, on the wall they're mounted on), I used to run some apps full-
screen across both monitors and had the same problem.

Back in kde3 era, there was an option that turned on a button at one or 
both ends of the panel, that when clicked, would hide away that panel to 
that end, leaving only the few pixels of button exposed to bring it back, 
when one was thru with the full-screen app.

Unfortunately, I've yet to see something similar for kde4's plasma 
panels, either built-in (as I believe it was in kde3's kicker panels) or 
as a plasmoid -- and believe me I looked on kde-look for one, tho it has 
been awhile!  That's one of the still BADLY missed bits of kde3, here.  
Oh, well...

Of course it's possible to fiddle with the panel config *TWICE* each time 
you run such an app (once to set the panel to windows cover before 
starting the app, again after you're done to set the panel back to always-
on-top), but THAT GETS OLD VERY FAST, as I'm sure you've found, 
especially so since the panel settings popup, which some would argue it's 
more intuitive than the kde3 standard dialog, is DEFINITELY more "fiddly" 
and temperamental than a standard dialog (accidently slip off the popup 
and over another window with the mouse, so the other window gets focus, 
and the popup disappears!).

And at least back then, activities configured the desktop only, not 
panels, which were either there or not, regardless (that was supposed to 
change with 4.8 or so, activities were supposed to handle panels too, but 
I've not tried activities lately to see if it has or not), so activities 
wasn't a solution either.  Believe me, I thought of that and tried it!

In some cases, especially if the panel is relatively small, setting it to 
autohide works, but if the panel's a third the size of the monitor (the 
biggest it could get, back then, I've not tried a bigger panel recently, 
either), triggering the auto-unhide tends to be WAAAYY too easy, and 
moving WAY across the screen just to let it hide again, WAAYYY too much 
of a hassle, for THAT to be a reasonable alternative.  Believe me, I 
tried that too!

ARGH!!

The workaround solution I came up with was:

1) killall plasma-desktop (or plasma-notebook, if you're using it 
instead), when you need the full desktop.

Note that both khotkeys and krunner are NOT part of plasma-desktop and 
thus should still be available.  Thus, it's still possible to use krunner 
to launch apps if desired, and if you have a hotkey system setup as I do, 
to launch all my usual apps quite apart from using the various launcher 
plasmoids (kickoff, lancelot, classic menu, the various button-launcher 
plasmoids, etc), really, you'll probably find plasma-desktop isn't 
anywhere NEAR as necessary as one might at first believe.

Of course, if you prefer you can keep a konsole window open, or launch a 
copy of your favorite launcher plasmoid in a window using either 
plasmoidviewer or plasma-windowed.  (Both those utilities allow running a 
plasmoid in a normal window instead of in plasma, but there's some 
differences in options available, etc.)

The point is, there's quite a few options for launching apps, etc, that 
don't depend on plasma-desktop/plasma-netbook.  Pick and configure one or 
more, and you'll find running without plasma-desktop/notebook actually 
quite practical!

2) Use the full-screen app as desired.

3) When done, use krunner or whatever to relaunch plasma-desktop (or 
plasma-notebook, if you're using that instead).


It's not ideal, the little hide-away buttons that kde3's kicker had were 
far closer to that, here, but it ABSOLUTELY POSITIVELY beat fiddling with 
panel properties twice per full-screen app!

Other alternatives:

1) As I mentioned above, plasma is /supposed/ to get activity-associated-
panels at some point, and it MAY actually have them now, I've not 
actually tried activities since 4.8 (or even 4.7, really), so I can't say 
for sure.  But if/when that works, it should be preferable to the 
admittedly rather drastic killall plasma-desktop solution that I had 
used, and still use occasionally.

2) Panel auto-hide, again mentioned above, but there's a serious hassle 
factor if the panel's large and you're not careful with the mouse.

3) There's a command-line and scriptable utility called wmctrl, that 
allows scripting window placement, etc.  If you don't have it installed 
and don't already have at least passing familiarity with it, I *HIGHLY* 
recommend that you install it and get at least familiar enough with it 
that you know the basic stuff it can handle.  In this case, it's worth 
noting that each plasma panel is in fact its own window, normally with 
the X dock property set, thus a panel's affinity for "docking" to a 
side.  As such, it's possible to script the panel's size and placement 
via wmctrl, and to setup two such scripts, one that FORCES the panel out 
of the way, temporarily, another that puts it back in the usual 
location.  This is the sort of "power-user" type solution I just might 
work up myself, if I was still using full-screen mode to the same extent 
that I was.

4) With multi-monitors, full-screen mode (as well as, optionally, 
maximize) normally full-screens to just ONE monitor.  Depending on the 
application, for instance, an emulator such as virtual-box, full-
screening to just one monitor of a multi-monitor setup may be just the 
ticket, leaving the other one with the normal kde desktop, panels, etc.

The way I have my monitors setup here, stacked, with the "system activity 
and auxiliary" monitor on top of the "working" monitor, full-screening 
(or maximixing) to one monitor works well indeed.  Nearly everything I 
might normally access, plus superkaramba for system monitoring, etc, is 
on the top/auxiliary monitor.  The lower/working monitor is thus 
generally free of desktop plasmoids (there's a comic plasmoid, but most 
comics update once a day so other than that it might as well be 
wallpaper).  It has one rather small auto-hide panel in the lower left 
corner, containing kickoff and a classic menu plasmoid set to bookmarks-
only, but those buttons and the panel itself are small enough that 
autohide isn't a big deal for that panel.  Plus, lower left corner isn't 
something I hit that frequently by accident, so in general, it only tends 
to trigger when I want it, and if it does trigger accidentally, a bit of 
movement and it's hidden again.

That leaves the bottom/working monitor free for either two half-maxed 
apps tiled side-by-side (kwin's drag-to-side half-max functionality works 
*VERY* well with this), for things like browser windows, list replies, 
konsole windows, etc, or a single maxed/full-screen app, covering the 
entire bottom monitor.

Given that the monitors are full-HD (1920x1080), this works /perfectly/ 
for full-screen media-players and the like, letting them full-screen to 
the bottom monitor, while the top one remains free, displaying CPU usage, 
etc, while playing the video, allowing file-manager browsing in the top 
monitor and drag-n-drop from there to the full-screen media player on the 
bottom monitor, etc.  Alternatively I can do the two-half-maxed windows 
thing on the bottom/working monitor, while playing a video in a window on 
the top monitor, if I'm multitasking.

But of course there's some apps that work even better when spread out to 
two monitors.  This is the problem I was having, originally, and the 
reason that I was using killall plasma-desktop.  But I'm using the next 
solution for this sort of thing most of the time now, so don't use the 
killall plasma-desktop workaround NEARLY as much as I used to.

5) With the now reliable OpenGL based zoom effect (configured in desktop 
effects, middle tab), I've switched to using this a lot more, these days, 
tho it was too buggy thru early 4.5 or so, and only became reliable 
enough to use it as much as I do with late 4.5.  Of course, the 
suitability of this alternative depends on the otherwise full-screen task 
you're doing, but for many tasks, simply running them windowed at a lower 
resolution, then zooming in using the zoom effect, works very well, at 
least on semi-decent hardware/driver combinations like my Radeon hd4650 
with the freedomware kernel-drm/kernel-mode-setting(kms)/mesa/xf86-video-
ati drivers.

This zoom effect is the reason for the past-tense in the killall plasma-
desktop instructions above, as zoom works as well or better for the use-
case I was using it for most, anyway.

I DID tweak the zoom-step to a reasonably fine 5%, but since I've 
configured good hotkeys that auto-repeat if I hold them down, thus giving 
me a quite smooth continuous zoom, the fine zoom-step still works great.  
(FWIW, the hotkeys I use for that are ctrl-meta-arrow, where arrow is 
down to zoom out, up to zoom in, and left to reset to normal/100% zoom.  
Meta is of course the winkey on most current x86 keyboards.)

Between the dual-monitor, full-screen-to-one, alternative, and the zoom-
effect alternative, depending on what I'm using it for, I really don't 
use the killall plasma-desktop workaround much at all, any more.  Still, 
it's there when I do need it, and at times cycling plasma using a killall 
and relaunch is handy for forcing it to save settings, etc, without 
exiting kde entirely, as well. =:^)

-- 
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.