Bug 488154 - Addition of a dedicated Tags Panel
Summary: Addition of a dedicated Tags Panel
Status: RESOLVED NOT A BUG
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 24.05.0
Platform: NixOS Linux
: NOR wishlist
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-06-07 08:31 UTC by m1vri31c
Modified: 2024-11-19 21:24 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Tag Panel Mockup (50.48 KB, image/png)
2024-06-07 08:31 UTC, m1vri31c
Details

Note You need to log in before you can comment on or make changes to this bug.
Description m1vri31c 2024-06-07 08:31:13 UTC
Created attachment 170220 [details]
Tag Panel Mockup

I initially posted this in the KDE discuss post below, "How to fix tags in Dolphin". This feature suggestion appears last in the post under the heading, "THE ACTUAL SOLUTION: A TAGS PANEL".
https://discuss.kde.org/t/how-to-fix-tags-in-dolphin/16679
In this version I have corrected errors and incorporated my later comment.


The current functionality to add, edit, view, filter by tags is confusing and scattered throughout the UI. What we need is a dedicated Tags Panel. 

I don’t think tags need to be removed from the Info and Places panels, although I wouldn’t be having tags appear in the Places panel by default, aside from All Tags, instead dragged there from the Tags Panel or All Tags.

SEE ATTACHED MOCKUP – the rest of this references that design.

The Tags Panel will only list tags within the current directory and its sub-directories. Using the tickboxes initiates a search in the current directory, without enabling the search panel.
The tickbox on the left is the same as the Add Tags tickboxes from the Search Panel, only showing in the search items with the selected tags. The tickbox on the right (which ideally would be visually differentiated even when un-ticked rather than my solution of confusing “show” and “hide” labels above the columns) allows you to hide items with certain tags from your search. As you check those boxes, the list grows shorter, only showing options that would yield results; that is, only show tags in the folder being searched or its sub-directories, that appear with the tags you have checked “Show”, and that don’t appear with the tags you have checked “Hide”.

Any Tag in this list can be clicked to navigate to its tag fragment (not activating a search in the selected folder like selecting the show or hide tickboxes) or dragged to the Places panel.

With this filter functionality from the Tags Panel, the “Add Tags” dropdown in the search panel is redundant and should be removed, and the user can use a combination of the search panel and the new Tags Panel to filter their search results. This would require the Tags Panel to respond to your search settings like where you are searching (“From Here (location)” VS “Your files”).

N.B. to navigate to a tag fragment from a selected file or folder, you would still need to click on the tag from the Info Panel, but I think this is the correct design, keeping the Tags Panel for filtering, and info panel for showing info attached to a selected item.


You can search for tags from the list using the search box, a basic text filter to find tags in a long list.

The add tag button to the left of the search box turns the whole panel into an add/edit tags menu, similar to the window that appears when clicking “Edit…” (in the Tags section) from the Info Panel – perhaps this should be more of an “edit tags” button than “add tag”, but I used the add tag symbol in my design because it was already there. When this button is clicked, the list of tags to filter by becomes list of all tags, the ones that apply to your selected item already ticked, and the search box becomes an Add Tags box. This mode should also be able to be activated with a keyboard shortcut.
The Add Tags box is similar to the Create New Tags box from that Edit Tags window, but I would amend its functionality to be able to add both new and existing tags. Currently to add tags, you bring up the Edit Tags window, and add one tag at a time by either selecting it from the list or typing the tag exactly and in full. To improve this experience, a case-insensitive autocomplete function should allow you to easily search existing tags by simply typing it in the Add Tags box and pressing enter once the autocomplete has done its job and found your desired existing tag. Once you have pressed enter and added that tag, your cursor will remain in the add tags box for you to immediately type another tag, instead of exiting the window as is the current behaviour, which requires you to click “Edit…” again to add another tag.
Another improvement over the current Edit Tags window would be to sort all currently selected tags for your item to the top of the list.
Comment 1 m1vri31c 2024-06-16 16:30:41 UTC
Something I might add is that in the filter mode, the panel would show any parent tags for tags that exist within the searched directory, but wouldn't show the options to tick to filter by them. Add tags mode would also have parent tags of course.

It would also sort tags by their parent tags. e.g. tag1/tag2 and tag1/tag3 would always appear together, as:
tag1
    tag2
    tag3

Visually, I would suggest connecting lines between them like folders in Dolphin's Details view, rather than just indentation like above.

When searching, parent tags would still be shown even if they don't match the search, as they are useful information about the tag you are searching.
Comment 2 m1vri31c 2024-06-16 16:36:48 UTC
Bug 432720 points out filtering can also be applied when adding tags. If this is implemented alongside my autocomplete suggestion, the filter/search of the tags as you type should not respond to the autocompleted text, but the text you have specifically typed. Perhaps a Tick can be pre-applied to the tag that corresponds to your autocomplete, while the tags that respond to the text you have typed as a filter appear unticked. Unticking the autocompleted one in the list would also remove the autocompleted, selected text in the text entry box. This means any tag that perfectly matches the text in the textbox (whether some of it is autocompleted or not) would be ticked, just like the current edit tags menu.
Comment 3 m1vri31c 2024-06-16 16:59:26 UTC
(In reply to m1vri31c from comment #1)

Do people think when in the filter view of the panel that searching for a tag should also reveal all it's children? I think it is useful in the case of tagging things with author/[theAuthor] or genre/[thegenre] to be able to search for "author" or "genre" and reveal all the tag's children, in this case a list of authors or a list of genres.
Comment 4 m1vri31c 2024-06-25 01:04:02 UTC
I don't know if this is a bug, but I just noticed the current Edit Tags window doesn't sort tags alphabetically. In the tags panel, they should definitely be sorted alphabetically aside from things I mentioned like sorting tags for your selected item to the top, or under their parent tag. 

Perhaps another sort option could be sorting by popularity.
Comment 5 m1vri31c 2024-06-25 01:17:33 UTC
I have reported the lack of sorting in Add/Edit Tags as mentioned in Comment #4 as Bug 489152
Comment 6 m1vri31c 2024-06-28 23:40:03 UTC
It is also worthwhile in the filter view to be able to switch between filtering only at the current directory level or also searching subdirectories.
Comment 7 m1vri31c 2024-07-28 05:04:07 UTC
Also, shift+clicking (or some other way) the show or hide tickboxes of a parent tag should show/hide all of its children. That is, shift+clicking "hide" for the tag "tag1" should also hide "tag1/tag2" and "tag1/tag3".
Comment 8 TraceyC 2024-11-19 21:24:56 UTC
Thanks for sharing this design proposal!

A better place to do this is in the Visual Design Group chatroom, because this isn't really a bug or a discrete feature request (it's more like a bunch of feature requests all mashed together). As such it would make more sense to discuss it in a group setting where existing design choices and constraints that may not be immediately obvious can be explained, and we can go over which elements of this proposal might make sense to integrate.

Check out https://community.kde.org/Get_Involved/Design.

Thanks for understanding!