Move a window between Workspaces

[dbannon]

Linux has a "Workspace" facility, typically four virtual screens you can switch between.

Does anyone know if LCL can move a window between workspaces. I currently call a wmctrl (a stand alone binary) process to do this but its becoming inconvenient to do so in a AppImage. And, honestly, the "process" approach is pretty lazy !

Any suggestions ?

Davo

[Zvoni]

Can you "debug" during "manual" switch?
Say, check the Value of DefaultMonitor, Owner, parent (and other "suspects") before the switch, then check it again after the manual switch (CTRL+SHIFT+PageUp/Down?)

[MarkMLl]

On Windows there's a specific abstraction layer for this sort of thing, based on windowspaces(?).

On typical unix systems this is a window manager operation starting off with fvwm IIRC, so I think it's basically down to working out what library/protocol wmctrl uses.

I've looked at related problems in the past, e.g. "is any desktop/workspace displaying a recognisable error dialogue", and not been able to get any further than that.

MarkMLl

[dbannon]

Thanks Zvoni, Mark,

Can you "debug" during "manual" switch?
Say, check the Value of DefaultMonitor, Owner, parent (and other "suspects") before the switch, then check it again after the manual switch (CTRL+SHIFT+PageUp/Down?)

Hmm, I had an old test project from last time I tried this. Form2 left:632 DFM:dmActiveForm POS:poDesigned STY:fsNormal

(DFM, default monitor, POS, Position, Sty, FormStyle) - they don't change. I had not tried Owner nor Parent but just now, seems 'Name' is not valid ?? Either triggers an access violation.

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

1. //    writeln(' OWN:', self.Owner.Name);
2. //    writeln(' PNT:', self.Parent.Name);

But poking around, I did find that calling ~.Hide; ~.show; actually brings it to the current workspace. If its already in the current workspace, it flickers. Not sure I like that, if someone has selected it, (in my case, from a menu from the SystemTrayIcon) its because they are looking for it, so, maybe that flicker is a good thing, it says, here, over here !

But sometimes, again, in my case, the window can be a bit slow to render because it has a lot of (marked up text) content, "further research is indicated".

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

1.     Form2.EnsureVisible(True);
2.     Form2.Hide;
3.     Form2.Show;

Mark :
Second time I have have seen you mention this "virtual desktop" idea on Windows ?  Is it common ?  I don't think I have ever seen it used on Windows ....

Davo

[MarkMLl]

I think that WMs classically implemented it by minimise/restore operations like you've shown, but that doesn't mean that they haven't- relatively recently- gained at least per-window attributes etc. acting as guidelines. There's a whole lot of implementation stuff at the WM level that I've never managed to grok: starting off with font metrics etc.

Second time I have have seen you mention this "virtual desktop" idea on Windows ?  Is it common ?  I don't think I have ever seen it used on Windows ....

NT4(?) had a variant called Terminal Server Edition which was basically there as a swipe at X11 and/or VNC and was based on the Window Station management layer, I believe this got rolled into the standard Server product from W2K onward. NT4's Resource Kit had a utility that used the same API to implement an arbitrary number of desktops, I've also used the same on XP but don't know about other versions. It was notably easier to move apps between desktops on Windows than on unix WMs.

I'm not sure, but I think unix started using "virtual desktops" etc. with fvwm, which was a derivative of fwm. So they've been around for a while, but not as a part of the underlying X11 API.

MarkMLl

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

1. (* The hierarchy appears to be:                                         *)
2. (*                                                                      *)
3. (* 1)   Each logon corresponds to a session. NT4W or NT4S supports a    *)
4. (*      single session, NT4 TSE supports multiple sessions generally    *)
5. (*      corresponding to client connections. According to               *)
6. (*      http://www.winnetmag.com/Articles/Index.cfm?ArticleID=3594&pg=2 *)
7. (*      the term "WinStation" may be synonymous with a session, in any  *)
8. (*      case sessions are distinct and do not share user-accessible     *)
9. (*      memory although winsta.dll appears to export enumeration and    *)
10. (*      management functions.                                           *)
11. (*                                                                      *)
12. (* 2)   Each session supports one or more WindowStations. One of these  *)
13. (*      is interactive, others may exist to support non-interactive     *)
14. (*      services. From http://www.geocities.com/teohunboon/tools.htm it *)
15. (*      appears that WindowStations exist in the global namespace, e.g. *)
16. (*      "\Sessions\x\WindowStation\Winsta0 where x is a numeric from 1  *)
17. (*      to the number of [active users]."                               *)
18. (*                                                                      *)
19. (* 3)   In the context of a particular session the interactive          *)
20. (*      WindowStation supports a default desktop named "Default" and if *)
21. (*      associated with a physical display at least one additional      *)
22. (*      desktop used for screensavers. Desktop management programs may  *)
23. (*      create additional desktops although naming conventions may be   *)
24. (*      obscure.                                                        *)
25. (*                                                                      *)
26. (* A Microsoft document published in the NT 3.51 era stated that the    *)
27. (* way to locate the desktop being used by the screen saver was to look *)
28. (* at the registry to determine the name of the current screen saver    *)
29. (* executable, examine the PE header of this to determine the process   *)
30. (* name, walk the process list looking for this named process and       *)
31. (* finally to query this to determine the desktop with which it was     *)
32. (* associated. I note that the facilities for walking processes etc.    *)
33. (* have improved since then and it may be that W2K or later makes this  *)
34. (* job much easier.                                                     *)
35.  

Note from the above (written circa 2002) the implication that non-displayed programs (i.e. services etc.) run in their own winstation. However other than having BTDT I claim no particular expertise or interest in the Windows APIs.

[Zvoni]

hmm..... on Windows there is the API GetDesktopWindow, which returns a Handle to the Desktop.
Shouldn't there be something similiar on Linux?
Considering a (different) Workspace is basically a "virtual" Desktop

[MarkMLl]

hmm..... on Windows there is the API GetDesktopWindow, which returns a Handle to the Desktop.
Shouldn't there be something similiar on Linux?
Considering a (different) Workspace is basically a "virtual" Desktop

Why?

MarkMLl

[Fred vS]

hmm..... on Windows there is the API GetDesktopWindow, which returns a Handle to the Desktop.
Shouldn't there be something similiar on Linux?

On Linux X11 you may get it via XGetWindowProperty() from xlib.pp.
( And via MSEgui, gui_getwindowdesktop()    )

[Zvoni]

hmm..... on Windows there is the API GetDesktopWindow, which returns a Handle to the Desktop.
Shouldn't there be something similiar on Linux?
Considering a (different) Workspace is basically a "virtual" Desktop

Why?

MarkMLl

Basically just to check if Dave's Program actually recognizes that it's on a "different" Desktop/Workspace.
Additionally: A Desktop could be considered the "Parent" for all Windows running on that Desktop.
That's what this is about.

No idea if/how to SET a "Desktop"-Parent for a Program.....

[Fred vS]

hmm..... on Windows there is the API GetDesktopWindow, which returns a Handle to the Desktop.
Shouldn't there be something similiar on Linux?

On Linux X11 you may get it via XGetWindowProperty() from xlib.pp.
( And via MSEgui, gui_getwindowdesktop()    )

This is for X11/Xorg.  For a Wayland session, it is quasi impossible, or needs to install extension:

https://stackoverflow.com/questions/67318357/how-to-set-the-position-of-a-wayland-window-on-the-screen

Acccording to this, toplevel windows cannot be moved in Wayland, only subsurfaces can be moved. So : What you are trying to do is impossible. If you really have to move the window, you'll have to switch to Xlib, or, even better, use a GUI framework as Qt5 or Gtk+ 3. The only option you have with Wayland is to make the toplevel as big as the screen, create a subsurface with the image and move that subsurface in the toplevel, as that is possible in Wayland. You can find an example on how to create subsurfaces in the subsurface-test.c file from the Weston compositor.

[MarkMLl]

Additionally: A Desktop could be considered the "Parent" for all Windows running on that Desktop.

Why? That's not how X11 works. Remember the old trick of killing your WM and starting a different one without losing the state of any programs?

You have one X11 session, represented by a socket. (originally TCP, latterly unix-domain etc.). The WM provides all the furniture for each window, including the caption etc., if you want to change anything then you need to talk to the WM: not to X11 which isn't particularly interested in that level of abstraction.

Similarly, your font metrics etc. are fed by the WM to the widget set: a year or so ago I was experiencing significant problems because the RPi's WM (AKA desktop enviroonment) skimped on this.

ATM, it's the widget set that talks to the WM: using in effect a private API which corresponds to what's used (on unix) by wmctl. Yes, it would be nice to be able to get at that API. But so far I don't think there's a Pascal port of the library etc. that does it.

MarkMLl

[MarkMLl]

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

Yes, that makes sense and I think that's roughly where I got to with my font metrics problem. But this is basically just a general-purpose protocol interface (rougghly equivalent to inspecting a processes environment variables), and there's a great deal of "what precise reference do I need to provide to get/set what I want?"... hence wmctl.

MarkMLl

[Zvoni]

Additionally: A Desktop could be considered the "Parent" for all Windows running on that Desktop.

Why? That's not how X11 works. Remember the old trick of killing your WM and starting a different one without losing the state of any programs?

You have one X11 session, represented by a socket. (originally TCP, latterly unix-domain etc.). The WM provides all the furniture for each window, including the caption etc., if you want to change anything then you need to talk to the WM: not to X11 which isn't particularly interested in that level of abstraction.

Similarly, your font metrics etc. are fed by the WM to the widget set: a year or so ago I was experiencing significant problems because the RPi's WM (AKA desktop enviroonment) skimped on this.

ATM, it's the widget set that talks to the WM: using in effect a private API which corresponds to what's used (on unix) by wmctl. Yes, it would be nice to be able to get at that API. But so far I don't think there's a Pascal port of the library etc. that does it.

MarkMLl

Everything true.
Just wanted to help out Dave to maybe get an "inspiration" for how to skin that cat.

[MarkMLl]

Everything true.
Just wanted to help out Dave to maybe get an "inspiration" for how to skin that cat.

I think a good start would be if we could find a good reference to what can be set by XGetWindowProperty() that interacts in some way with the WM. The easiest way might be to look at the source for wmctl.

There's other subtleties relating to X authentication etc. which I poked a year or so ago in the context of Docker, but by and large I think we can assume that in this specific case we're dealing with a single X11 session so knowing that we're already interacting with it things should be OK.

MarkMLl

Updated: Google gives me these both of which look relevant.

https://bbs.archlinux.org/viewtopic.php?id=117031

https://codereview.stackexchange.com/questions/283445/a-c-python-x-server-interface-extension-package

[zeljko]

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