Mapping filter control with dedicated Gtk.ListBox filter manager

[ubunatic]

This is a followup on #621. It adds

• a generic list manager for Gtk.ListBoxes to show and hide rows
• a mapping filter control and the related UI elements

See the screens in #621

[jonasBoss]

using a GtkSearchEntry gives us the clear button for free.

[ubunatic]

Using GtkSearchEntry now.

P.S.: Ideally I would want to have sth. like this:

This is the VSCode search and I would love to have this on any list in any UI.

But one step at a time ;)

[ubunatic]

1. ✅ merged your proposal, I was looking for this magic linked style but could find it. Thx!
2. Separate PR is better. This one gets bigger and bigger
3. I would use it to search for generated text ("Alt L") vs. my own custom text ("ALT"). I have a lot of mappings now. And event the search is not enough actually. I would want a searchable tree or some other kind of grouping of things beyond being sorted A-Z. Maybe I would even group them manually. But for now the search is fine. Better than just scrolling. Let's start small.

[sezanzeb]

allright

I found the "linked" class when I used the gtk inspector on quod libet, it has a small dropdown button to the right of its search.

[ubunatic]

I also added support for an explicit GTK_PATH in this PR now. This allows me to start the local development app with:

GTK_PATH=$PWD PYTHONPATH=$PWD bin/input-remapper-gtk -R

so that it will load the latest local files from ./data.

I test my changes this way. First I start the app. Then I press ESC on the pkexec dialog. And then I try my changes in the GUI.

[ubunatic]

Ready to be merged from my side.

P.S. @sezanzeb I have sent you an email ;)

[ubunatic]

Do you have any plans regarding the search looking through the outputs as well already? If not, I'd probably merge this after 2.0.

Not sure this a good idea without more entry controls. The names in the list are defined by the input only; unless renamed manually. We would need more buttons, I guess:

But then the UI seems to get more complicated. The user would need to know that he is searching through text that is not visible in the list; only the first output will be shown on the right. Let's have a discussion about better filters later.

If you want this in a 2.0, I would say we stay minimal with the change:

• remove the pkexec stuff (maybe replaced by development-only env var for now)
• keep the filter on visible input text only

I can do these changes tomorrow, after that I am off for the weekend and will also have less time next week.

[jonasBoss]

If you want this in a 2.0, I would say we stay minimal with the change:

• remove the pkexec stuff (maybe replaced by development-only env var for now)
• keep the filter on visible input text only

I think for now this makes the most sense.

---

Searching through the whole mapping would require us to do the filtering in the data manager. I think that can be done by filtering inside the publish_mapping() method. The controller would set the filter in the data_manager, and then call publish_mapping whenever the filter changes. I don't think we need more buttons for that we could just always search the whole mapping. I can not imagine that someone needs the extra granularity. If we want an advanced search, that should be done inside a dedicated menu. So we keep the main UI simple.

[ubunatic]

If we want an advanced search, that should be done inside a dedicated menu. So we keep the main UI simple.

agreed.

I think I am done with this PR. If there are smaller issues, I can address them next week. But I will not have time for major changes in the next days.

[sezanzeb]

Finding something I'm looking for is easy when I can see it.

The output is not visible unless I click on a mapping.

Finding something that maps to a specific key is impossible unless I click on every mapping to look through every one of them.

I think a search only makes sense when it also filters through the output. And I wouldn't make an extra window for it.

[sezanzeb]

If you want to make an advanced search, then the advanced search would be tweakable to only look for specific things, while the regular search searches everything.