-
-
Notifications
You must be signed in to change notification settings - Fork 26
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
Comments
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. |
@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. |
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. |
@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. |
I must have misunderstood your intention then - sorry. |
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 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. |
@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. |
@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. |
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. 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. |
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) |
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 😅 |
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 |
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 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 😅 |
@leolost2605 I opened #224 so we don't junk up this issue with talk about the workspace switcher :) |
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
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.
The text was updated successfully, but these errors were encountered: