Version: 4.7.3 (using KDE 4.7.3) OS: Linux When attempting to use fullscreen mode with a VirtualBox guest, the top center screen edge detection zone grabs focus from the vbox window when attempting to use the pop-out mini toolbar. Disabling desktop switching on screen edges allows the mini toolbar to pop out as expected. Reproducible: Always Steps to Reproduce: 1) Configure desktop switching by screen edges, with a single-row pager so only left and right edges trigger a desktop switch. 2) Start a virtualbox guest that has mouse integration (from the Guest Additions) and switch to full screen. VBox mini toolbar is briefly visible before it auto-hides. 3) Move mouse to the mini toolbar. Mouse pointer changes to host appearance before the mini toolbar is triggered. Move the mouse to left or right screen edge--desktop switches as expected. 4) Disable screen edge desktop switching. Mini toolbar now pops out when the mouse touches the top edge. Actual Results: Top screen edge, even if unused by the configured desktop switching layout, interferes with full screen virtualbox. Expected Results: Unused screen edge hot spots should not capture the mouse pointer. With the generic desktop switching on edges disabled, I configured "Desktop Cube" in various hot spots other than the top center. This successfully popped up the full cube animation without blocking the VirtualBox mini-toolbar. Triggering the kwin "previous desktop" and "next desktop" shortcuts on just the left and right screen edges would be ideal. This could be a separate screen edge mode, or generic configurable global shortcut option for each hot spot.
Though a reasonable wish, this would hardly provide a real solution to the actual issue (what about other pager layouts, what if there's an autohiding or similar panel on the top, what if it's an external one like cairo-dock, what ....) Since this also hits okular, gwenview etc. we'd actually need to figure whether fullscreen windows should stack on top of (some) electric borders or whether we need a netwm spec addition or rules to deactivate electric borders or at least desktop switching or whether we should in general just disable electric border switching while there's a fullscreen client (and say hello to smplayer/vlc developers once more about the fact that a rooted toolbar will break the fullscreen mode - maybe we could just deviate from NETWM and exclude toolbars/popups from breaking fullscreen - at least when not unredirecting fs windows?
I recognize that many other combinations of desktop components conflict with electric borders, and some pager layout/switching combinations need top/bottom borders to work. All I am after is a way to do left/right switching with top/bottom electric borders turned off. So many interfering combinations are top/bottom that I think my suggestion is valid. Also, the "previous desktop" and "next desktop" global shortcuts I suggested supporting will cycle through all desktops, even if the pager layout is more than one row. Without the edge triggering I would like, I've fallen back on ctrl-alt-left and -right assigned to these shortcuts, with no edge switching. With the pager @ 2x2 and the cube set to ignore the pager, the cube animation is otherwise just the way I want it.
(In reply to comment #2) > So many interfering combinations are top/bottom that I think my suggestion is valid. Undoubted, but doesn't reach nearly far enough because it only covers some very particular setups (in particular horizontal pager layouts at min.) - we'd inevitably run into the next conflicts, therefore we need a reasonable strategy for electric borders in general. Also see bug #288791 I guess what you want is to keep vertical electric borders intact despite the fullscreen virtualbox, but it doesn't just work because it works in your setup. Ideally applications would hint the WM "I'm gonna need this border now, please don't track it for now". Btw: raising the activation delay in the screen edges dialog will likely help you for now since it makes activation more resistive (thus the internal panel should take precedence)
(In reply to comment #3) > (In reply to comment #2) > I guess what you want is to keep vertical electric borders intact despite the > fullscreen virtualbox, but it doesn't just work because it works in your setup. Yes, this is what I'm after. > Ideally applications would hint the WM "I'm gonna need this border now, please > don't track it for now". This idea sounds wonderful, but obviously requires every app to cooperate. > Btw: raising the activation delay in the screen edges dialog will likely help > you for now since it makes activation more resistive (thus the internal panel > should take precedence) No, as the edges I want to disable in my setup don't trigger a switch anyways. The problem is the transparent border layer in the window manager intercepts the mouse hover, so the underlying full-screen app never sees a mouse position that would trigger its hidden toolbar. The mouse pointer simply bumps up against the top screen edge without triggering anything.
(In reply to comment #4) > No, as the edges I want to disable in my setup don't trigger a switch anyways. Ouch, it only has a 1px wide sensitive border ... :-\ (Okular & Gwenview have a bigger one, so should autohiding panels - but i guess the "windows can cover" proxies don't either)
Created attachment 69067 [details] Implement desktop switching on left/right edges only I finally had some time to implement my own solution ... This applies to and works against kwin-4.8.0 on my gentoo laptop. (The patch is applied locally by placing in /etc/portage/patches/kde-base/kwin-4.8.0, for those gentoo folks who are interested.) This patch exposes another choice in the system setting for screen edge switching: "Always Enabled, Left/Right Only" When selected, desktop switching only reserves the "electric borders" for the left and right edges, and performs switching without regard to the pager layout. The settings UI is adjusted to allow custom actions on top & bottom edges in this case, or pass through to applications. Everything on my wishlist works: Small 2Rx2C pager on my panel, but switching like a 1Rx4C pager Top and bottom edges remain available for custom actions Top and bottom edges pass through to fullscreen virtualbox Please review. If you like, I can pull a tree and generate a proper patch for kde-devel.
Nice try, but the implementation is too case specific :-) What can be done (and be done in the 4.8 cycle - your patch has new strings, thus would have to be scheduled for 4.9 anyway) is to match the pager layout against the electric borders (ie. don't reserve horizontal borders for one column or vertical ones for one row - your case) what will take far less code as well ;-) How the pagers represent things is another issue, but defining a 2x2 layout but acting like on a 4x1 layout - at least on borders - is, to me, quite on the edge. Imho there should be one central definition and pagers *might* deviate from that, but kwin itself should rather not (just think of crossing borders and the desktop slide effect, it will act rather odd the way you intend to set it up)
(In reply to comment #7) > Nice try, but the implementation is too case specific :-) Too case specific? I dispute that below. > What can be done (and be done in the 4.8 cycle - your patch has new strings, > thus would have to be scheduled for 4.9 anyway) is to match the pager layout > against the electric borders (ie. don't reserve horizontal borders for one > column or vertical ones for one row - your case) what will take far less code > as well ;-) I agree that the "Always On" mode should do this. > How the pagers represent things is another issue, but defining a 2x2 layout but > acting like on a 4x1 layout - at least on borders - is, to me, quite on the > edge. The desktop switching animations already offer a setting to ignore pager layout. They just aren't 100% consistent about it. I suspect it is there for people like me, who like the desktop cube w/ a continuous rotation paradigm, but don't want a huge pager eating up space in our panel. I've been using "ignore pager layout" since kwin added the cube switcher. Given that it has existed for years (?) now, I don't think it is "quite on the edge". > Imho there should be one central definition and pagers *might* deviate from > that, but kwin itself should rather not (just think of crossing borders and the > desktop slide effect, it will act rather odd the way you intend to set it up) Arguably, setting this new left/right only edge mode could force the "ignore pager layout" setting. Or the ignore pager layout setting could trigger this behavior without the combo box change. I didn't do the latter as it would complicate the settings UI features that expose/hide edge customization options based on the switching mode. As for scheduling the code inclusion... I'm fine with 4.9, as gentoo makes it easy for me to carry this customization in the meantime.
> Please review. If you like, I can pull a tree and generate a proper patch > for kde-devel. please post the patch on reviewboard.kde.org - it's the best way to handle patches as it yells at me about not yet managed patches :-)
(In reply to comment #9) > > Please review. If you like, I can pull a tree and generate a proper patch > > for kde-devel. > please post the patch on reviewboard.kde.org - it's the best way to handle > patches as it yells at me about not yet managed patches :-) It doesn't like me. My mailing list login, my forums login, and my bugzilla login were all rejected. What kind of account do I need to qualify for a "standard username and password" ? :-)
> > > Please review. If you like, I can pull a tree and generate a proper > > > patch > > > for kde-devel. > > > > please post the patch on reviewboard.kde.org - it's the best way to handle > > patches as it yells at me about not yet managed patches :-) > > It doesn't like me. My mailing list login, my forums login, and my bugzilla > login were all rejected. What kind of account do I need to qualify for a > "standard username and password" ? :-) it needs an identity.kde.org account
Posted to reviewboard as: https://git.reviewboard.kde.org/r/104070/
(In reply to comment #8) > I've been using "ignore pager layout" since kwin added the cube switcher. > Given that it has existed for years (?) now, I don't think it is "quite on the > edge". As mentioned, pagers (and the cube effectively is one) may deviate from the given layout for particular reasons (eg. because the typical 6 faces layout could not be covered by a plain matrix and it could never reflect a random nxm matrix) > Arguably, setting this new left/right only edge mode could force the "ignore > pager layout" setting. What if I want top/bottom. And why should that not be covered by the pager layout itself (to me the entire pager layout thing is plain stupid. Different views on virtual desktops have different requirements, eg, i've a pager in a slim panel which is *always* one row height, for the panel is slim) If we make the electric borders an abstract trigger for jumping to random desktop #n we can basically omit the entire pager layout and be happy with "have n virtual desktops"
turned into a duplicate *** This bug has been marked as a duplicate of bug 182987 ***
Git commit 2ed2c50b713843b184a7b973b1dfc106679df7ff by Thomas Lübking. Committed on 03/05/2012 at 19:48. Pushed by luebking into branch 'master'. Only reserve required electric borders for ElectricAlways REVIEW: 104073 M +17 -0 kwin/desktoplayout.cpp M +2 -2 kwin/effects.cpp M +1 -1 kwin/effects.h M +2 -2 kwin/geometry.cpp M +2 -2 kwin/libkwineffects/kwineffects.h M +1 -2 kwin/scene.cpp M +32 -9 kwin/screenedge.cpp M +1 -1 kwin/screenedge.h M +11 -3 kwin/workspace.cpp M +1 -0 kwin/workspace.h http://commits.kde.org/kde-workspace/2ed2c50b713843b184a7b973b1dfc106679df7ff