Hello,
and thanks for your help.
First, to mention about about firefox: If one runs firefox
on the local machine, restauration after crash are always
correct!
I understand your explanation about the workspace number.
At time of my question, the number of workspaces between
user local and on the server were really different. But this
should not matter, because - more "accidentally" - my test
happened on the first eight workspaces (at that time, the
server have luckily had 8 for this user).
I made the test you mentioned and the _NET_WM_DESKTOP is
always present (before suspend and after restore), BUT
windows, which were located in different workspaces even
do NOT appear - I checked all workspaces (because I use
a lot of them, I have "tools" for this).
To the checks. I save all window properties for my
attempts and a grep over them shows:
test3-win1-ws-6-x-post.txt:_NET_WM_DESKTOP(CARDINAL) = 6
test1-win2-ws-7-post.txt:_NET_WM_DESKTOP(CARDINAL) = 7
test1-win1-ws-6-7-post.txt:_NET_WM_DESKTOP(CARDINAL) = 6
test2-win1-ws-7-post.txt:_NET_WM_DESKTOP(CARDINAL) = 7
test1-win2-ws-7-org.txt:_NET_WM_DESKTOP(CARDINAL) = 7
test2-win2-ws-7-post.txt:_NET_WM_DESKTOP(CARDINAL) = 7
(The 'test1-win1-ws-6-7-post' has had a window on workspace 7
too, which does not appear at resume time).
The last test generates a lot of output, I put it at the end.
I survive a little with scripts, which saves all window titles
(which are not necessarily unique) and I can restore partially
the firefox windows. But gave up - would probably need the
main-window id for the tabs .... But at login, I start eight
caja windows this way.
Please, no notes about my workspaces, I am trying something new
and have a total of 60(!!). Organized into 15 interest zones with
4 prioritry rows - will see, if this make sense (most of the time,
many are empty and will be named later).
The problem with the firefox windows was the massivst problem, due
to the huge amout of windows to re-arrange, but behind it, is the
probably bigger problem: After shutdown or hibernate,most(!) of my
remote sessions do NOT appear at all! Firefox, compared, runs in
a KVM guest an my host and hibernate freeze everything - this survives!
Regards,
Manfred
----- xprop -root | grep -e ^_NET -e ^WM --------
(Could send this as attachment, if wished)
$ xprop -root | grep -e ^_NET -e ^WM
_NET_DESKTOP_LAYOUT(CARDINAL) = 0, 0, 4, 0
_NET_CLIENT_LIST_STACKING(WINDOW): window id # 0x1600028, 0x7e003e5, 0x7e00623, 0x7e00872, 0x820000c, 0x8200bf2, 0x8201937, 0x82025ef, 0x82034d1, 0x8204255, 0x6606e43, 0x840002c, 0x9803f41, 0xa20040d, 0xa200437, 0xa200461, 0xa20048b, 0xa2004a7, 0xa2004d1, 0xa2004fb, 0xa200525, 0xa200541, 0xa20056b, 0xa200595, 0xa2005bf, 0xa2005e9, 0xa200613, 0xa20063d, 0xa200667, 0xa200691, 0xa2006ad, 0xa2006d7, 0xa200701, 0xa20072b, 0xa200755, 0xa200771, 0xa20078d, 0xa2007b7, 0xa2007e1, 0xa20080b, 0xa200835, 0xa200851, 0xa20087b, 0xa2008a5, 0xa2008cf, 0xa2008eb, 0xa200915, 0xa200931, 0xa20095b, 0xa200985, 0x66081ac, 0x9200007, 0x9a00003, 0xa600007, 0x7600256, 0x7600268, 0x7600271, 0x7600283, 0x760027a, 0x760029e, 0x76002a7, 0x76002b0, 0x76002c2, 0x76002b9, 0x76002dd, 0x76002cb, 0x76002ef, 0x7600301, 0x760030a, 0x76002f8, 0x760031c, 0x7600340, 0x7600349, 0x7600352, 0x760044a, 0x7600468, 0x7600471, 0x7600634, 0x9c00003, 0x7600746, 0x666fa22, 0x667013f, 0x66708b8, 0x7605ccd, 0x760ae3a, 0x7610447, 0xb800007, 0x761df90, 0xba00006, 0x7628f61, 0x765381e, 0x6693712, 0x766809f, 0x76681b7, 0x7668218, 0xc800008, 0x7674e37, 0x768aba2, 0x76a6a45, 0x76b5aeb, 0x76bda67, 0x76c76a4, 0x76c76d2, 0x76f7665, 0xa400008, 0x772ec73, 0x830a51c, 0x66c40d1, 0x66d836f, 0xca0000c, 0x7780a47, 0x7780ae9, 0x778a22c, 0x668655a, 0x6600003, 0x660015a, 0x6600105, 0x660005e, 0x6800030, 0xb600003, 0x6601471, 0x6601654, 0x660270f, 0x66025dc, 0xa800003, 0xb201219, 0xb200205, 0x666f154, 0x666cc1a, 0x66710db, 0xae00011, 0x66f10d5, 0x774e3fb, 0x774602c, 0x775b01b, 0x7746082, 0x668071a, 0x66bdafc, 0x66e6679, 0x66c5ab2, 0xcc00003, 0x76002d4, 0x76002e6, 0x6601fb4, 0x6601ff8, 0x66e283d, 0x66c8c74, 0x6800011, 0xc200e9f, 0x66c5329, 0x66e8c6a, 0x66d65ae, 0x66e4cc3, 0x66e8d17, 0x66d72ec, 0x775b116, 0x66f2fd0, 0x771543d, 0x7715389, 0x76ff2b2, 0x77265ff, 0x76c91ef, 0x771545f, 0x76eba78, 0x76d1ece, 0x76f1cf3, 0x76f77ed, 0x76cc87d, 0x76ce82f, 0x802933c, 0x8204dd3, 0x76d1df2, 0x779c3a4, 0x680003c, 0x6800048, 0x779c3c9, 0x779eeb7, 0x829b5c5, 0x8297927, 0x824aeac, 0x6a85792, 0xbe0cd50, 0xa634a91, 0x77a1f24, 0x6a00007, 0x77b9496, 0x77c4aba, 0x77c768c, 0x77a1f48, 0xa634b91, 0x7e0006f, 0x66ffbd3, 0x77e6a13, 0x6603a9f, 0x77e6a61, 0x77de574, 0x6700733, 0x77f2c39, 0x900021c, 0x6a00e44, 0x7800061, 0x7e00246, 0x77c76be, 0xa63b44a, 0x980436c, 0x67007d2, 0x1800012, 0x180001a, 0x180001e, 0x1800016, 0x1800023, 0x1800003, 0x804fe20
_NET_CLIENT_LIST(WINDOW): window id # 0x1800003, 0x1800012, 0x1800016, 0x180001a, 0x180001e, 0x1800023, 0x1600028, 0x6600003, 0x660005e, 0x6600105, 0x660015a, 0x6800011, 0x6800030, 0x680003c, 0x6800048, 0x6601471, 0x6a00e44, 0x6601654, 0x6601fb4, 0x6601ff8, 0x66025dc, 0x660270f, 0x6603a9f, 0x7e0006f, 0x7e00246, 0x7e003e5, 0x7e00623, 0x7e00872, 0x820000c, 0x8200bf2, 0x8201937, 0x82025ef, 0x82034d1, 0x8204255, 0x8204dd3, 0x6606e43, 0x840002c, 0x9803f41, 0xa20040d, 0xa200437, 0xa200461, 0xa20048b, 0xa2004a7, 0xa2004d1, 0xa2004fb, 0xa200525, 0xa200541, 0xa20056b, 0xa200595, 0xa2005bf, 0xa2005e9, 0xa200613, 0xa20063d, 0xa200667, 0xa200691, 0xa2006ad, 0xa2006d7, 0xa200701, 0xa20072b, 0xa200755, 0xa200771, 0xa20078d, 0xa2007b7, 0xa2007e1, 0xa20080b, 0xa200835, 0xa200851, 0xa20087b, 0xa2008a5, 0xa2008cf, 0xa2008eb, 0xa200915, 0xa200931, 0xa20095b, 0xa200985, 0x66081ac, 0x802933c, 0x9200007, 0x9a00003, 0x804fe20, 0xa600007, 0x7600256, 0x7600268, 0x7600271, 0x7600283, 0x760027a, 0x760029e, 0x76002a7, 0x76002b0, 0x76002c2, 0x76002b9, 0x76002d4, 0x76002dd, 0x76002cb, 0x76002e6, 0x76002ef, 0x7600301, 0x760030a, 0x76002f8, 0x760031c, 0x7600340, 0x7600349, 0x7600352, 0x760044a, 0x7600468, 0x7600471, 0x7600634, 0x9c00003, 0x7600746, 0x666cc1a, 0x666f154, 0x666fa22, 0x667013f, 0x66708b8, 0xae00011, 0x66710db, 0xb200205, 0xb201219, 0x7605ccd, 0xa800003, 0x760ae3a, 0x7610447, 0xb600003, 0xb800007, 0x761df90, 0x668071a, 0xba00006, 0x7628f61, 0x668655a, 0x765381e, 0x6693712, 0x766809f, 0x76681b7, 0x7668218, 0xc800008, 0x7674e37, 0x768aba2, 0x76a6a45, 0x76b5aeb, 0x824aeac, 0x76bda67, 0x76c76a4, 0x76c76d2, 0x76c91ef, 0x76cc87d, 0x76ce82f, 0x76d1df2, 0x76d1ece, 0x76eba78, 0x76f1cf3, 0x76f7665, 0x900021c, 0x76f77ed, 0xa400008, 0x76ff2b2, 0xbe0cd50, 0x8297927, 0x7715389, 0x771543d, 0x771545f, 0x77265ff, 0x772ec73, 0x829b5c5, 0x830a51c, 0x66bdafc, 0x66c40d1, 0x66c5329, 0x66c5ab2, 0x66c8c74, 0x66d65ae, 0x7800061, 0x66d72ec, 0x66d836f, 0x980436c, 0xc200e9f, 0x66e283d, 0x774602c, 0x7746082, 0x66e4cc3, 0x66e6679, 0x66e8c6a, 0x66e8d17, 0x774e3fb, 0x775b01b, 0x66f10d5, 0x6a85792, 0x66f2fd0, 0x775b116, 0x6a00007, 0xcc00003, 0xca0000c, 0x7780a47, 0x7780ae9, 0x778a22c, 0x779c3a4, 0x779c3c9, 0x779eeb7, 0x77a1f24, 0x77a1f48, 0xa634a91, 0x77b9496, 0x77c4aba, 0x77c768c, 0x77c76be, 0x77de574, 0xa634b91, 0x77e6a13, 0x66ffbd3, 0x77e6a61, 0x77f2c39, 0x6700733, 0xa63b44a, 0x67007d2
_NET_DESKTOP_NAMES(UTF8_STRING) = "mail 1", "pol-info 2", "pol-extra 3", "pol-more 4", "pol-todo 5", "POL-SoZMed/Main 6", "adm-boxes 7", "adm-search 8", "adm-misc 9", "VMs 10", "Wokspace 11", "admin-base 12", "ws 13", "work-boxes 14", "Workspace 15", "fbox/fun/music 16", "devil 17", "Restore-SIMS 18", "Infra-Extras 19", "infra-edit 20", "infra-misc 21", "infra-anal 22", "admin-logs 23", "admin-gui 24", "Workspace 25", "Workspace 26", "Workspace 27", "Workspace 28", "Workspace 29", "Workspace 30", "User-Org 31", "Workspace 32", "Workspace 33", "Workspace 34", "Workspace 35", "Workspace 36", "Workspace 37", "Workspace 38", "Workspace 39", "Workspace 40", "Workspace 41", "Workspace 42", "Workspace 43", "Workspace 44", "Workspace 45", "Workspace 46", "Workspace 47", "Workspace 48", "Workspace 49", "Workspace 50", "Workspace 51", "Workspace 52", "Workspace 53", "Workspace 54", "InfraDocs 55", "Workspace 56", "Workspace 57", "Workspace 58", "Workspace 59", "Workspace 60", ""
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x67007d2, 0x0
_NET_CURRENT_DESKTOP(CARDINAL) = 0
_NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0
_NET_DESKTOP_GEOMETRY(CARDINAL) = 2560, 1600
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x1000122
_NET_SUPPORTED(ATOM) = _NET_ACTIVE_WINDOW, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_CLOSE_WINDOW, _NET_CURRENT_DESKTOP, _NET_DESKTOP_GEOMETRY, _NET_DESKTOP_LAYOUT, _NET_DESKTOP_NAMES, _NET_DESKTOP_VIEWPORT, _NET_FRAME_EXTENTS, _NET_MOVERESIZE_WINDOW, _NET_NUMBER_OF_DESKTOPS, _NET_REQUEST_FRAME_EXTENTS, _NET_SHOWING_DESKTOP, _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_SYSTEM_TRAY_OPCODE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK, _NET_WM_ALLOWED_ACTIONS, _NET_WM_BYPASS_COMPOSITOR, _NET_WM_CONTEXT_HELP, _NET_WM_DESKTOP, _NET_WM_FULLSCREEN_MONITORS, _NET_WM_ICON, _NET_WM_ICON_GEOMETRY, _NET_WM_ICON_NAME, _NET_WM_MOVERESIZE, _NET_WM_NAME, _NET_WM_OPAQUE_REGION, _NET_WM_PID, _NET_WM_PING, _NET_WM_STATE, _NET_WM_STATE_ABOVE, _NET_WM_STATE_BELOW, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_FOCUSED, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_HIDDEN, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MODAL, _NET_WM_STATE_SHADED, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY, _NET_WM_STRUT, _NET_WM_STRUT_PARTIAL, _NET_WM_SYNC_REQUEST, _NET_WM_SYNC_REQUEST_COUNTER, _NET_WM_USER_TIME, _NET_WM_USER_TIME_WINDOW, _NET_WM_WINDOW_OPACITY, _NET_WM_WINDOW_OPACITY_LOCKED, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_DESKTOP, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WORKAREA, _GTK_FRAME_EXTENTS, _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED, _GTK_SHOW_WINDOW_MENU, _NET_STARTUP_ID
_NET_WORKAREA(CARDINAL) = 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517, 0, 83, 2560, 1517
_NET_NUMBER_OF_DESKTOPS(CARDINAL) = 60
=================================================
----- Original Message ----- From: Ulrich Sibiller [
mailto:uli42@gmx.de] To: <webman@manfbraun.de>
Cc: x2go-user@lists.x2go.org
Sent: Mon, 20 Mar 2023 00:27:51 +0100
Subject: Re: [X2Go-User] Resume/restoration of windows to linux workspaces
Well,
thinking about this...
Typically a window manager will store the workspace to use in the
_NET_WM_DESKTOP property of a window. You can check that with xprop |
grep _NET_WM_DESKTOP (selected the window you are interested in with
the mouse). Alternatively you can run xprop -id <windowid> | grep
_NET_WM_DESKTOP.
Whenever a published application opens a window it will open this
window on the x2goagent/nxagent on the server AND open a clone window
on you local X server. Internally the agent has a mapping between the
window ids of each window pair. On suspend the windows on the local X
server are closed, the ones on the agent stay. On resume/reconnect the
agent winn again open (new!) clone windows on the local X server and
update their window ids in its list.
When the local window manager sets the _NET_WM_DESKTOP property the
agent will register this and _should_ update the _NET_WM_DESKTOP
property on the agent side window, too.
If a client changes a window property the agent will forward this
change to the twin window on the local X server EXCEPT for properties
starting with for WM_, _NET_ and for the
_KDE_NET_WM_SYSTEM_TRAY_WINDOW_FOR property. So if firefox is trying
to handle these properties itself this might explain why the workspace
is not honored (just speculating, have not tested further).
But I am wondering: If, e.g., a window was placed on, say, workspace 4
and then suspended and the resume happens on a setup that only has one
or two workspaces what would happen?
Also there might be further problems arising from restored windows
having an other window id than previously. If the window manager
chooses to store some workspace information depending on the window id
(I don't know if any WM is doing this) this will not work with the
restored windows.
I am also wondering if setting the desired workspace by the client (in
this case the agent is a client to the local X server) is honored by
the WM at all.
So can you please to some tests with the xprop command described above
(run it from a local terminal, NOT from a published application) and
check the properties of those windows before and after the reconnect?
Does the _NET_WM_DESKTOP property get lost?
Please also post the output of xprop -root | grep -e ^_NET -e ^WM -
this will show the window manager related configuration.
Uli
On Sun, Mar 19, 2023 at 11:02 PM <webman@manfbraun.de> wrote:
>
> Hello Uli!
>
> Thanks for your reply.
>
> Published applications are not necessarily one-window, strictly
> spoken, a terminal with two tabs has (at least) two windows. As
> long as they are inside the terminals main-window, everything works
> (sad to say: most of the time).
> If there are two separate windows, which are in the current
> workspace, this works too.
> Below of that, it gets complicated.
> If two windows are in separate workspaces, it works sometimes.
> I am not sure, why at all - from your guess.
> If you have two terms at WS1 and WS3 and you resume on WS5,
> NO window appear at all, though the processes are running
> well on the server side!
> For firefox, this is more different.
> From several windows, which were originally located in different
> workspaces, only one window will be restored, this of the current
> workspace. If all were located in the same workspace, they are
> restored to the current workspace, if you are in that workspace,
> which was current at 'suspend' time - otherwise: NO window
> appear at all!
> But for the first case, it gets interesting.
> Go to 'more tools/taskmanager' (of the fox!), you'll see all
> windows as processes. Double-clicking on of them brings it
> back to the workspace were it was originally located!
> Works for all of them.
> Back to the first cases above.
> If a session is restored by the x2go-client (I do not know
> about this, due to lack of documentation), it knows all
> windows and restores them - so ether the session on the server
> or the client must give the window-manager advice.
> I am starting my caja browsers at logon this way and they will
> be even tagged to be visible on all workspaces.
> So suspending a session must save the workspace accordingly.
> I asked me, on which side, the workspace will be read at all,
> server oder client? Just to be sure to have the same number
> of WSs, I made them equal (for the testuser), but this does
> not change anything (may be, a restart is necessary?).
>
> From toolchains perspective, X(&co.) were never made for
> suspending window sessions (at least, so far I know) and
> the window manager is only a filter for the workspace numbers.
> What remains is, that only x2go can handle this at all.
>
> This was - a little - exploration, which shed me light on
> the sessions, which do not work after return from hibernate
> my box in the morning.
>
> Regards,
> Manfred
>
>
> ----- Original Message -----
> From: Ulrich Sibiller [mailto:uli42@gmx.de]
> To: <webman@manfbraun.de>
> Cc: x2go-user@lists.x2go.org
> Sent: Fri, 17 Mar 2023 08:29:50 +0100
> Subject: Re: [X2Go-User] Resume/restoration of windows to linux workspaces
>
> Hello Manfred,
>
> in published applications mode the local window manager should be responsible for arranging the application windows. The application itself does not know about the workspaces at all. So probably the window manager does not recognize the restored windows as previously known windows. I have no idea at the moment how to even check if this theory applies here. You could try to run another desktop environment locally and check if the behaviour changes.
>
> Uli
>
> <webman@manfbraun.de> schrieb am Fr., 17. März 2023, 03:19:
>>
>> Hello!
>>
>> I am using published applications to run firefox.
>> I am on debian bullseye (client and server).
>> There is a big behavioral difference from using fox between
>> this and using fox local in regard of crash and restore.
>> If the fox restores a crashed window set locally, all windows
>> appear on the workspace, they were originally running on.
>> Not so with x2go - they all appear in the workspace, were
>> the restauration starts.
>> I usually have >50 windows and this is a big pain.
>> Is this the normal behavior?
>> If not, where to look for the problem?
>> Note, this does not depend on a users profile.
>> I created an additional user on the server and it behaves the same.
>>
>> Thanks,
>> Manfred
>>
>> _______________________________________________
>> x2go-user mailing list
>> x2go-user@lists.x2go.org
>> https://lists.x2go.org/listinfo/x2go-user