Bug 337790 - In a multiscreen setup, tabbox is placed on a random screen
Summary: In a multiscreen setup, tabbox is placed on a random screen
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: tabbox (show other bugs)
Version: git master
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/124...
Keywords:
: 343431 350449 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-07-25 08:25 UTC by Luca Beltrame
Modified: 2015-08-19 10:39 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.4
Sentry Crash Report:
thomas.luebking: ReviewRequest+


Attachments
Supporting information from KWin (4.51 KB, text/plain)
2014-07-25 08:25 UTC, Luca Beltrame
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luca Beltrame 2014-07-25 08:25:16 UTC
Created attachment 87942 [details]
Supporting information from KWin

I have the following screen layout (3 identical 1280x1024 screens):

left - middle (primary) - right

When using Alt-Tab, the tabbox is placed on a random screen: what's interesting is that it is never the active screen (pointer + window focus).

Examples:

- Window on middle screen with focus and pointer -> Alt-Tab sends the tabbox on the left screen;
- Window on the left screen -> Alt Tab sends the tabbox on the rightmost screen

This can be reproduced 100% of the time.
Comment 1 Martin Flöser 2014-07-25 08:31:18 UTC
I can unfortunately confirm the behavior with a two screen setup. Never really 
noticed it.
Comment 2 Martin Flöser 2015-01-28 07:34:38 UTC
*** Bug 343431 has been marked as a duplicate of this bug. ***
Comment 3 Oscar Fuentes 2015-05-03 01:04:43 UTC
I'm experiencing this problem with Plasma 5.2.9 (default install with Kubuntu 15.04) and with Plasma 5.3 (same Kubuntu install upgraded with Kubuntu PPA Backports). The curious thing is that at first the tabbox appears on the right monitor (the one that has the focus) but after a while it only appears on the secondary monitor when the primary has the focus, and vice-versa. As my secondary monitor is off most of the time, this is quite annoying. Then, I switch to another Visualization (say, from "Grid" to "Informative") and the new visualization also works for a while. If I revert to a previous Visualization that showed the problem, it persists. So the only "fix" is to log-off and log-on.

Curiously, the "Flip switch" and the "Cover switch" visualizations seems not affected by this problem: they always show on the monitor that has the focus.
Comment 4 Alexander Potashev 2015-06-30 11:33:48 UTC
I can confirm this with Breeze visualization on Fedora 22 and kwin-5.3.1. Only Breeze is affected, all other visualizations (text only, grid, compact, detailed, thumbnails, ... - all of them!) appear on the screen where the active window resides.
Comment 5 Thomas Lübking 2015-07-21 12:39:46 UTC
*** Bug 350449 has been marked as a duplicate of this bug. ***
Comment 6 Tobias Langner 2015-08-18 07:48:08 UTC
I am also affected by this bug and conducted a few experiments to understand what's happening. I think that the tab switcher is always displayed on a screen that is not the active screen (i.e., the screen that contains the active window) and among those, the screen that contains the most recently used window. In a dual screen setup, this means that it always appears on the non-active screen, which is very much annoying.

Please address this issue quickly as it completely kills the usability of the task switcher. I would already appreciate a fix that just forces the task switcher on all screens or just one a fixed one..
Comment 7 Thomas Lübking 2015-08-18 11:16:35 UTC
There's a combination of three major problems here.

a) geometry.cpp:396
-      if (!c->isOnActiveScreen())
+ //     if (!c->isOnActiveScreen())
        screens()->setCurrent(c->screen());

The test leads to insufficient updates (usually I only get an update when clicking a window)

b) The tabbox somehow "pollutes" the current screen while showing up and that signal is apparently not caught by the QML interpreter.

c) m_currentFollowsMouse isn't covered by the QML tabbox at all, because it doesn't query the current() screen when mandatory and moving around the mouse does not emit signals (for obvious reasons)

=> I doubt the tabbox QML stuff works as done right now.
Instead of listening to current screen change signals (which get emitted fairly random atm.) we need to enforce a re-read of the current screen geometry whenever the tabbox shows up.

This here fixes it (for both active screen models - I assume the activation problem is related to the pollution by the tabbox) afaics:

diff --git a/tabbox/switcheritem.cpp b/tabbox/switcheritem.cpp
index f463027..957e153 100644
--- a/tabbox/switcheritem.cpp
+++ b/tabbox/switcheritem.cpp
@@ -43,7 +43,7 @@ SwitcherItem::SwitcherItem(QObject *parent)
         }
     });
     connect(screens(), &Screens::changed, this, &SwitcherItem::screenGeometryChanged);
-    connect(screens(), &Screens::currentChanged, this, &SwitcherItem::screenGeometryChanged);
+//     connect(screens(), &Screens::currentChanged, this, &SwitcherItem::screenGeometryChanged);
 }
 
 SwitcherItem::~SwitcherItem()
@@ -71,6 +71,8 @@ void SwitcherItem::setVisible(bool visible)
     if (m_visible == visible) {
         return;
     }
+    if (visible)
+        emit screenGeometryChanged();
     m_visible = visible;
     emit visibleChanged();
 }
Comment 8 Martin Flöser 2015-08-18 11:22:35 UTC
For point a the problem is obvious: that cannot work with any window being on multiple screens.
b needs to be fixed, c sounds strange: there shouldn't be a need for that - after all it should only interact with the current screen. That sounds like a problem with the bindings.

I'll look in it once I get my branch cleaned up in a state that I can commit again :-P
Comment 9 Thomas Lübking 2015-08-18 11:28:44 UTC
(c) is actually the showstopper to the present approach - the current screen value isn't updated on moving the mouse between screen A and screen B (as that implies to track the mouse)

The (mouse driven) value is updated on query only, but QML does never query the value by itself but only for the changed signal.

=> We must ensure a "changed" signal at an appropriate moment (which is imo "before the tabbox gets shown") so that the qml interpreter updates the geometry value.
That is probably even less overhead than telling the hidden tabbox about a hundred current screen changes.
Comment 10 Martin Flöser 2015-08-18 11:51:31 UTC
ah, now it makes sense. Yeah should probably just query Cursor::pos prior to showing.
Comment 11 Thomas Lübking 2015-08-19 10:39:40 UTC
Git commit f96836b2df46e94dff52d0b26f7b6b01c4cec2ff by Thomas Lübking.
Committed on 19/08/2015 at 10:31.
Pushed by luebking into branch 'Plasma/5.4'.

update SwitcherItem::screenGeometry when showing

not everytime the current screen changes.
a) that pollutes the geometry when the tabbox is invoked
b) it's insufficient for "Active Screen follows mouse" (the default)
c) less overhead (ok: "on multiscreen")
Related: bug 341531
FIXED-IN: 5.4
REVIEW: 124814

M  +2    -1    tabbox/switcheritem.cpp

http://commits.kde.org/kwin/f96836b2df46e94dff52d0b26f7b6b01c4cec2ff