inconsistent positioning of restored app window on virtual desktop (using xPager's sticky window option)

[Lewis Rosenthal]

This used to work correctly with 2.7.0.

Consider:

• xPager configured for 3x2 virtual desktops. Start in lower left desktop.
• Dave Saville's ClipView minimized, and configured as sticky in xPager
• Restore ClipView from taskbar. ClipView opens in lower left of current desktop.
• Minimize ClipView.
• Restore ClipView. ClipView again opens in lower left of current desktop.
• Switch desktops.
• Restore ClipView. ClipView is restored off the bottom of the lower left window, requiring Alt-F7 to position it in any virtual desktop.

Expected behavior:

Windows restored from lSwitcher's taskbar, if set to sticky in xPager, should restore to the same relative position on the current desktop (as I say, this used to work).

I have not tested with the widget, as I don't use it. Restoring from popup window is also inconsistent, but app window shows up in yet a different spot (to the left or right of the current virtual desktop).

Taskbar settings:

Switch to PM from FS
Show hints
No sticky popup window
No popup window exclusions
Taskbar enabled
Auto-hide
Flat buttons
3D look
Default icons only
Bottom of screen
No taskbar exclusions

[Lewis Rosenthal]

[Comment intentionally deleted.]

[Lewis Rosenthal]

Also just realized that I meant to clarify that I am using lSwitcher 2.8.1, installed from the WPI package.

N.B.: It might be useful to customize the version and perhaps the component fields for this project. If this is an issue, perhaps I can help.

[Andy Willis]

I can confirm, if I minimize clipview and change virtual desktops and then restore it restores off screen. I have not yet tested other applications to verify other apps also exhibit this but I have no reason to suspect it is isolated to the one app at this time. It did not seem to make a difference how I changed between desktops nor how I restored the application. This did make me realize my xpager box was showing off screen.

[Andy Willis]

My xpager was missing I believe due to this problem. When I could not find it I set it to stay on top and removed the flash to top option. Now that I returned it to normal, if I change virtual desktops, I can see the xpager window flash up just off screen (I can just see the edge of it).

[Andy Willis]

It could also be the cause of my window list showing offscreen initially. I'll have to perform some testing in the coming days as I hopefully get some time to do so.

[Andy Willis]

Here is the code in the code that mentions the virtual desktop from common.c. Most of it was commented out for 2.71... I changed it to #if so I could change it easily but it hasn't seemed to make any difference.

//returns TRUE if any part of the hwnd is currently within desktop
BOOL IsInDesktop(HAB hab, HWND hwnd, LONG lCurrDesktop)
{
    SWP swp;
    RECTL rcl1, rcl2, rcl3;
    USHORT usCXScreen = WinQuerySysValue(HWND_DESKTOP, SV_CXSCREEN),
	usCYScreen = WinQuerySysValue(HWND_DESKTOP, SV_CYSCREEN);

    WinQueryWindowPos(hwnd, &swp);
#if 0  // Was added as commented out in 2.71
  if (swp.fl & SWP_MINIMIZE) {
    swp.x = WinQueryWindowUShort(hwnd,QWS_XRESTORE); swp.y = WinQueryWindowUShort(hwnd,QWS_YRESTORE);
    swp.cx = WinQueryWindowUShort(hwnd,QWS_CXRESTORE); swp.cy = WinQueryWindowUShort(hwnd,QWS_CYRESTORE);
  }
#endif
    WinSetRect(hab, &rcl1, swp.x, swp.y, swp.x + swp.cx, swp.y + swp.cy);

// +8 may need to be added to CXScreen and CYScreen as virtual desktop dimensions seem to be 8 points larger than screen size
#if 0  // Was added as commented out in 2.71
  WinSetRect(hab,&rcl2,
             usCXScreen*((lCurrDesktop&0xFF00)>>8),usCYScreen*(lCurrDesktop&0xFF),
             usCXScreen*(((lCurrDesktop&0xFF00)>>8)+1),usCYScreen*((lCurrDesktop&0xFF)+1));
#endif

    WinSetRect(hab, &rcl2, 0, 0, usCXScreen, usCYScreen);

    WinIntersectRect(hab, &rcl3, &rcl1, &rcl2);

    return (!WinIsRectEmpty(hab, &rcl3));
}

#if 0  // Was commented out in 2.71
//get the virtual desktop number relative to the one in which the program was started
LONG GetCurrDesktop(LSWDATA *plswData)
{ USHORT usCXScreen=WinQuerySysValue(HWND_DESKTOP,SV_CXSCREEN),
         usCYScreen=WinQuerySysValue(HWND_DESKTOP,SV_CYSCREEN);
  SWP swp;
  SHORT x,y;

  if (plswData->bNowActive) return -1;

  WinQueryWindowPos(plswData->hwndPopup,&swp);
  x=(POPUPWINHIDEPOSX-swp.x)/usCXScreen;
  y=(POPUPWINHIDEPOSY-swp.y)/usCYScreen;
  return ((x<<8)+y);
}
#endif

[Andy Willis]

I have noticed one other thing that may be related... without lswitcher running, if I minimize an app and then go to another desktop and then switch to it, it comes up on the current desktop. With lswitcher running, if I minimize the app, go to another desktop and switch to it, it switches back to the original desktop where it was minimized. I am fairly certain that is new behavior.

[Andy Willis]

The minimized app I mentioned in comment #43 is certainly new, as this is from the readme:

Hidden and minimized to viewer windows are always restored to the current
virtual desktop. This is an XPager feature/limitation.

Still don't know that it is related though.

[Gregg Young]

I believe that common.c is the most likely place for this to have occurred. Are we sure the problem was not present in 2.71? I don't see how any of the post 2.71 changes effected this. If it really didn't exist in 2.71 was it present in 2.80? One way to find this is to build the change sets splitting the difference between working and nonworking until we find the change that caused it.

[Gregg Young]

I just tested this. It is version 2.71 where this occurred. I will look through the diff for possible culprits. Andy I think you have found part of it.

[Gregg Young]

I tried to narrow this down with very little success. The code in the comment above doesn't seem to be the issue. The only interesting thing I found is that by adding different amounts to x and y in this formula((x<<8)+y) I can change where the program misses the desktop (ie I can move it to the left or right or above and below). The code was changed significantly between 2.70 and 2.71 so it is difficult to determine what change may have caused this and it is also difficult to revert the changes.

[Lewis Rosenthal]

Sorry to be so late getting back to this party, guys... I keep forgetting that email notifications from here don't work.

Some additional comments:

Andy, per your comment 7, I can confirm both that this happens and that it is new.

Per comment 9, the build I have been using for some time is:

4-11-04 16:14 105,526 1,273 lSwitch.exe

which may in fact be 2.70. ISTR you and I having a conversation a decade or so ago about complaints we both had with 2.71, and I believe I rolled back to 2.70 immediately after.

Re comment 11, Gregg: LOL - At least you know how to adjust how far off it is!

Sadly, this is one of those things which for those of us who rely on multiple desktops for our daily work, is a show-stopper.

Please let me know if there is anything else I may provide in terms of testing.

[Gregg Young]

if (x != oldx

y != oldy) {

SWP swp;
HWND hwndNext;
USHORT k;
BOOL bMinMax;
HENUM henum = WinBeginEnumWindows(HWND_DESKTOP);

while ((hwndNext = WinGetNextWindow(henum)) != NULLHANDLE) {

WinQueryWindowPos(hwndNext, &swp);
if (swp.fl & SWP_MINIMIZE) {

DebugHereIAm();
for (k = 0, bMinMax = FALSE;

k < MINMAXITEMS && !bMinMax; k++)

if (plswData->MinMaxWnd[2 * k] == hwndNext)

bMinMax = TRUE;

if (!bMinMax) {

swp.x =

WinQueryWindowUShort(hwndNext, QWS_XRESTORE);

swp.y =

WinQueryWindowUShort(hwndNext, QWS_YRESTORE);

swp.x += (oldx - x) * (usCXScreen + 8);
swp.y += (oldy - y) * (usCYScreen + 8);
WinSetWindowUShort(hwndNext, QWS_XRESTORE, swp.x);
WinSetWindowUShort(hwndNext, QWS_YRESTORE, swp.y);

}

}
else if (swp.fl & SWP_HIDE) {

swp.x += (oldx - x) * (usCXScreen + 8);
swp.y += (oldy - y) * (usCYScreen + 8);
WinSetWindowPos(hwndNext, 0, swp.x, swp.y, 0, 0,

SWP_MOVE);

DebugHereIAm();

}

}
WinEndEnumWindows(henum);

}

[Gregg Young]

This is the code that causes this behavior. It is also the code that take you back to the desktop the window was on when you minimized it. I am guessing there is a way to query if a window is sticky. I if I could do that we could have the feature of minimized windows being restored on the desktop they were minimized on without breaking sticky windows.

[Lewis Rosenthal]

Wow... Notifications via email! Nice to be in the loop again. ;-)

As this worked in 2.70, Gregg, perhaps a look through that code might shed some light. If not, perhaps I might persuade Paul to weigh in on this issue. That said, have a look at ​common.c, line 440, et. seq. from version 2.70. Does any of this help?

[Gregg Young]

I already posted a query in the netlabs xworkplace newsgroup as to how to query if a window is sticky. Hopefully it is easy. if it isn't I will go back to the 2.70 behavior which I now know how to do.

[Lewis Rosenthal]

You might have been better off posting that to the xworkplace devel list, though most of the same crowd hangs out in both places. :-)

[Andy Willis]

Replying to gyoung:

This is the code that causes this behavior. It is also the code that take you back to the desktop the window was on when you minimized it. I am guessing there is a way to query if a window is sticky. I if I could do that we could have the feature of minimized windows being restored on the desktop they were minimized on without breaking sticky windows.

I supposed one advantage of not getting notifications is that I would stop trying to reply via email:
Can this be *easily* set as a configuration? I often wanted a minimized
app to show up on the desktop I was on. If not it is not a big deal.
Also, we might need to special case the window list as it shows the same
issue as a sticky window if ctrl-esc is used (chording the mouse of course
brings it to the correct location). Though, I suppose, it may be possible to add the window list to the sticky windows.

[Gregg Young]

Paul indicated there isn't a way to determine if a window is sticky outside of xworkplace, I just gave him a more complete explanation of what I was trying to do and perhaps he will have a suggestion for achieving it but I am not optimistic particularly for the standalone version. I could still add a setting to allow the new behavior with a warning about sticky windows.

[Lewis Rosenthal]

I think we should close this, and perhaps open an enhancement ticket to add this functionality (which may require an update to XWP to support such a hook, based upon what we've heard from Paul thus far). Certainly the subject of this ticket has been addressed.

Gregg: if that code has not yet been checked in, you might want to do that. ;-)

[Andy Willis]

I wanted to put this in last night but was getting 40+% packet loss.
We could do this by adding a new screen to the settings, one similar to the exclude screens we have now. In it we could list the applications that are sticky like we do the exclude windows. It would have a checkmark for whether sticky windows support is needed.
It can then be handled in one of two ways:
Either the user has to input it here as well as xpager or we handle it and suggest the user not put them into the xpager sticky window.
Each has its own advantages and disadvantages. The user either has to put it into both locations or they have to have lswitcher running to have sticky windows as it is not in xpager but only has to input it into one location. We would want to add the window list.

[Lewis Rosenthal]

Andy, I think that's a new RFE ticket (restoring to the original desktop). ;-)