20
849
Fork
You've already forked fuzzel
83

Discuss: Replace "big icon" feature with automatically expand/collapse feature #665

Open
opened 2025年08月25日 15:55:56 +02:00 by markstos · 5 comments
Collaborator
Copy link

Pre-checks

Do similar tools already implement this feature?

Yes. bemenu adds and removes visible lines as needed.

Walker also works like this.

Describe your feature request

Fuzzel has a feature where it will display a large app icon if there's enough room for a large icon to display and there are few enough app matches.

But since the default matching algorithm switched to be "fuzzy", these icons may be rarely seen because the algorithm frequently matches /something/ as an additional match.

Here we propose an alternate behavior when the displayed results have been filtered to be less the configured number of lines to display. That is: grow or shrink the window size to match the number of results. Some specifics:

  • The window would never grow larger than --lines, only shrink smaller than that and then possibly grow back to this size as the number of filtered results changes.

  • The top edge of the window and prompt / input line would remain in a constant position on the screen, but the selection list area may shrink or grow.

  • As this is somewhat normal/expected menu behavior to maintain size that fits the content, this would not be a configurable option, but would be the new default behavior. As such the "large icon" code path would never trigger and would be removed.

  • The resizing might be "debounced" so it's not redrawing too frequently due to fast typing that causes the number of rows to change rapidly.

(It would be possible to combine the "large icon" and "shrink-and-grow" feature: If there is exactly one match: grow the window enough to display the large icon.

Note that while this is related to the "--minimal-lines" option, it's not the same thing. --minimal-lines controls the initial window size, possibly making it smaller if the input has fewer input lines configured by "lines" to display. --minimal-line is not concerned with otherwise shrinking or growing the window once filtering stars.

### Pre-checks - [x] The [fuzzel.ini](https://codeberg.org/dnkl/fuzzel/src/branch/master/doc/fuzzel.ini.5.scd) and [fuzzel](https://codeberg.org/dnkl/fuzzel/src/branch/master/doc/fuzzel.1.scd) man pages. - [x] [Changelog](https://codeberg.org/dnkl/fuzzel/src/branch/master/CHANGELOG.md#unreleased) of newer and unreleased features ### Do similar tools already implement this feature? Yes. bemenu adds and removes visible lines as needed. Walker also works like this. ### Describe your feature request Fuzzel has a feature where it will display a large app icon if there's enough room for a large icon to display and there are few enough app matches. But since the default matching algorithm switched to be "fuzzy", these icons may be rarely seen because the algorithm frequently matches /something/ as an additional match. Here we propose an alternate behavior when the displayed results have been filtered to be less the configured number of lines to display. That is: grow or shrink the window size to match the number of results. Some specifics: - The window would never grow larger than `--lines`, only shrink smaller than that and then possibly grow back to this size as the number of filtered results changes. - The top edge of the window and prompt / input line would remain in a constant position on the screen, but the selection list area may shrink or grow. - As this is somewhat normal/expected menu behavior to maintain size that fits the content, this would not be a configurable option, but would be the new default behavior. As such the "large icon" code path would never trigger and would be removed. - The resizing might be "debounced" so it's not redrawing too frequently due to fast typing that causes the number of rows to change rapidly. (It would be possible to combine the "large icon" and "shrink-and-grow" feature: If there is exactly one match: grow the window enough to display the large icon. Note that while this is related to the "--minimal-lines" option, it's not the same thing. --minimal-lines controls the initial window size, possibly making it smaller if the input has fewer input lines configured by "lines" to display. --minimal-line is not concerned with otherwise shrinking or growing the window once filtering stars.
Owner
Copy link

I agree this might be a better option. But I'd like more community input. I don't want to have to maintain two different rendering modes, so whatever we pick must be what the majority of our users want.

I agree this might be a better option. But I'd like more community input. I don't want to have to maintain two different rendering modes, so whatever we pick must be what the majority of our users want.

FWIW, I wouldn't miss the large icons.

FWIW, I wouldn't miss the large icons.
Author
Collaborator
Copy link

So whatever we pick must be what the majority of our users want.

I'm not sure how to reach the majority of Fuzzel users. Maybe the best way is via Changelog notes.

Maybe introduce the alternate behavior in one release with a note about how to vote, along with a promise to remove the losing option in the next the release?

We could release a beta with the alternate feature, but I doubt that would reach a majority of users.

> So whatever we pick must be what the majority of our users want. I'm not sure how to reach the majority of Fuzzel users. Maybe the best way is via Changelog notes. Maybe introduce the alternate behavior in one release with a note about how to vote, along with a promise to remove the losing option in the next the release? We could release a beta with the alternate feature, but I doubt that would reach a majority of users.

Just dropping reference previous discussion for others this seems to be a direct issue regarding: #144

I also don't care for large icons and would find it useful if fuzzel can automatically adjust its window to the number of entries shown, leaving more context available for the screen instead of wastefully consuming valuable space. Given it's already a behavior available in similar applications and a request was brought up previously for fuzzel, I'd love to see this implemented.

Just dropping reference previous discussion for others this seems to be a direct issue regarding: https://codeberg.org/dnkl/fuzzel/issues/144 I also don't care for large icons and would find it useful if fuzzel can automatically adjust its window to the number of entries shown, leaving more context available for the screen instead of wastefully consuming valuable space. Given it's already a behavior available in similar applications and a request was brought up previously for fuzzel, I'd love to see this implemented.

It would be more practical if fuzzel could dynamically adjust the row count according to the number of matches.

It would be more practical if fuzzel could dynamically adjust the row count according to the number of matches.
Sign in to join this conversation.
No Branch/Tag specified
master
gnome-support
releases/1.14
issue-319-window-switching
issue-561-nord-theme-only
resvg-filtering-take-2
resvg-filtering
releases/1.13
rehanzo-dont-ignore-execute-648
keybinds-overwrite
issue-561-refresh-theme
ci-automated-testing
reenable-legacy-icons
releases/1.12
test-coverage-for-fzf-caching
releases/1.11
releases/1.10
releases/1.9
releases/1.8
releases/1.7
releases/1.6
releases/1.5
releases/1.4
releases/1.3
releases/1.2
releases/1.1
releases/1.0
1.14.1
1.14.0
1.13.1
1.13.0
1.12.0
1.11.1
1.11.0
1.10.2
1.10.1
1.10.0
1.9.2
1.9.1
1.9.0
1.8.2
1.8.1
1.8.0
1.7.0
1.6.5
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.2
1.4.1
1.4.0
1.3.0
1.2.0
1.1.0
1.0.1
1.0.0
0.9.0
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 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#665
Reference in a new issue
dnkl/fuzzel
No description provided.
Delete branch "%!s()"

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?