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

Introduce a Launch-or-Focus Application Switcher #1119

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

felix-andreas
Copy link
Member

@felix-andreas felix-andreas commented Apr 30, 2021

Supersedes #585

This PR introduces a new Application Switcher which let's the user bind any application to a Launch-or-Focus shortcut which ...

  • ... launches the application, if it is not running.
  • ... focuses the application, if it is running.

Pressing the Launch-or-Focus shortcut multiple times cycles through the different open windows of the application. In other words: an application-specific AltTab shortcut.

Additionally Ctrl + Launch-or-Focus always opens a new window of the application regardless if there is already another instance running. (similar to the dock, but this is not implemented yet)

Applications can be bound to a shortcut via the system settings keyboard-plug. For demonstration purposes some default applications are bound to the following shortcuts:

Application Shortcut
Text Editor Super E
File Manger Super M
Web Browser Super B
Terminal Super T

Motivation

Most of the current possibilities of switching between different windows rely on some "state" which the user has to keep track of in order to build up muscle memory. Therefore switching windows, when working with many applications at the same time, can add a some cognitive workload to the user:

  • For AltTab the "state" would be the order of windows. It works great when toggling between two different application, but scales bad with increasing number of windows as the user has to keep track of the ordering in the window stack, which makes it hard to build up muscle memory.
  • For the Mutlitasking View / Window Overview the "state" would be the position of windows. As these change depending on which applications are running, it is also not possible to learn/build up muscle memory using a mouse or the SuperDown + Arrow Keys shortcuts.
  • For Workspaces the "state" would be set of windows on the different workspaces. Learn/build up muscle memory for the SuperNumber shortcuts, would require to setup applications so that they are always on the same workspace (see Blockbuster). But his workflow might not be suitable for every user and the numbering also breaks down if one of the applications isn't running.
  • The dock is in that sense "state-less", but has no keyboard shortcuts.

The goal of this PR is to introduce a Launch-or-Focus shortcut which is in that sense "state-less" that always leads to the same outcome: Regardless of whether the application is running or not, on which workspace its window is on and what position it has in the window stack, the Launch-or-Focus shortcut always brings the user to the application.

Due to the shortcut being "state-less", it possible for the user to learn/build up muscle memory for it. Switching between windows is a very fundamental operation when using a computer and I think that something like Launch-or-Focus shortcut could significantly increase the workflow for many people.

Prior Art

⚠️ Disclaimer ⚠️

Remove this plugin when switching back to the main branch:

rm /usr/lib/x86_64-linux-gnu/gala/plugins/libgala-launch-or-focus.so

Otherwise gala crashes when logging in again!

@jeremypw
Copy link
Contributor

Sounds interesting but I am not sufficiently familiar with Gala coding to review this properly.

@JoseExposito
Copy link
Member

JoseExposito commented Jun 14, 2021

What do you think about this @elementary/ux ?

IMHO, this would be great to have, I'd use T a lot :) However, I think that integrating this with switchboard-plug-applications or at least shortcut-overlay is mandatory to make shortcuts easy to discover.

EDIT - It looks like @andreasfelix has already done some work:
elementary/switchboard-plug-keyboard#233

@jeremypw
Copy link
Contributor

It might be easier to split this into two PRs - one dealing with standard apps and one dealing with custom shortcuts. Then we can think about whether there is a way of not limiting the number of custom apps to 10 which seems rather ugly. E.g. is it not possible to use a setting that is a map of desktop ids to shortcuts rather than a separate setting for each custom app.

I'd like to get this merged at least for standard apps.

@jeremypw
Copy link
Contributor

Am I right in thinking that there is a separate shortcut for the launch-or-focus behaviour? This could be confusing. If this behaviour is desirable than maybe it should apply automatically to existing app shortcuts? Or have a toggle to turn it on/off globally?

@felix-andreas
Copy link
Member Author

Am I right in thinking that there is a separate shortcut for the launch-or-focus behaviour? This could be confusing. If this behaviour is desirable than maybe it should apply automatically to existing app shortcuts? Or have a toggle to turn it on/off globally?

My intention was to make this the default behavior when opening apps using a shortcut. (See elementary/switchboard-plug-keyboard#358)

@felix-andreas
Copy link
Member Author

It might be easier to split this into two PRs - one dealing with standard apps and one dealing with custom shortcuts.

OK! The last commit removed the ability to bind non-default applications.

Then we can think about whether there is a way of not limiting the number of custom apps to 10 which seems rather ugly. E.g. is it not possible to use a setting that is a map of desktop ids to shortcuts rather than a separate setting for each custom app.

Yes, I must admit that my solution was not particularly elegant 😄 . Using some kind of map which is not limit to 10 apps is probably possible. I have tried something like this in the commit 99b6eaf of the old PR #585. I can't remember what was the problem, but it didn't quite work out. So I went with the ugly solution, which at least worked...

@jeremypw
Copy link
Contributor

The switchboard plug uses a relocatable schema to store info an arbitrary number of custom shortcuts (limited to 100 I assume for performance or key availability reasons). Files uses a variant setting to store info on an arbitrary number of tabs to restore.

@felix-andreas
Copy link
Member Author

The switchboard plug uses a relocatable schema to store info an arbitrary number of custom shortcuts (limited to 100 I assume for performance or key availability reasons). Files uses a variant setting to store info on an arbitrary number of tabs to restore.

Yes, but as we split up this PR this will be a concern of the next PR. Or?

@jeremypw
Copy link
Contributor

Yes, I think individual settings are acceptable for a fixed list of native apps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants