Search history

[anthony-bernaert]

Add a dropdown to the search field with the recent text searches to quickly return to previously found files.

Maybe also add general back/forward buttons that act on the include/exclude filters. These would modify the filter one step at a time (in the order they were added). Ideally these buttons would be mapped to the physical back/forward side buttons of a mouse.

[DSPaul]

A system similar to Google search that shows your 5 or so most recent searches when you focus the search field that you can go to with arrow keys seems like a good thing to add, I'll add it to the list.

The going forward & backward for adding filters would be part of a more general undo redo system, already tracked in #30.

[anthony-bernaert]

Ok, I also saw issue #30 about the undo system, but that seemed to only refer to "actions" - this is about navigation. But of course you're right that, implementation-wise, it is also just some kind of undo/redo system.

[DSPaul]

I would argue selecting and removing filters are also actions, rather than a form of navigation because you are staying on the same screen, just modifying its state. So I'm not going to make a separate system for this. It will add bloat and confusion. The undo will simply bring you back to the state before your last click/keyboard shortcut/ ect. which includes undoing adding or removing filters.

[anthony-bernaert]

Well, different point of views here 😄. The reason I mentioned navigation is because I'm intensively using this app as an alternative to the default file explorer. I frequently update files, not only the content on disk, but also the tags, description, ... in-app.

The situation I ran into already a few times is: having certain filters applied, changing the filters to temporarily select another file, editing that file's COMPASS metadata, then going back to the first set of filters.

A unified undo system where data model and view state are combined makes it dangerous to use here, as I'm losing the edit to the metadata when I want to go back.

There may be alternatives to this feature request, perhaps some tabbing system or a derivative. In any case, something to switch filter sets even faster without affecting metadata.

[DSPaul]

I think a tab system is indeed the better solution here, as it is a more versatile solution that more people will get use out of.

[DSPaul]

Implemented on Avalonia branch, coming in v2.0.0
See commits 341462a and d494fc0

[anthony-bernaert]

Seems like a good compromise indeed. What about removing some rounding of the buttons to emphasize that they are part of a tab system (like the sidebar)?

[DSPaul]

It's not a bad idea, might help communicate the functionality. However I use firefox as my browser and they just use the same corner radius on all four corners of their tabs so I think both are possible. I'll think about it, might put it to a vote when we get closer to release.