20
849
Fork
You've already forked fuzzel
83

Add keyboard-focus=exclusive|on-demand command line and config option #492

Manually merged
dnkl merged 0 commits from bbb651/fuzzel:ondemand-interactivity into master 2025年03月07日 10:57:41 +01:00
Contributor
Copy link

Some asked in the niri matrix room if this was possible and it seemed quite straight forward and useful. Not entirely sure about the name and documentation, I tried to avoid bikeshedding.

Some [asked](https://matrix.to/#/!KIjqiaZyJFkPXxMmGQ:gnome.org/$IuB1rQ0TWPIQ_28OFqScpklRv0vpgvTE-nDlk0mFJak?via=gnome.org&via=matrix.org&via=tchncs.de) in the niri matrix room if this was possible and it seemed quite straight forward and useful. Not entirely sure about the name and documentation, I tried to avoid bikeshedding.
doc/fuzzel.1.scd Outdated
@ -312,2 +312,4 @@
Default: _top_
*--keyboard-interactivity-on-demand*
Request on demand keyboard focus rather than exclusive.
Contributor
Copy link

It took me a while to parse this sentence when reading it for the first time. I think using "on-demand" would make it clearer.

It took me a while to parse this sentence when reading it for the first time. I think using "on-demand" would make it clearer.
doc/fuzzel.1.scd Outdated
@ -313,1 +313,4 @@
*--keyboard-interactivity-on-demand*
Request on demand keyboard focus rather than exclusive.
This switching keyboard focus to close fuzzel.
Contributor
Copy link

It seems like "switching" should be "switches" here, but I'm still not sure what's being expressed.

It seems like "switch**ing**" should be "switch**es**" here, but I'm still not sure what's being expressed.
Contributor
Copy link

Oh, I guess the idea was something more like: "This makes fuzzel exit when keyboard focus is lost"?

Oh, I guess the idea was something more like: "This makes fuzzel exit when keyboard focus is lost"?
dnkl left a comment
Copy link

I think it would be very useful to support the extended protocol, and there's nothing wrong with that part of the implementation.

However, like @craigbarnes, I find the documentation (of fuzzel's options) hard to understand. That needs to be improved.

It might also make more sense to add an enum-like command line/config option, rather than a boolean: keyboard-focus=exclusive|on-demand perhaps? Defaulting to exclusive.

I think it would be very useful to support the extended protocol, and there's nothing wrong with that part of the implementation. However, like @craigbarnes, I find the documentation (of fuzzel's options) hard to understand. That needs to be improved. It might also make more sense to add an enum-like command line/config option, rather than a boolean: `keyboard-focus=exclusive|on-demand` perhaps? Defaulting to `exclusive`.
Author
Contributor
Copy link

I find the documentation (of fuzzel's options) hard to understand. That needs to be improved.

I'll try, I'm not used to writing man pages. In general I don't like the duplication between fuzzel(1), fuzzel.ini(5) and --help, I know they serve different purposes but especially with flags that just set config options like this one it feels a bit redundant

It might also make more sense to add an enum-like command line/config option, rather than a boolean: keyboard-focus=exclusive|on-demand perhaps? Defaulting to exclusive.

I agree, even if it's unlikely there'll be additional variants it's just as short and more intuitive to override. Probably also focus over interactivity, I wanted to match the protocol but it could just be mentioned in the man page.

Edit: Unrelated to this PR, I noticed layer defaults to overlay but --help says it defaults to top. This is what I'm talking about, when there's no single source of truth, documentation, completions, etc. eventually go out of date

> I find the documentation (of fuzzel's options) hard to understand. That needs to be improved. I'll try, I'm not used to writing man pages. In general I don't like the duplication between `fuzzel(1)`, `fuzzel.ini(5)` and `--help`, I know they serve different purposes but especially with flags that just set config options like this one it feels a bit redundant > It might also make more sense to add an enum-like command line/config option, rather than a boolean: `keyboard-focus=exclusive|on-demand` perhaps? Defaulting to `exclusive`. I agree, even if it's unlikely there'll be additional variants it's just as short and more intuitive to override. Probably also `focus` over `interactivity`, I wanted to match the protocol but it could just be mentioned in the man page. Edit: Unrelated to this PR, I noticed `layer` defaults to `overlay` but `--help` says it defaults to top. This is what I'm talking about, when there's no single source of truth, documentation, completions, etc. eventually go out of date
bbb651 force-pushed ondemand-interactivity from da29db1b36
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/freebsd-x64 Job failed
to 72acd91c28
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/freebsd-x64 Job failed
2025年03月05日 21:16:25 +01:00
Compare
bbb651 changed title from (削除) Add keyboard-interactivity-on-demand command line and config option (削除ここまで) to Add keyboard-focus=exclusive|on-demand command line and config option 2025年03月05日 22:26:37 +01:00
bbb651 force-pushed ondemand-interactivity from 72acd91c28
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/freebsd-x64 Job failed
to bdaac3041f
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/freebsd-x64 Job failed
2025年03月07日 10:51:31 +01:00
Compare
bbb651 force-pushed ondemand-interactivity from bdaac3041f
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/freebsd-x64 Job failed
to aa8553b12b
Some checks reported errors
ci/woodpecker/push/woodpecker Pipeline was successful
ci/woodpecker/pull_request_closed/woodpecker Pipeline is pending approval
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/freebsd-x64 Job failed
2025年03月07日 10:57:40 +01:00
Compare
dnkl manually merged commit aa8553b12b into master 2025年03月07日 10:57:40 +01:00
Author
Contributor
Copy link

I accidentally force pushed the branch to master while trying to resolve the submodule being removed (some weird interaction with jj and force pushing), and that made codeberg think it's been manually merged... is it possible to reopen the PR? The commit should be good now: bbb651/fuzzel@466abbe0f7

I accidentally force pushed the branch to master while trying to resolve the submodule being removed (some weird interaction with jj and force pushing), and that made codeberg think it's been manually merged... is it possible to reopen the PR? The commit should be good now: https://codeberg.org/bbb651/fuzzel/commit/466abbe0f756f2e88c45be18284f3afc8900bb3b
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
dnkl/fuzzel!492
Reference in a new issue
dnkl/fuzzel
No description provided.
Delete branch "bbb651/fuzzel:ondemand-interactivity"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?