browser moves to workplace when link clicked in program on other workplace

[netfun81]

When clicking a web link in a program on lets say desk2, if a browser is already open on desk1 it will now move to desk2. I prefer the browser would not move but the bigger issue is that it has some buggy behavior as it will disappear from all virtual desktops when switching between them. Cycling through the desktops again will make it reappear but its not easy to return to previous behavior as pressing Mod-Shift 1 will not make it stay back on desk1. The only way to fix it seems to be to close the browser and open another one on the correct desktop.

Its a minor annoyance but thought I would mention it, otherwise good work on a nice minimal window manager and I like how you added possible upgrades via patches!

[ghost]

Looks like this is caused by the following sequence of events:

1. Some client already exists in a currently unmapped ws_list
2. In another workspace, something happens that causes a new client with the same Window (such as a web browser) to be created and added to that ws_list.
3. The user switches back to the workspace where the Window already exists causing ws_go to first map all the Windows in the new workspace and then unmap all the Windows in the old workspace.

Since the same Window is in both workspaces, it's mapped and then immediately unmapped which will cause the window not to be visible and alt+tab will seem to work improperly as it has to cycle over a client with an unmapped Window. However, one can switch to a third workspace and then back to the original and the window will appear there as normal.

Presumably windows from the switching-to workspace are mapped before windows in the switching-from workspace are unmapped to avoid a brief flicker where no clients would be onscreen between workspace changes. Switching the order of mapping and unmapping would fix the problem of the buggy visibility at that expense but..

The real problem is that new clients can be created that have the same Window as another client. It's possible to do something like the above steps and send a dozen clients with the same Window to the same workspace so that alt+tabbing through the ws_list will appear to be buggy.

Since this program uses linked lists, I don't see how to fix this without either brute force searching the entire array of lists, creating a list of Windows and having to do a search linear in the number of all Windows, or significantly altering the architecture of the program by adding some kind of hash to check for uniqueness. With the conciseness and simplicity of this program, none of these seem like a good option.

Thoughts?

[netfun81]

Just wanted to leave a note that the patch that Stutonk made shown above, fixed the issue for me. Thanks Stutonk that eliminated an annoyance.