On Fri, Mar 2, 2012 at 05:54, Duncan <1i5t5.dun...@cox.net> wrote:
> 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.
>
Thanks. I have my main panel set to "Always visible" so that Maximized
applications do not refer to the panel's space as being available. I
also have another panel set to "Windows go below" however this tiny
panel only covers a small part of the windows' title bar. Based on
your analysis I would expect the "Always visible" panel to go below
the "Keep Above Others" window, and in any case, no matter what the
settings, I would expect all panels to be below fullscreen
applications.
Frustratingly, or possibly not frustratingly, I cannot reproduce the
issue right now to check the state of my smaller panel. In other
words, it works when I don't want it to and breaks when I want it to
work!
> 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".
>
Does the X spec, or Kwin, specify whether full-screen apps or Always
on Top panels should have higher Z-axis values? Where would I even go
to look this up myself? I cannot find anything pertinent to X or Kwin
from the mighty google, though lots of irrelevant MSDN results do show
up.
>> 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...
>
Manual hiding of panel
https://bugs.kde.org/show_bug.cgi?id=158556
This is relevant too:
Screen corners to un-hide panels
https://bugs.kde.org/show_bug.cgi?id=185318
> 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!).
>
Additionally, I have the fullscreen app on one desktop but other apps
on another desktop. So "temporarily" changing the panel settings means
that I will be annoyed on the other desktop.
> 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!
>
I also found that Activities do not affect the panels. So even that
workaround is moot.
> 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,
