more correct synchronization of virtual desktops

[totaam]

Issue migrated from trac ticket # 774

component: core | priority: major | resolution: fixed

2015-01-03 10:43:09: totaam created the issue

---

Tasks:

• ensure the server defines _NET_DESKTOP_NAMES and _NET_NUMBER_OF_DESKTOPS to match the client
• get the value for X11 clients and Windows 10 (which finally supports virtual desktops - Microsoft, welcome to the 1980s)
• monitor for changes and update the server (the "desktop_size" packet can be augmented for that)

This should allow application which are virtual desktop aware to work properly.

[totaam]

2015-01-03 11:16:13: totaam changed status from new to assigned

[totaam]

2015-01-03 11:16:13: totaam changed owner from antoine to totaam

[totaam]

2015-01-03 11:16:13: totaam edited the issue description

[totaam]

2015-01-03 11:16:13: totaam commented

---

Mostly done:

• r8361: see commit message for details
• r8362: detect client side changes

With this in place, I can see:

$ xprop -root | egrep "_NET_DESKTOP_NAMES\(UTF8_STRING\)|_NET_NUMBER_OF_DESKTOPS\(CARDINAL\)"
_NET_DESKTOP_NAMES(UTF8_STRING) = "desktop 1", "desktop 2"
_NET_NUMBER_OF_DESKTOPS(CARDINAL) = 2

Or with xpra info:

$ xpra info | egrep "desktops|desktop_names"
client.desktop_names=('desktop 1', 'desktop 2')
client.desktops=2

And changing the preferences on the client side is immediately reflected on the server side.

Remaining TODO:

• server side events: forward to client as metadata updates
• let the client update the server-side workspace the window is on to match its state
• Windows 10 support (low priority)
• OSX support, see Detecting when a space changes in Spaces in Mac OS X

[totaam]

2015-01-04 09:11:29: totaam changed status from assigned to new

[totaam]

2015-01-04 09:11:29: totaam changed owner from totaam to afarr

[totaam]

2015-01-04 09:11:29: totaam commented

---

Ready for testing:

• r8370 contains the bulk of the changes
• r8371 adds a test app: "test workspace"
• r8372: minor fixes

How to test:

• we now have workspace in xpra info
• there is an xpra control interface: xpra control :DISPLAY WINDOWID WORKSPACE (ie: xpra control :10 1 2 moves window 1 to workspace 2)
• the test app can be used to move itself to different workspaces, should work the same inside and outside xpra
• the client-side window manager can also be used to move windows to different workspaces

No matter which method is used, the value shown in xpra info should be consistent with reality.

Support for win32 and OSX has been moved to #776, as this will take longer.

[totaam]

2015-02-21 00:33:52: maxmylyn commented

---

Retested with a r8661 Fedora 21 client, an r8640 OSX client, and an 8647 Win8.1 client against a Fedora 20 r8661 (downloaded from xpra.org/beta) server:

• Workspace info not found in xpra info (did an xpra info :13 | grep workspace )

• xpra control :13 3 2 returns

server returned error code 6
invalid command

• The test app does not show any workspace information and does not appear to work.
• This does work. I can move between workspaces by right clicking on the window in Fedora 21(the client computer) and selecting "Move to Workspace Down"

[totaam]

2015-02-21 06:17:12: antoine commented

---

OSX client.. Win8.1 client..
[[BR]]
MS Windows and OSX clients are not supported for this feature yet: see comment:2 and #776.

---

Workspace info not found in xpra info
[[BR]]
The workspace is only shown if it has been set to something meaningful. (the default is unset)

$ xpra info | grep workspace=
window[1].workspace=0
window[5].workspace=1

---

xpra control :13 3 2 returns
[[BR]]
Oops, sorry about that - I forgot the verb.
The control command to use is:

xpra control :DISPLAY workspace WINDOWID WORKSPACE

ie:

xpra control :DISPLAY workspace 1 2

The test app does not show any workspace information and does not appear to work.
[[BR]]
It does not show workspace information, it is used to set it.
(but you have to use a supported OS, not OSX...)

[totaam]

2015-02-23 18:53:48: maxmylyn changed owner from afarr to antoine

[totaam]

2015-02-23 18:53:48: maxmylyn commented

---

retested with CentOS runknown(20150217 beta build from xpra.org/beta) and Fedora 21 r8661 clients against a Fedora 20 r8661 server:

using xpra control :13 workspace 3 0 I can move firefox between workspaces. Interestingly if I use a number higher than the maximum number of workspaces(that is, moving to workspace 4 when I only have 2) it'll just move it to the highest workspace number(in my case 2). This works with both Fedora 21 and CentOS 6.4.

In addition, the python app(now that I know how to use it) works as expected. I can use it to move across workspaces in both Fedora 21 and CentOS 6.4.

edit: and xpra info | grep workspace is showing correct values, as well.

Re-assigning back to you

[totaam]

2015-02-24 00:51:50: antoine changed status from new to closed

[totaam]

2015-02-24 00:51:50: antoine set resolution to fixed

[totaam]

2015-02-24 00:51:50: antoine commented

---

if I use a number higher than the maximum number of workspaces it'll just move it to the highest workspace number
[[BR]]
Yes, it is capped.

Looks done, closing.

[totaam]

2017-02-15 12:38:23: antoine commented

---

Windows 10 support moved to #1442

MacOS in #2488