Add option to restore windows not marked as "sticky" in XPager settings to (original) XPager virtual desktops

[Lewis Rosenthal]

Minimizing a window opened on XPager's Virtual Desktop #1, then switching to Virtual Desktop #2 and restoring that window results in the window (not marked "sticky") being restored to the current Virtual Desktop and not its original Virtual Desktop.

This RFE is to add an option to restore a minimized window to the original desktop from which it was minimized.

This may require additional support in XWorkplace.

[Lewis Rosenthal]

Consider the following XPager layout:

+----------+----------+
|          |          |

|   1      |   2      |
|          |          |
|          |          |
+----------+----------+

Now consider application X (in the sticky list) is opened while the focus
is on Virtual Desktop 1 (VD1). Application X is then minimized on VD1.

The user moves to VD2 and restores the window. Is there a method in
Xworkplace for the window manager (lSwitcher, in this case) to determine the
VD from which X was minimized so that X may be restored to *that* VD instead
of the current one?

As X has been set as sticky, the user would then want it to be restored to
the originating VD, and not just in the same x,y position on the current
desktop.

Use case:

I have a grouping of several windowed command line processes in VD1 and
another set, doing something else, in VD2. Minimizing one of the windows
(call it X) on VD1, switching to VD2, and (possibly inadvertently) restoring
X while working with my "set" of windows on VD2 should not restore X on top
fo the "working set," but instead, should send it to VD1, where it
"belongs." This comes up when I am working with several FTP sessions and
unzipping the resulting files. I keep a group of windows working on one
server in one VD and another group (perhaps two download sessions and two
unzip sessions) in another VD, logged onto different local directories, as
well. I don't want a window from the *other* desktop to suddenly interrupt
my flow on my *present* desktop, simply because that's the active desktop;
instead, I want it to go back from whence it came (before I do something
stupid without looking at my pwd in that restored session).

[Gregg Young]

This was attempted in 2.71. It breaks sticky windows and there isn't a straight forward way to identify sticky window from outside xworkplace. The second problem is this was the major cause of windows going missing on reboots and under some other circumstances. I would probably need to update xworkplace to report sticky windows. Unfortunately the fix for the second problem is harder on normal shutdown I can restore the minimized windows and folders to the home window and wait long enough to allow the inis to save so they won't be lost on the next startup. However, I can't do this if Ctrl-Alt-Del is used to restart. I suppose I could rewrite CAD to do this but I'm not sure it would be worth the effort or is even possible. Even if all this were possible, I would need people to upgrade 3 programs to make it work. I guess it is possible to do since Object Desktop was able to restore programs to specific desktops on restart if I remember correctly.

[Lewis Rosenthal]

In discussing this with Paul Ratcliffe on the Xworkplace Users list, in the thread entitled, Query to find out if a window is sticky, in response to your query, Gregg, of whether there was a method to determine whether a window had been marked sticky in XPager, Paul had this to say:

You might try sending an XDM_ISTRANSIENTSTICKY message (WM_USER + 432) via krnSendDaemonMsg with mp1 containing your target window handle. See the Winlist widget code for details of how to resolve and call this function (src\widgets\w_winlist.c).

I don't know that this has been pursued. Before we close this as wontfix, this might be worth checking for the next release.

[Gregg Young]

I think I looked at this once. While it might be possible with the widget I could see no way to do it with the standalone.

[Gregg Young]

The fact that a window is sticky would need to be stored somewhere assuming that status survives reboots. I wonder where? OS2.INI?

[Gregg Young]

This also needs a consistent way to identify desktop. It must be independent of the configuration and number of desktops.

[rlwalsh]

lswitcher would have no way of knowing where the window should be restored. XPager would have to be modified to save that info.

[Gregg Young]

This is what I thought was the case. Rich thanks for confirming

[Gregg Young]

Resolved as invalid based on Rich's comment 10