feat(clipboard): add type filters to clipboard history

[dionjoshualobo]

Description

This PR introduces the ability to filter clipboard history by entry type (Text, Long Text, and Image), exposing the existing getEntryType() backend classification to the frontend UI.

Currently, users with large clipboard histories must scroll extensively or rely purely on text search, which is inefficient for finding specific media like images or long text blocks.

Key Changes:

• State Management: Added an activeFilter property to ClipboardService.qml.
• Filtering Logic: Modified updateFilteredModel() to apply the entry type filter before the search text filter and sorting logic.
• UI Integration: Added a DankDropdown to ClipboardHeader.qml with options for "All", "Text", "Long Text", and "Image".
• Localization: All new user-facing strings in the dropdown are wrapped in I18n.tr() with appropriate context, using array indices to ensure safe selection regardless of the active language.
• Data Flow: Connected the state through ClipboardContent and ClipboardHistoryContent to keep the UI perfectly synchronized with the singleton service.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that changes existing behavior)
• Refactor / internal cleanup
• Documentation
• Other

Related issues

Closes #2639

Screenshots / video

DMSFilter.mp4

Checklist

• My code follows the conventions in CONTRIBUTING.md
• I have tested my changes locally
• New user-facing strings are wrapped in I18n.tr() with translator context, reusing existing terms where possible
• Go changes: ran make fmt, added/updated tests, make test passes, and go mod tidy is clean
• QML changes: ran make lint-qml with no new warnings
• I have opened a corresponding pull request in dlx-docs to document any new behaviors: https://github.com/AvengeMedia/DankLinux-Docs

[dionjoshualobo]

A couple of follow-up ideas came up while implementing this, but I left them out to keep the scope of this PR focused:

• Keep or change the selected filter between openings of the clipboard history.
• Let user decide if they want to treat text and long text under the same filter.

The backend already exposes clipboard entry types and the CLI supports filtering, so this PR focuses only on exposing that functionality in the clipboard UI.

Also, this is my first contribution to a large open-source project. I chose this because it is rather simple, self-contained, and something I definitely needed. Any feedback, suggestions, or pointers on how I can improve my contributions would be greatly appreciated.

[jbwfu]

Filtering is indeed needed, but I feel the current location of the filter menu is unreasonable and it might be a more appropriate location for it to appear on the left or right side of the search bar. I also noticed that it is not controlled by blur and animation speed settings.

It would be even better if there was a search integration rather than just button interaction, such as requiring only the keyboard to type certain key characters for specific filtering, which would avoid unnecessary mouse manipulation. However, I didn't use more specific ideas on the specific interaction method of this function on my page. Perhaps it can give you some inspiration.

[dionjoshualobo]

Thank you for the feedback.

About the location of the filter, I did have some confusions on where to place it, and I kept it where it was since there was a lot of empty space there. But what you say makes sense too, since search and filter both aim to narrow the results.

I wasn't aware of the blur and animation speed settings, and I will take a look at it.

Search integration also makes sense. Right now I am thinking of /text, /ltext, /image. I'll experiment with that approach, but I'd be interested to hear if you have another workflow in mind.

[jbwfu]

Typing / (or another symbol) will bring up a partial list of candidates to choose from. This list can be toggled using tab or shift+tab, and selected using enter. You can continue typing while the candidate list is open. If no match is found for a particular type, the entire input in the search box will be treated as a regular string for filtering.

Is this considered a classic type of interaction? I'm not sure if this kind of interaction is appropriate here.

[dionjoshualobo]

These are the ideas I have at the moment.

I think it would make more sense to move the dropdown from its current location to beside the search bar, while also making it fully keyboard accessible.

For filtering directly from the search bar, one idea is to use / to open filter suggestions. If the user selects one of the suggestions using the arrow keys, the corresponding filter is applied. If they do not select a suggestion, the entire input, including the /, is treated as a normal search query.

Once a filter is applied, a small visual chip could appear at the start of the search bar (e.g. im: or text:) to indicate the active filter. The chip could be removed with Backspace when the search field is empty, or with Esc, which would also clear the filter. Esc could also be used to dismiss the suggestion list without applying a filter.

I'll also start looking into the blur/animation settings integration and moving the dropdown closer to the search bar.

Does this direction sound more appropriate?

[hthienloc]

@dionjoshualobo This is how I imagine it.

[jbwfu]

Once a filter is applied, a small visual chip could appear at the start of the search bar (e.g. im: or text:) to indicate the active filter.

Is it possible to integrate this part with the drop-down menu? I'm not sure if it's appropriate to put it together, but it needs to be consistent, at least in terms of state.

The others look fine, unless it's in a very unreasonable location like it was at the beginning. The other UI/UX details are a matter of detail, which mainly depends on user preferences. This will definitely not satisfy everyone. First, give a usable version and slowly optimize and adjust it during use.

[dionjoshualobo]

I also noticed that it is not controlled by blur and animation speed settings.

I went into more detail about this.

The blur / transparency aspect is somewhat difficult for me to validate since I was not able to locate any option in my current configuration which changes the behavior of the dropdown. The other thing which I did confirm is that the global animation speed impacts other animations but not this one.

I will do some further research on how the dropdown popup is implemented now and possibly adapt it to use the global animation speed as well.

[dionjoshualobo]

Once a filter is applied, a small visual chip could appear at the start of the search bar (e.g. im: or text:) to indicate the active filter.

Is it possible to integrate this part with the drop-down menu? I'm not sure if it's appropriate to put it together, but it needs to be consistent, at least in terms of state.

Do you mean this way, #2640 (comment) ? The chip itself is the dropdown? That also makes sense.

[jbwfu]

Do you mean this way, #2640 (comment) ? The chip itself is the dropdown? That also makes sense.

Yes, it is equivalent to the search bar having an area that fixedly displays the search type. It is itself selectable with the mouse and can also be switched by typing /.

[dionjoshualobo]

That makes sense. I like that approach better as well as it avoids having separate UI elements for the same filter state.

I'll try with integrating the filter selector directly into the search bar and use that as the single source of truth for the active filter, while still allowing keyboard-driven switching through /.

[dionjoshualobo]

Edited this according to the feedback regarding keeping the filter status closer to the search flow.

The dropdown now resides next to the search box in order to maintain the same functionality in the dropdown, but at the same time increase visibility while using the search function.

I have looked briefly into having keyboard control navigation between the search and the dropdown, but the current implementation of DankDropdown does not seem to expose the functions required for smooth navigation via keyboard.

I am still considering the possibility of embedding the filter into the search field, but I will begin with this small layout adjustment first.

[Purian23]

Hey @dionjoshualobo, thanks for the idea, I find it very useful! Thanks for the feedback/reviews @jbwfu and @hthienloc. I have gone ahead and updated it with some fixes and polish to the vision I have for it. It now fits together cleaning as in inline filter, alongside a new user facing toggle in Settings>System > Clipboard to optionally remember your last filter set.