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

Rethink Hotkeys #7

Open
3 tasks
GeorgesStavracas opened this issue Feb 10, 2023 · 4 comments
Open
3 tasks

Rethink Hotkeys #7

GeorgesStavracas opened this issue Feb 10, 2023 · 4 comments
Labels
settings The settings dialog

Comments

@GeorgesStavracas
Copy link
Member

Seems like improving hotkeys is a priority for community members.

We need to:

  • List and rank all the problems the current hotkeys implementation has
  • Decide what's the ideal flow for them
  • Intersect the ideal flow with what's feasible
@gxalpha
Copy link
Member

gxalpha commented Feb 10, 2023

To sum up what I believe to be current consensus:

The major problem with the hotkeys window is that the list, as currently presented, can get very long (especially with lots of scenes and sources). This makes it hard to navigate and the settings window takes ages to load because of it.

The end goal should be a view that doesn't contain every possible hotkey even if it's not used (typically, only a minority of the possible hotkeys will actually get set), but gives the user a flow that lets them add the ones they need, while still keeping it obvious that all those hotkeys exist.

@Fenrirthviti
Copy link
Member

Fenrirthviti commented Feb 15, 2023

Adding an example of the style we are thinking about. This is how Mumble handles hotkeys:
image

@gxalpha
Copy link
Member

gxalpha commented Jun 23, 2023

To add to the list of things needed here, there was the idea floating around of hotkeys with configurable properties (e.g., the "Save Replay Buffer" hotkey having a "Duration" and/or a "Flush after Saving" setting).
It would be useful for a hotkey rework to at least take this into consideration when creating a design, even if it isn’t implemented immediately.

@tytan652
Copy link

tytan652 commented Jan 15, 2024

Adding the GlobalShorcuts portal in the equation, it makes the UI/flow requires to "work" with two design:

  1. Completely managed by the application, the registered hotkey get its shortcut-bind from the app (Windows, macOS and X11), the actual design
  2. Partially managed by the application, the registered hotkey get its shortcut-bind from the desktop environment (Linux with xdg-desktop-portals)
    • (implementation-related but affects the flow) Hotkey's can not (or rather should not) be registered one by one, it should done once or at least per block (e.g frontend and per source/encoder) to reduce the number of permission prompt
    • The user should not end up having to re-register the hotkeys to the desktop environment each time they start the app

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
settings The settings dialog
Projects
Status: Backlog
Development

No branches or pull requests

4 participants