Move a window between Workspaces lazarus / 32-Linux ---------------------------------------------------------------------- dbannon · 2024-09-02 09:15 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 · 2024-09-02 09:30 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 · 2024-09-02 09:43 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 · 2024-09-02 11:37 Thanks Zvoni, Mark, Quote from: Zvoni on September 02, 2024, 11:30:08 amCan 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i //    writeln(' OWN:', self.Owner.Name);//    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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i     Form2.EnsureVisible(True);    Form2.Hide;    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 · 2024-09-02 12:26 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. Quote from: dbannon on September 02, 2024, 01:37:59 pmSecond 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i (* The hierarchy appears to be:                                         *)(*                                                                    *)(* 1)   Each logon corresponds to a session. NT4W or NT4S supports a    *)(*      single session, NT4 TSE supports multiple sessions generally    *)(*      corresponding to client connections. According to               *)(*      http://www.winnetmag.com/Articles/Index.cfm?ArticleID=3594&pg=2 *)(*    the term "WinStation" may be synonymous with a session, in any  *)(*      case sessions are distinct and do not share user-accessible     *)(*      memory although winsta.dll appears to export enumeration and    *)(*      management functions.                                         *)(*                                                                    *)(* 2)   Each session supports one or more WindowStations. One of these  *)(*      is interactive, others may exist to support non-interactive     *)(*      services. From http://www.geocities.com/teohunboon/tools.htm it *)(*      appears that WindowStations exist in the global namespace, e.g. *)(*      "\Sessions\x\WindowStation\Winsta0 where x is a numeric from 1  *)(*    to the number of [active users]."                               *)(*                                                                    *)(* 3)   In the context of a particular session the interactive        *)(*      WindowStation supports a default desktop named "Default" and if *)(*      associated with a physical display at least one additional      *)(*      desktop used for screensavers. Desktop management programs may  *)(*      create additional desktops although naming conventions may be   *)(*      obscure.                                                      *)(*                                                                    *)(* A Microsoft document published in the NT 3.51 era stated that the    *)(* way to locate the desktop being used by the screen saver was to look *)(* at the registry to determine the name of the current screen saver    *)(* executable, examine the PE header of this to determine the process   *)(* name, walk the process list looking for this named process and       *)(* finally to query this to determine the desktop with which it was     *)(* associated. I note that the facilities for walking processes etc.    *)(* have improved since then and it may be that W2K or later makes this  *)(* job much easier.                                                   *)  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 · 2024-09-02 12:44 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 · 2024-09-02 13:14 Quote from: Zvoni on September 02, 2024, 02:44:35 pmhmm..... 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 · 2024-09-02 13:15 Quote from: Zvoni on September 02, 2024, 02:44:35 pmhmm..... 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 · 2024-09-02 13:21 Quote from: MarkMLl on September 02, 2024, 03:14:07 pmQuote from: Zvoni on September 02, 2024, 02:44:35 pmhmm..... 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 · 2024-09-02 13:32 Quote from: Fred vS on September 02, 2024, 03:15:20 pmQuote from: Zvoni on September 02, 2024, 02:44:35 pmhmm..... 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 QuoteAcccording 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 · 2024-09-02 13:35 Quote from: Zvoni on September 02, 2024, 03:21:15 pmAdditionally: 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 · 2024-09-02 13:39 Quote from: Fred vS on September 02, 2024, 03:15:20 pmOn 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 · 2024-09-02 13:44 Quote from: MarkMLl on September 02, 2024, 03:35:10 pmQuote from: Zvoni on September 02, 2024, 03:21:15 pmAdditionally: 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 · 2024-09-02 13:57 Quote from: Zvoni on September 02, 2024, 03:44:12 pmEverything 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 · 2024-09-02 18:37 Here is answer https://stackoverflow.com/questions/75292933/controlling-an-x-window- from-a-different-virtual-desktop-without-entering-that-x ---------------------------------------------------------------------- MarkMLl · 2024-09-02 19:12 Quote from: zeljko on September 02, 2024, 08:37:16 pmHere 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 · 2024-09-03 00:44 OK, some pretty useful suggestions here and I thanks you all. Quote from: zeljko on September 02, 2024, 08:37:16 pmHere 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. Quote from: Fred vS on September 02, 2024, 03:15:20 pmOn 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 · 2024-09-03 07:00 Quote from: dbannon on September 03, 2024, 02:44:22 amQuote from: Fred vS on September 02, 2024, 03:15:20 pmOn 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 · 2024-09-03 07:09 Quote from: MarkMLl on September 03, 2024, 09:00:52 amQuote from: dbannon on September 03, 2024, 02:44:22 amQuote from: Fred vS on September 02, 2024, 03:15:20 pmOn 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 · 2024-09-03 12:57 Quote from: Zvoni on September 03, 2024, 09:09:38 amQuote from: MarkMLl on September 03, 2024, 09:00:52 amQuote from: dbannon on September 03, 2024, 02:44:22 amQuote from: Fred vS on September 02, 2024, 03:15:20 pmOn 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 · 2024-09-03 13:07 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i uses  Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls {$ifdef LINUX}, x, xlib, ctypes, xatom, process {$endif}; .... const Max_Property_Value_Len = 4096; procedure TForm1.MoveWindow();var    Disp : PDisplay;    Prop : cint;    Win : TWindow;    xa_prop_name : TAtom;    xa_ret_type : PAtom;    ret_format : Pcint;    ret_nitems, ret_bytes_after, tmp_size : Pculong;    ret_prop : PPcuchar;begin    Disp := XOpenDisplay(Nil);    if Disp = nil then begin        Memo1.Append('Nope, unable to open Disp');    end else begin        xa_prop_name := XInternAtom(disp, '_NET_CLIENT_LIST', False);        Win := DefaultRootWindow(disp);        Prop := XGetWindowProperty(Disp, Win, xa_prop_name, 0, MAX_PROPERTY_VALUE_LEN div 4,                False, XA_WINDOW, xa_ret_type, ret_format, ret_nitems, ret_bytes_after, ret_prop);    end;    XCloseDisplay(disp);end;   (*  C code looks like this -    Window *client_list;    if ((client_list = (Window * )get_property(disp, DefaultRootWindow(disp),                    XA_WINDOW, "_NET_CLIENT_LIST", size)) == NULL) {        if ((client_list = (Window * )get_property(disp, DefaultRootWindow(disp),                      XA_CARDINAL, "_WIN_CLIENT_LIST", size)) == NULL)     Pascal -  function XGetWindowProperty(para1:PDisplay; para2:TWindow; para3:TAtom; para4:clong; para5:clong;           para6:TBool; para7:TAtom; para8:PAtom; para9:Pcint; para10:Pculong;           para11:Pculong; para12:PPcuchar):cint;cdecl;external libX11;    *) ---------------------------------------------------------------------- MarkMLl · 2024-09-03 13:35 Quote from: dbannon on September 03, 2024, 03:07:47 pmIt 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 · 2024-09-08 00:48 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 · 2024-09-08 06:35 Thanks for the contribution. I habitually use KDE but will definitely be dipping into that. MarkMLl ---------------------------------------------------------------------- dbannon · 2024-09-08 12:36 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 · 2024-09-08 12:42 Quote from: dbannon on September 08, 2024, 02:36:17 pmThe 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 · 2024-09-08 18:36 Quote from: dbannon on September 08, 2024, 02:48:35 amOK, 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 · 2024-09-08 22:43 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 · 2024-09-09 09:30 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 · 2024-09-09 09:47 Quote from: dbannon on September 09, 2024, 11:30:26 amExpect 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/ ---------------------------------------------------------------------- dbannon · 2024-09-09 10:35 Quote from: MarkMLl on September 09, 2024, 11:47:11 am.... 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 ** . Well, in my app for example, a user can open any number of non-modal windows over a period of time. I keep a list of the forms (and some other data), it would be very easy to grab the WindowID at each create time, store it in the list and use it directly when necessary. But finding the WindowID of a whole lot of windows at the same time could be slow.  Think I would build an index of all named windows, then its just a look up. Hmm, maybe no that slow .... Its worth noting that a TWinow is actually a qword, someone is allowing for a lot of windows !  Davo ---------------------------------------------------------------------- MarkMLl · 2024-09-09 10:42 Quote from: dbannon on September 09, 2024, 12:35:40 pmIts worth noting that a TWinow is actually a qword, someone is allowing for a lot of windows !  Yes, but being unix it's also going to be a pointer... although not necessarily on the local machine, which might make it unsafe to redeclare it as a ptruint. Lifetime is going to be more of an issue, depending on whether windows are really being created and destroyed or merely hidden. MarkMLl ---------------------------------------------------------------------- dbannon · 2024-09-09 11:54 Here is an  enhanced version of the demo, no change to MvXWindows unit. I thought should show the "other" way to achieve what I set out to do here. That is, bring a Window, in another Workspace, here.  By just hiding it and then showing it again, yes, it pops up in the current workspace !  But if its already visible, it has a noticeable flicker.  I am not sure that is a bad thing, maybe its useful to draw the user's attention ? I have not yet determined which approach I will use in my app, both approaches are documented in the demo. Davo ---------------------------------------------------------------------- dbannon · 2024-09-09 12:05 And, Mark, thanks for the XKCD !  I think I remember that date but I did not think I'd told Munroe about it .... Davo ---------------------------------------------------------------------- Aruna · 2024-09-19 01:45 Quote from: dbannon on September 08, 2024, 02:48:35 amBe interested in hearing how other (Linux) Desktops perform ? Davo @davo, The first screenshot gnome-classic bottom right shows workspaces and the second workspace shows the moved window. Above that is a terminal that shows the desktop is gnome-classicThe second screenshot bottom left shows workspaces and the terminal shows the desktop is LXDE. Something I noticed is with LXDE everything loaded like lightning. Compared to gnome-classic things rendered blazingly fast ---------------------------------------------------------------------- Aruna · 2024-09-19 01:46 Quote from: dbannon on September 08, 2024, 02:48:35 amBe interested in hearing how other (Linux) Desktops perform ? Davo The third screenshot terminal shows the desktop is cinnamon and the fourth screenshot shows cinnamon workspaces and the moved window on workspace two. I will post others as and when I test them. ---------------------------------------------------------------------- dbannon · 2024-09-19 09:23 Hey, thanks Aruna, I take it you found it worked as expected ? Quote from: Aruna on September 19, 2024, 03:45:04 am Something I noticed is with LXDE everything loaded like lightning. Compared to gnome-classic things rendered blazingly fast Yeah, work on Gnome for a little while and everything else seem blindingly fast ! I decided to use that code in my own project, far tidier than using wmctrl as I did previously.  I too have been testing all over the place and, so far, good.  Enlightenment being the exception .... Davo ---------------------------------------------------------------------- Aruna · 2024-09-19 09:42 Quote from: dbannon on September 19, 2024, 11:23:31 amHey, thanks Aruna, I take it you found it worked as expected ? You are most welcome. I only tested moving the window from it's initial workspace to another. I have to test bringing it back from a workspace. What I tested so far, yes works fine.  Btw, very nice how you have the time taken in milli secs. And any thank's should go to @Joanna and her buddy @kee as they were responsible for me finally getting Lazarus to compile under qemu. Quote from: dbannon on September 19, 2024, 11:23:31 amQuote from: Aruna on September 19, 2024, 03:45:04 am Something I noticed is with LXDE everything loaded like lightning. Compared to gnome-classic things rendered blazingly fast Yeah, work on Gnome for a little while and everything else seem blindingly fast ! I was thinking 'what the heck just happened, I am  inside qemu and that took less than a second? Sweet! (Do you know what the lightest fastest WM is please?) Quote from: dbannon on September 19, 2024, 11:23:31 amI decided to use that code in my own project, far tidier than using wmctrl as I did previously.  I too have been testing all over the place and, so far, good.  Enlightenment being the exception .... My friend as a practising Buddhist I can assure you many have and are yet searching for Enlightenment! This is one of the reasons I love Lazarus. Every time I figure out something on my own I get enlightened? ---------------------------------------------------------------------- dbannon · 2024-09-19 11:22 Quote from: Aruna on September 19, 2024, 11:42:36 am... And any thank's should go to @Joanna and her buddy @kee as they were responsible for me finally getting Lazarus to compile under qemu. Wow, you use qemu ?  Its hard work compared to Virtual Box, I only use qemu when I have to make out I have a different CPU. I spent some time running a POWERel emulator when Debian complained that my project would not compile there.  I currently have 29 Linux VM's on my laptop, all for testing my app under Virtual Box at release time. Quote from: Aruna on September 19, 2024, 11:42:36 am(Do you know what the lightest fastest WM is please?) Not from personal testing but its generally agreed that, of the mainstream desktops, its XFCe. And it works reasonably well, just a bit plain sometimes. Quote from: Aruna on September 19, 2024, 11:42:36 amMy friend as a practising Buddhist I can assure you many have and are yet searching for Enlightenment! Ah, yes, Enlightenment is clearly a good idea. Unless you are talking about Linux desktops. I have a good friend who is always trying to convert me to (Linux) Enlightenment and its just not going to happen ! I hope your path to enlightenment is an easier one ! Davo