-
Notifications
You must be signed in to change notification settings - Fork 460
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
With isolate workspaces enabled, prevent multiple instances of a specific application from launching #445
Comments
I use isolation all the time, and I do understand what you are saying. However, from a settings point of view, it can get very messy. A possible solution: |
Why would it "get complicated" in practice? |
I am not sure, just being cautious really... I can try and implement this more nicely, if it sounds ok? |
Doesn't that also happens from the default dash? In any case, I would go on implementing your suggested fix. |
Sounds good! I'll test a bit to check for consistency, and submit a PR. Any comment on the implementation above 98e2455 ? I'm adding an input to getInterestingWindows, but it doesn't get used all the time. |
Why do we need that? I'm not a fan of boolean function parameters. |
The reason is that some apps would start showing on all workspaces. Say you open Rhythmbox (and it's not favorite), then getAppInterestingWindows will act in such a way that the launcher will show up on all workspaces. This effectively breaks the 'isolation'. In the end, we need to check if the application is single-windowed only for activation, but not when checking for active apps on a given workspace, or for running style. Anyway, at least this is how I see it. Perhaps you expect a different behavior? As for the code itself, that's why I said it was a "proof-of-concept", and not a nice implementation. |
I see. I think we should move that logic out of the |
Just to be clear, the function wasn't returning I will try to make things nicer, and come back with a patch. Thanks! |
Ops, you are right. I got fooled by the github code snipped collapse. |
I tried to come up with a smarter solution, but I didn't improve things that much... Number 2) is essentially having duplicated code, which is a shame really. Thoughts? |
@micheleg just a ping on this issue :) I don't think we reached a solid conclusion anyway. |
I think option 2 is recommended. The reason this wasn't merged is juts this implementation details, right? I need to recheck the code, but I'm ok with having duplicated code. It can be improved later. |
Indeed, this was not merged due to implementation details. Both approaches yield the same result. |
I don't think we need this anymore. Thanks for the new window management logic, it's working great. |
Ok. Good. To clarify, this (as also commits 168e7eb and a69c77c) only solves the issue for those applications marked as "single window" through For those we would need a workaround or some sort of whitelisting. |
Indeed. However, is it easy to create such a whitelist? Myself I can only think of Spotify (since mentioned here), and perhaps Icedove/Thunderbird (when clicking on "New Window" it changes workspace and opens the main window anyway). |
I think it might be obvious for some applications, but very subjective for others. One possible approach would be to have the user specify this (A similar approach as a workaround for a similar problem with windows management was suggested in #300). But things would get easily messy. |
When isolate workspaces is not enabled:
If program A is running on workspace 1, and you are on workspace 2. If you click on A in the dock, it moves to workspace 1.
When isolate workspaces is enabled:
Clicking on A in the dock launches a new instance of A.
For certain applications like Spotify, or other media players this is not preferred. Only 1 instance is preferred. Add the option to add certain applications to a list, such that clicking on them will change to the workspace it is running in, and not launch a new list.
The text was updated successfully, but these errors were encountered: