Issue 66 in mdesktop: Fast switching desktop causes window disappearing
mdes...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 66 by fer...@gmail.com: Fast switching desktop causes window
disappearing
http://code.google.com/p/mdesktop/issues/detail?id=66
What steps will reproduce the problem?
1. Minimize all windows on desktop 2
2. switch rapidly back and forth from desktop 1 (delays of ~5ms to 500ms)
3. check on desktop 2 - windows no longer on taskbar. Orphaned somewhere.
What is the expected output? What do you see instead?
Windows should remain where placed. They're still running, as I still hear
audio through one of the "disappeared" firefox windows
What version of the product are you using? On what operating system?
1.6 beta. Win 7 SP1. Possibly of note: my taskbar is not at the bottom,
but rather on the right side.
Please provide any additional information below.
Maybe there should be an "orphaned window" dialogue for windows not
assigned to current valid desktops? or it should dump to desktop 1 or n?
mdes...@googlecode.com
Comment #1 on issue 66 by fer...@gmail.com: Fast switching desktop causes
window disappearing
http://code.google.com/p/mdesktop/issues/detail?id=66
(distinct from bug 62). Also closing mDesktop did not collapse these
hidden windows to desktop 1. Relaunching mdesktop did not result in seeing
these windows on any of the desktops.
mdes...@googlecode.com
Comment #2 on issue 66 by jacerox1234: Fast switching desktop causes window
disappearing
http://code.google.com/p/mdesktop/issues/detail?id=66
Hm alright, I have an idea for how to fix this.
In 1.6b1 I currently have a text file that stores all of the open windows.
This is only erased if the program exits correctly. This is in case the
program crashes.
What I need to do is also cycle through that list when the program exits,
displaying all of the closed windows.
mdes...@googlecode.com
Status: Accepted
Comment #3 on issue 66 by jacerox1234: Fast switching desktop causes window
disappearing
http://code.google.com/p/mdesktop/issues/detail?id=66
(No comment was entered for this change.)
mdes...@googlecode.com
Labels: Version-mDesktop1.6Beta
Comment #4 on issue 66 by jacerox1234: Fast switching desktop causes window
mdes...@googlecode.com
Comment #5 on issue 66 by fer...@gmail.com: Fast switching desktop causes
window disappearing
http://code.google.com/p/mdesktop/issues/detail?id=66
A related/the same bug appeared for me today. I was fast scrolling through
my desktops (control-arrow key). My primary desktop had been #1, but now
all the taskbar items from desktop #1 are now on desktop #2. Applications
that had been on the #2 taskbar are still running, but are not listed on
any of my desktops (1-4)
still on the officially provided 1.6 beta build
I will try to cntrl-alt-delete to rescue the orphaned windows after saving
my work.
mdes...@googlecode.com
Comment #6 on issue 66 by fer...@gmail.com: Fast switching desktop causes
window disappearing
http://code.google.com/p/mdesktop/issues/detail?id=66
control-alt-delete did not restore orphaned windows. will note on the
appropriate bug report where you note that as a solution
mdes...@googlecode.com
Comment #7 on issue 66 by fer...@gmail.com: Fast switching desktop causes
window disappearing
http://code.google.com/p/mdesktop/issues/detail?id=66
Quick note: I've added a couple of comments to bug 15 that are relevant.
Additionally, I think this issue could be ameliorated by a slight change in
mDesktop's behavior (which hopefully would not result in it being "laggy").
When switching desktops
1) check flag on current ("old") desktop to see if all relevant windows
have been added (see below for more flag details).
2) Save Z-index of the application as well as the window within the
application (both in terms of display as well as on the taskbar) as well as
the minimization state of the window if needed. This step prevents
re-reshuffling of windows on restore.
3) Hide windows on the current desktop (in reverse Z index order?)
4) Flag new desktop number as "locked"
5) Restore windows on new desktop in proper Z-index order
6) Clear mDesktop's z-index cache for new desktop
7) Flag new desktop number as "unlocked"
If a window is "sent" to a new desktop, it should z-index stack at the
bottom (window wise, as well as if the application isn't loaded on that
desktop, also the app), but appear non-minimized
If the flag is locked in step 1, either a) pause for all windows to appear
and the flag to be unlocked or b) skip step 2 and just re-hide the windows,
assuming you haven't cleared the Z-index data for the current desktop, and
clear the lock flag for the current desktop.
A) would be more robust but would inhibit you from switching desktops
quickly (either it would swallow and lose the switch signal or store it in
a buffer not longer than the number of desktops).
B) wouldn't be any more laggy than the current model, or at least not
noticeably so. However, if a window was spawned by the user before all the
windows on the transient desktop can propagate and the user switches away
before the propagation can complete, the new window would be orphaned.
However, unless the user has hundreds of windows to restore, this should
not be an issue.
Perhaps the issue in B could be circumvented by there being a "desktop
modified" flag when a new window is spawned, which would force method A or
an appending of the Z-index data for the desktop for this window.
This hybrid appending approach would look like (excuse the
beginning "BASIC" like logic)
1) check lock flag on current desktop to see if all relevant windows have
been added
if locked do Step 97, else do step 2
97) Check "desktop modified" flag (or otherwise detect if there are visible
windows that do not appear in the current Z-index for the current
desktop). If set goto 98, if not set goto 99.
98) Append Z-index data for newly spawned windows (e.g. visible windows not
appearing in the data file for the current desktop) to the already-existing
Z-index for the current desktop.
99) Unset "desktop modified" flag as well as lock flag for current desktop.
100) Goto step 3
2) Save Z-index of the application as well as the window within the
application (both in terms of display as well as on the taskbar) as well as
the minimization state of the window if needed. This step prevents
re-reshuffling of windows on restore.
3) Hide windows on the current desktop (in reverse Z index order?)
4) Flag new desktop number as "locked"
5) Restore windows on new desktop in proper Z-index order
6) Clear mDesktop's z-index cache for new desktop
7) Flag new desktop number as "unlocked"
mdes...@googlecode.com
Comment #8 on issue 66 by jacerox1...@gmail.com: Fast switching desktop
http://code.google.com/p/mdesktop/issues/detail?id=66
Issue 134 has been merged into this issue.
mdes...@googlecode.com
Comment #9 on issue 66 by colinpof...@gmail.com: Fast switching desktop
http://code.google.com/p/mdesktop/issues/detail?id=66
I get a similar issue, and critically there seems to be no way of
recovering the lost windows. They show up in task manager so I can confirm
are all running. I have been very happy with mDesktop (had just donated
before this happened), but this does seem to be a show stopper for me.
I would consider just having a way to manually rescue orphaned windows a
satisfactory solution.
mdes...@googlecode.com
Comment #10 on issue 66 by efial...@gmail.com: Fast switching desktop
I have the same problem and I also would appreciate it if we can have a
workaround until you fix the problem. I have seen the following work for me
sometimes:
- Using Process Explorer from sysinternals sometimes I get the window back
with Right click -> Window -> Bring to Front
- If I start logging off and I haven't saved a document, Word shows up
again to ask if I want to save the document. I stop the log-off process and
I at least get that window back
The above are far from ideal though and don't work all the time. I
personally get most affected when I have a big visual studio solution that
took a long time to load and now it is running in the background with no
way for me to bring it back except for killing it and starting over.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
mdes...@googlecode.com
Comment #11 on issue 66 by bor...@gmail.com: Fast switching desktop causes
window disappearing
http://code.google.com/p/mdesktop/issues/detail?id=66
FYI: you can manually recover the lost windows using Process Hacker. Use
View/Windows, sort, right click the lost window and select Visible.
Unfortunately the on-crash recovery doesn't work, also, settings are not
persistent. Too bad, with some bugfixes this could be the single best
desktop switcher. Hope bugs will be fixed one day.