With isolate workspaces enabled, prevent multiple instances of a specific application from launching

[Genius1237]

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.

[franglais125]

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.
I'll wait for @micheleg's opinion.

A possible solution:
I tried using something like app.can_open_new_window() to check if a new instance can be launched at all. If it's a single-window app, then we could switch to it.
This sounds nice, but I fear that in practice it could get complicated.
Here is an example using this solution: https://github.com/franglais125/dash-to-dock/tree/single_window_isolation (@Genius1237 do you mind testing this?)
This is just a proof-of-concept, not a properly implemented idea. Again, I'll wait for @micheleg to weigh in before working more on this.

[micheleg]

Why would it "get complicated" in practice?

[franglais125]

I am not sure, just being cautious really...
A simple example of a problem would be applications that use pkexec. For instance, if Synaptic is a favorite app and you try to open it from a different workspace, it will ask for root password, and only then switch to the appropriate workspace. Although not terrible, it could feel inconsistent.
But in any case, I guess it's better than what we have now.

I can try and implement this more nicely, if it sounds ok?

[micheleg]

Doesn't that also happens from the default dash? In any case, I would go on implementing your suggested fix. app.can_open_new_window() is also what's used when the launcher is activated
(https://git.gnome.org/browse/gnome-shell/tree/js/ui/appDisplay.js?id=09e6bb5d5660956049d63ba67b4320374a0b20f4#n1789), so it should be reliable and consistent.

[franglais125]

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.

[micheleg]

Why do we need that? I'm not a fan of boolean function parameters.

[franglais125]

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'.
The same thing can be said for favorite applications, as now the app will be shown as being active on all workspaces (e.g. running dots on the icon).

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.
We could simply create a new function, and use that.

[micheleg]

I see. I think we should move that logic out of the getAppInterestingWindows function. In any case, returning true instead of a list of windows look awkward to me and must be avoided.

[franglais125]

Just to be clear, the function wasn't returning true, that was only the filtering :)

I will try to make things nicer, and come back with a patch. Thanks!

[micheleg]

Ops, you are right. I got fooled by the github code snipped collapse.

[franglais125]

I tried to come up with a smarter solution, but I didn't improve things that much...
Here are the two approaches (with the same result of course):

1. Keep the boolean parameter 60d227a
2. Add a function similar to getInterestingWindows f22a444

Number 2) is essentially having duplicated code, which is a shame really. Thoughts?

[franglais125]

@micheleg just a ping on this issue :)

I don't think we reached a solid conclusion anyway.

[micheleg]

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.

[franglais125]

Indeed, this was not merged due to implementation details. Both approaches yield the same result.

[micheleg]

Do we still need this after 168e7eb and a69c77c ?

[franglais125]

I don't think we need this anymore. Thanks for the new window management logic, it's working great.

[micheleg]

Ok. Good. To clarify, this (as also commits 168e7eb and a69c77c) only solves the issue for those applications marked as "single window" through can_open_new_window(). These do not include things like Spotify (and other Chrome/Electrum application which are most likely all meant to be single window)

For those we would need a workaround or some sort of whitelisting.

[franglais125]

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).

[micheleg]

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.