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.
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 ***
Okay I see, thanks for your reply, but now I'm wondering why this is possible in awesome but not in KDE?
(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 ***
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.