Bug 335704

Summary:	Second monitor cannot be controlled seperately
Product:	[Plasma] kwin	Reporter:	schubert.viktoria
Component:	general	Assignee:	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.