On Fri, Mar 2, 2012 at 05:54, Duncan <1i5t5.duncan@xxxxxxx> 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, I
> tried that too!
>
> ARGH!!
>
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. =:^)
>
My God, Duncan, have you not thought of everything? However, for my
particular workflow each solution has more problems than it solves. I
just need the blessed panels to stop showing above full-screen apps!
If it happens again (and it will) I'll grab a screenshot and file a
bug,
Thank you. Have a great week!
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
___________________________________________________
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.
