Skip to content

command : make always bindings a choice per binding - #3112

Open
AKArien wants to merge 1 commit into
WayfireWM:masterfrom
AKArien:revamp_always_bindings
Open

command : make always bindings a choice per binding#3112
AKArien wants to merge 1 commit into
WayfireWM:masterfrom
AKArien:revamp_always_bindings

Conversation

@AKArien

@AKArien AKArien commented Aug 18, 2026

Copy link
Copy Markdown

Remove the always_bindings category. Instead, make all other types of bindings configurable as always.

I don’t quite expect it to be merged as is, as it breaks configuration and might not be the cleanest/best way to do this, but i am looking for feedback/someone to have a better way of handling things.

Remove the always_bindings category. Instead, make all other types of bindings
configurable as `always`.
@soreau

soreau commented Aug 18, 2026

Copy link
Copy Markdown
Member

It is not clear what problem this might solve. Can you elaborate?

@AKArien

AKArien commented Aug 18, 2026

Copy link
Copy Markdown
Author

It is not clear what problem this might solve. Can you elaborate?

Currently, you can only have a binding take place always (when another plugin is running, and when the screen is locked) that behaves like a regular binding. This allows having this « always » behaviour for repeatable and release bindings.

@ammen99

ammen99 commented Aug 21, 2026

Copy link
Copy Markdown
Member

Fwiw I think you could add a new category of bindings, which can have repeatable, always and release as boolean options instead of being separate lists. Then we say everything in the old options is deprecated and remove it after 1-2 releases.

@ammen99

ammen99 commented Aug 21, 2026

Copy link
Copy Markdown
Member

Also fwiw the ini syntax is ugly (not your fault, just how it is), if you have any better ideas of how to encode the information, that would be great. Maybe a command prefix of always$, repeat$, for ex. command = always$terminator. I don't think this is necessarily better, simply saying that I'm open for other suggestions too.

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.

3 participants