Move a window between Workspaces

[MarkMLl]

Here is answer
https://stackoverflow.com/questions/75292933/controlling-an-x-window-from-a-different-virtual-desktop-without-entering-that-x

Ah yes. That looks like a good one.

Somewhat later: that appears to tie in with https://en.wikipedia.org/wiki/Extended_Window_Manager_Hints , suggesting that things like getting (as distinct from setting) the captions of displayed windows might be available via the older ICCCM (WM_NAME?).

I think that the only time I've used xlib directly is for getting to the "keyboard bell".

MarkMLl

[dbannon]

OK, some pretty useful suggestions here and I thanks you all.

Here is answer
https://stackoverflow.com/questions/75292933/controlling-an-x-window-from-a-different-virtual-desktop-without-entering-that-x

The answer there is pretty much a screen scrape from    https://specifications.freedesktop.org/wm-spec/latest/.   

I had got there by tracing back from wmctrl source. Sadly, wmctrl appears to be abandonware, but still appears in  most linux distros because its such a useful thing.  So, almost certain it will not work under Wayland (yet ?) that does not worry me that much at present, Qt apps need use XCB to be usable on a Wayland system anyway. We have seen very little improvements in core Wayland in the last couple of years but lots of effective ways to work around it. Have to wonder what the future there is.

On Linux X11 you may get it via XGetWindowProperty() from xlib.pp.

Hmm, thats worth looking into. I am already using XLIB bindings (to find out if I have a usable System Tray Icon) so its well worth while looking at.  I will report back what I find.

The interesting thing I have found however, is that hiding and reshowing the window does bring it back in the current Workspace, nominally, all I need. The resulting 'flicker' could be seen as the Window trying to attract the users attention. I am not sure its a bad thing thing, my Windows and Mac users might complain they don't see a flicker ....

I will report back !

[MarkMLl]

On Linux X11 you may get it via XGetWindowProperty() from xlib.pp.

So looking at xlib, are properties like the desktop also /set/ using WindowProperty()?

MarkMLl

[Zvoni]

On Linux X11 you may get it via XGetWindowProperty() from xlib.pp.

So looking at xlib, are properties like the desktop also /set/ using WindowProperty()?

MarkMLl

https://tronche.com/gui/x/xlib/window-information/obtain-properties.html

XChangeProperty looks promising

[Fred vS]

On Linux X11 you may get it via XGetWindowProperty() from xlib.pp.

So looking at xlib, are properties like the desktop also /set/ using WindowProperty()?

MarkMLl

https://tronche.com/gui/x/xlib/window-information/obtain-properties.html

XChangeProperty looks promising

Yes dealing with net_wm_desktop atom.

[dbannon]

I have been looking pretty closely at the c code in wmctrl. Its nice clean C, not C++ so understandable even by me. So, I reasoned, following just the "mv window here" path might be a good approach.

https://github.com/Conservatory/wmctrl/blob/master/main.c

Everything I need does seem to be available in the x, xlib, ctypes, xatom bindings.

It does not use  XChangeProperty(), it posts an event to X in some manner.  It does use XGetWindowProperty() with its 12 parameters, to read specific properties from the window (much line env vars as Mark mentioned).  You call it, tell it which property you are interested in and it comes back with a heap of data. Including, I am guessing, the Workspace number if you ask for the right property.

So far, all I can get is an AV when I call XGetWindowProperty() and it late here !  Going to bed.

Davo

Code: Pascal  [Select][+][-]

1. uses
2.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls {$ifdef LINUX}, x, xlib, ctypes, xatom, process {$endif};
3.  
4. ....
5.  
6. const Max_Property_Value_Len = 4096;
7.  
8. procedure TForm1.MoveWindow();
9. var
10.     Disp : PDisplay;
11.     Prop : cint;
12.     Win : TWindow;
13.     xa_prop_name : TAtom;
14.     xa_ret_type : PAtom;
15.     ret_format : Pcint;
16.     ret_nitems, ret_bytes_after, tmp_size : Pculong;
17.     ret_prop : PPcuchar;
18. begin
19.     Disp := XOpenDisplay(Nil);
20.     if Disp = nil then begin
21.         Memo1.Append('Nope, unable to open Disp');
22.     end else begin
23.         xa_prop_name := XInternAtom(disp, '_NET_CLIENT_LIST', False);
24.         Win := DefaultRootWindow(disp);
25.         Prop := XGetWindowProperty(Disp, Win, xa_prop_name, 0, MAX_PROPERTY_VALUE_LEN div 4,
26.                 False, XA_WINDOW, xa_ret_type, ret_format, ret_nitems, ret_bytes_after, ret_prop);
27.     end;
28.     XCloseDisplay(disp);
29. end;  
30.  
31. (*  C code looks like this -
32.     Window *client_list;
33.     if ((client_list = (Window * )get_property(disp, DefaultRootWindow(disp),
34.                     XA_WINDOW, "_NET_CLIENT_LIST", size)) == NULL) {
35.         if ((client_list = (Window * )get_property(disp, DefaultRootWindow(disp),
36.                         XA_CARDINAL, "_WIN_CLIENT_LIST", size)) == NULL)
37.  
38.     Pascal -
39.     function XGetWindowProperty(para1:PDisplay; para2:TWindow; para3:TAtom; para4:clong; para5:clong;
40.            para6:TBool; para7:TAtom; para8:PAtom; para9:Pcint; para10:Pculong;
41.            para11:Pculong; para12:PPcuchar):cint;cdecl;external libX11;    *)

                           

[MarkMLl]

It does not use  XChangeProperty(), it posts an event to X in some manner.  It does use XGetWindowProperty() with its 12 parameters, to read specific properties from the window (much line env vars as Mark mentioned).  You call it, tell it which property you are interested in and it comes back with a heap of data. Including, I am guessing, the Workspace number if you ask for the right property.

So far, all I can get is an AV when I call XGetWindowProperty() and it late here !  Going to bed.

You'll probably know /exactly/ how to fix it when you get up.

I think a key thing here is that XGetWindowProperty() is built on top of ICCCM hence ICE etc. which just like any other X11 protocol gets pushed through a single socket (if TCP, it would be in the 60,000 region). In principle you could look at that traffic using something like Wireshark, but the fact that in practical terms this can't really be done is something that's irritated me ever since the days of X-Terminals (which typically used a 68000 chip, which gives some idea of the era :-)

The complexity and sheer depth of the rabbit hole has invariably ended up with my simply finding some other way of doing things, so it's really of considerable interest to see somebody actually making some progress.

MarkMLl

[dbannon]

OK, here is my solution to moving a (Linux) window around between workspaces (or virtual desktops). An updated download further on in this thread.

It works on most Linux Desktops, exception being KDE (who have apparently invented their own model) and pure Wayland ones.  Qt5 and Qt6 apps work fine on Gnome if you use the QT_QPA_PLATFORM=xcb env var (and you really must use that anyway).  GTK2 apps work fine under gnome.

Everything works with the user friendly desktops, Cinnamon, XFCe, Mate etc.

Be interested in hearing how other (Linux) Desktops perform ?

Might also be useful examples of how to get a XWindow ID, post an event to X11, use XGetWindowProperty etc.

Davo

[MarkMLl]

Thanks for the contribution. I habitually use KDE but will definitely be dipping into that.

MarkMLl

[dbannon]

The interesting thing seems to be that wmctrl still works on KDE. My code is based, in part, on wmctrl's C code. Further research is indicated .....

Davo

[MarkMLl]

The interesting thing seems to be that wmctrl still works on KDE. My code is based, in part, on wmctrl's C code. Further research is indicated .....

Yes, I'd got there... :-)

Wouldn't be surprised if Debian (hence the many derivatives) had patched it.

MarkMLl

[zeljko]

OK, here is my solution to moving a (Linux) window around between workspaces (or virtual desktops).

It works on most Linux Desktops, exception being KDE (who have apparently invented their own model) and pure Wayland ones.  Qt5 and Qt6 apps work fine on Gnome if you use the QT_QPA_PLATFORM=xcb env var (and you really must use that anyway).  GTK2 apps work fine under gnome.

Everything works with the user friendly desktops, Cinnamon, XFCe, Mate etc.

Be interested in hearing how other (Linux) Desktops perform ?

Might also be useful examples of how to get a XWindow ID, post an event to X11, use XGetWindowProperty etc.

Davo

In CurrentWorkSpace() and function below that one you forgot to add CloseXDisplay(), so when your system reach maxallowedfiles you'll get crash because of too many XOpenDisplay() without closing descriptors for one shot ops.

[dbannon]

Ah, yes Zeljko, very good point.  I also need to rationalise the opening of XDisplay anyway, should only open in the entry point(s).

Mark : the code repo for wmctrl i am using predates Wayland, I'll grab a debian source package later today if I get some time.

Davo

[dbannon]

OK, here is my second crack at it. An updated download further on in this thread.

I now do a recursive search through the windows below RootWindow, I wanted to avoid this as its relatively slow and, on  systems I  tested, unnecessary. But under KDE the window hierarchy has more levels. Perhaps other systems too.

Expect a working machine with lots of windows open to take 20mS to 100mS to move one. wmctrl always takes more than 100mS.

Anyway, the core action of "move that window to this workspace" works fine now under KDE. The complementary "move that windows to Workspace X"  is surprising in that it also takes focus there. Other ways in KDE of moving a window does the same thing. Go figure ...

I have removed the previous attachment.

Davo

[MarkMLl]

Expect a working machine with lots of windows open to take 20mS to 100mS to move one. wmctrl always takes more than 100mS.

Presumably though that can be cached... although that is more the domain of xdg-screensaver being used to make sure a system doesn't go dark at an inopportune time ** .

I wonder how /that/ works? Probably more ICCCM stuff under the hood, so what you've done is still very relevant.

MarkMLl

Obligatory xkcd https://xkcd.com/196/