Bug 335704

Summary: Second monitor cannot be controlled seperately
Product: [Plasma] kwin Reporter: schubert.viktoria
Component: generalAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: wishlist CC: schubert.viktoria
Priority: NOR    
Version: 4.11.9   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description schubert.viktoria 2014-06-02 16:32:34 UTC
When a second monitor is attached, the only options for what the screen shows are a mirror of the first one ore an expansion of the first one in a matter that switching the virtual desktops on the first monitor, the second one also changes the desktop.
I wish I could control it seperately, which means that when my mouse is on screen 1 I only change the the virtual desktops on screen 1 and the other way around. 

Reproducible: Always

Steps to Reproduce:
1.attach second monitor
2.
3.
Actual Results:  
I have no choice about the handling of the second monitor in its extended desktop way.

Expected Results:  
The software should give me a choice on how to handle the extended desktop.
Comment 1 Thomas Lübking 2014-06-02 18:25:37 UTC
virtually impossible with virtual desktops since the ewmh spec only specifies ONE current virtual desktop (and is mostly multiscreen unaware anyway)

(ie. when you whel the desktop, plasma-desktop informs the system that the new vd is n+1, there's not even a chance to know "for what screen" the vd should be changed.

*** This bug has been marked as a duplicate of bug 107302 ***
Comment 2 schubert.viktoria 2014-06-02 18:29:51 UTC
Okay I see, thanks for your reply, but now I'm wondering why this is possible in awesome but not in KDE?
Comment 3 Martin Flöser 2014-06-02 19:11:02 UTC
(In reply to comment #2)
> Okay I see, thanks for your reply, but now I'm wondering why this is
> possible in awesome but not in KDE?

because awesome might have done different decisions.

*** This bug has been marked as a duplicate of bug 107302 ***
Comment 4 Thomas Lübking 2014-06-02 19:50:32 UTC
Awesome does not implement EWMH compliant, but "self contained" VDs.

It's trivially simple to write even a KWin script that listens to a shortcut and proceeds to the next (previous/some specific) ... let's say "Hyperspace" on the current screen only - but that does not work "across the stars" ... system. Neither would interaction w/ EWMH compliant pagers or plasma-desktop (let alone any other desktop) possible*, nor would the client know that it's now on a different virtual desktop (just that it's "iconified" - ie. "minimized" in human speech)

tl;dr
of course such behavior can be implemented, even as addon to kwin, but it will match the EWMH/NETWM protocol of virtual desktops.

*actually plasma-desktop and some others let you execute random calls on wheel - so you could make a dbus call to kglobalaccel to trigger your next/prev shortcut.