[bug]: Filtering by non-existent color breaks search #22

bragefuglseth commented 2026年07月04日 18:22:35 +02:00

When searching for a color that no current counter has, the search view gets locked to the "No Matches" state.

Steps to reproduce

1. Ensure that at least one color is absent from the list of counters
2. Perform a search for that color

Current behavior

The "No Matches" screen appears, and refuses to go away even when the search is changed or closed altogether

Expected behavior

The "No Matches" screen appears, but goes away when the search becomes valid or is closed

When searching for a color that no current counter has, the search view gets locked to the "No Matches" state. ## Steps to reproduce 1. Ensure that at least one color is absent from the list of counters 2. Perform a search for that color ## Current behavior The "No Matches" screen appears, and refuses to go away even when the search is changed or closed altogether ## Expected behavior The "No Matches" screen appears, but goes away when the search becomes valid or is closed

vtrlx commented 2026年07月06日 18:32:56 +02:00

I redid the logic governing the "No Matches" page so that it uses Gtk.ListBox's :set_placeholder() method. I also make sure to tweak the CSS when the aforementioned status page appears so that it looks like an ordinary status page instead of as a child element to the list.

I also rigorously tested the search in every way I could imagine. I believe it is now bug-free along with meeting the criteria for Circle inclusion.

I redid the logic governing the "No Matches" page so that it uses Gtk.ListBox's :set_placeholder() method. I also make sure to tweak the CSS when the aforementioned status page appears so that it looks like an ordinary status page instead of as a child element to the list. I also rigorously tested the search in every way I could imagine. I believe it is now bug-free along with meeting the criteria for Circle inclusion.