Skip to content
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

Isolate workspaces #134

Open
kdwk opened this issue Nov 20, 2021 · 14 comments
Open

Isolate workspaces #134

kdwk opened this issue Nov 20, 2021 · 14 comments
Labels
Priority: Wishlist A feature request or enhancement

Comments

@kdwk
Copy link

kdwk commented Nov 20, 2021

Problem

Currently, dock shows apps opened on all workspaces. However, this does not fit in to the concept of '1 workspace 1 task'.

From the 'studying workspace', a user can still directly access the browser window in the entertainment workspace by clicking on the browser icon in dock. This is not desirable as it cannot maintain the principle that 'what happens in this workspace stays in this workspace' and significantly weakens workspace separation.

This also causes a lot of confusion to the user as to what workspaces are supposed to be and hurts the 'switching workspaces as alternative to minimizing apps' argument (if workspaces are not isolated, that means tasks can be and should be mixed between workspaces, i.e. the user can have entertainment and productivity in a single workspace, and that means the argument for minimizing apps is valid).

Proposal

  1. Only show apps opened in that workspace in dock. Hide apps from all other workspaces. If the user tries to open an app that is not in that workspace and can only have one instance of, switch to the workspace where the opened window is in (and bring that window to focus).
  2. In the spirit of 'what happens in a workspace stays in that workspace', apps should open in whichever workspace its icon was clicked on. That is, if users open an app in workspace 2 and switches to workspace 1 before the app window is opened, the app window should open in workspace 2.
  3. Inform new users of this workflow in the onboarding experience, as this is likely to be drastically different from what they are used to.

Prior Art (Optional)

The Dash to Dock Gnome shell extension has an identical option where only apps from that particular workspace is shown in the dock.

@jeremypw
Copy link

I for one would like to able to access all the pinned and running apps from each workspace but maybe the apps in the current workspace could be shown as a separate group? The drawback of that would be that the position of a given app would not be consistent so I am +- on this.

@kdwk
Copy link
Author

kdwk commented Nov 21, 2021

@jeremypw The main reason to isolate workspaces in the dock is to open a new instance of an app by default if the app is not open on a workspace but open on another. This works especially well for things like a browser. If you have a window open in the entertainment workspace and you are in the productivity workspace you can open a new browser window without having to remember that you have opened another window in another workspace and choosing 'open new window' in the right-click menu.

If we can do this without taking away the indicators, i.e. you can still see the 'open' indicator below an app opened in another workspace, but if you click on it a new instance is opened, then I think it'll work. This can also be an option in Settings for users to toggle.

@jeremypw
Copy link

The main reason to isolate workspaces in the dock is to open a new instance of an app by default if the app is not open on a workspace but open on another.

If a user (like me) is in the habit of opening apps by clicking on the dock rather than through the Applications menu, then this implies that pinned apps that are not open on the current workspace should still be shown in the dock.

@kdwk
Copy link
Author

kdwk commented Nov 21, 2021

@jeremypw I'm not sure what you mean. I did not propose pinned apps to be removed from the dock if it is not opened in the current workspace. Rather, I propose that when (app in dock is clicked on),

IF 1. (app is open in other workspace), 2. (app is not open in current workspace), and 3. (app allows multiple instances)

THEN 1. (open new instance of app in this workspace), 2. (leave instance in other workspace untouched)

ELSE IF (app does not allow multiple instances)

THEN 1. (switch to workspace that app is opened in), 2. (focus on app, bring to foreground in necessary)

This should clarify my proposal a bit. Hope this helps.

@jeremypw
Copy link

Only show apps opened in that workspace in dock

I must have misunderstood your intention then - sorry.

@Blast-City
Copy link

Blast-City commented Nov 21, 2021

Hi.

This is issue is similar to #98 and #101. It would be nice for a moderator to consolidate all the issues since this is such an important workflow problem.

I don't think the issue is that elementary doesn't isolate workspaces, but how opening a new instance of an app requires an extra right click and there is not an automatic placement of windows to know if apps are already open. It would be nice if there to write a guideline that if apps could run multiple instances, that option must be included in the first position of the desktop file. This way it would be easy to implement a middle click to open a new instance that would always work. If there was not a new instance option in the desktop file, an error sound would be played.

I also proposed on an another issue that there should be three type of indicators on the dock:

User chosen accent color dot - App open in currently selected workspace
Monochrome dot - App open in another workspace
Icon flashes - App requires attention (the current red dot).

This and automatic placement of windows (elementary/gala#439) would make it easy to know when you should use the middle click while maintaining the option to switch to apps on other workspaces by using the left click.

@kdwk
Copy link
Author

kdwk commented Nov 21, 2021

@Blast-City @jeremypw after reading the proposal in #101 I believe visually different indicators would be ideal. However, I still think (clicking on an app in the dock) (on a workspace with no instance of that app open ) (should open a new instance by default). A middle click to always open a new instance may not be that discoverable, and an error when a new instance is forbidden may be confusing, disorienting and add burden to the user for dismissing the error and trying again.

Instead, I think switching to an instance on another workspace should be achieved by right click and choosing the instance in the menu. These other instances are on other workspaces, which means they are not visible and hidden to the user at the moment, so having to go the extra step of right clicking seems logical and reasonable.

@Blast-City
Copy link

Blast-City commented Nov 21, 2021

@kdwk, I think that the indicators will only help if the dock click options keep working like they're working now. If #85 is implemented, it would be really difficult to not agree with your opinion, thought.

Either way, right now, unless the option is present on the desktop file, opening a new instance is just a "feeling lucky" action. More on this on #77 and #82.

@leolost2605
Copy link
Member

I kind of like both ways and I think this might even be worth an configuration option in settings like "Show Apps from all Workspaces" (or "Isolate Workspace" which would be the reversed).

If toggled we show apps from all workspaces with apps from a different workspace having a different "open" indicator. Clicking a Launcher will switch to the workspace with the app window and if multiple windows are open show windows from all workspaces in the spread.

If off we only show apps from the current workspace. Pinned apps that are open on a different workspace will still have the different open indicator.
If an app has a window on a different workspace and a window on this workspace clicking it will activate the window on this workspace. If it has two windows on this workspace clicking it will show a spread with only the windows on this workspace. If it doesn't have a window on this workspace clicking it will always try to open a new window on this workspace or if it fails switch to the open window on another workspace.

I'm open to suggestions and improvements but I think something similar to an isolate workspace behavior would be quite useful :)

@danirabbit @elementary/ux opinions on this?

AFAICT from an implementation standpoint this should be doable without too much effort.

@leolost2605
Copy link
Member

Another thing to consider is how this would interact with https://github.com/orgs/elementary/discussions/337 (which I haven't given too much priority now that we have a clutter canvas replacement in Gala)

@danirabbit
Copy link
Member

danirabbit commented Apr 2, 2024

Yeah I think it might be worth revisiting launch vs focus behavior alongside the idea of having the workspace switcher in the dock. I'd really like to avoid options since options end up creating branching/untested code paths and bugs etc. But if there was a clear separate workspace manager in the dock perhaps pinned launchers could be always activate and the workspace switcher would be always focus (ofc).

The big problem is most apps are single window so how do we avoid behaviors that feel nondeterministic? That's kind of the reasoning we have been working with where if the app is not running we launch it and if it is running we focus it, because that works for every app. Currently the dock behavior is always about putting the app window you want in front of you. If it has no windows, it makes a window. If it has one window, it takes you to the window. If it has multiple windows, it prompts you with which window you want. The desire/outcome path is always "Take me to the app I just clicked"

If some apps launch new instances and some apps focus, and the dock has no idea which one will happen, this seems problematic. If we say pinned launchers only launch and don't handle focusing, then what happens if you click a single-window app (again most of the apps) on a different workspace?

So that's kind of my major concerns here is that we don't have two modes: deterministic and lottery 😅

@danirabbit
Copy link
Member

Okay so it turns out there is a part of the desktop spec to hint to the shell that your app supports multiple windows. See #77 (comment)

That would at least give us a deterministic way to try to create a new window for an app that wouldn't accidentally trigger a focus/workspace switch

@leolost2605
Copy link
Member

Hmm okay how about we have pinned apps on the left which keep the current behavior with window spread for all workspaces, activate on any workspace and launch and we can revisit this later once we do some investigation into SingleMainWindow and its adoption etc.
And on the right we have the workspaces like in the mockup but for workspaces with multiple apps it expands on hover and shows it apps with launcher size where clicking will activate on single window and show a spread for this specific workspace on multiple windows. So that you have a workspace/multitasking area with some finer grained focus control.

I'm just doing some brainstorming here because I've got some time the next few days and would like to work on this but don't want to do some stuff that will probably have to be redone anyways 😅

@danirabbit
Copy link
Member

@leolost2605 I opened #224 so we don't junk up this issue with talk about the workspace switcher :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: Wishlist A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

5 participants