Currently, the Find application determines which attributes are available for queries based on the MIME type of the files being searched. While this works well for typical use cases, it creates a limitation for advanced workflows, particularly when working with symbolic links that have specialized attributes.
Use Case:
When adding audio attributes (e.g., Audio:Artist, Audio:Album, Audio:Track) to symbolic links pointing to audio files on non-BFS filesystems, these attributes are stored successfully on the symlinks themselves. However, the Find tool only offers generic symlink attributes for querying, not audio attributes, because symlinks have the MIME type application/x-vnd.Be-symlink.
This prevents users from querying symlinks by their audio metadata using the convenient âby attributeâ interface
Proposed Solution:
Add a MIME type selector to the Find interface that allows users to choose which set of attributes to query, independently of the file type being searched.
UI Mockup Suggestion:
In the âby attributeâ view (see attached screenshot), add a dropdown menu or BMenuField above the attribute list:
Options could include:
âAuto (match searched type)â - current default behavior
List of all MIME types (each having a specific list of attributes)
Benefits:
Improved usability: Makes the intuitive âby attributeâ interface available for cross-MIME-type queries
Flexible: Supports custom attribute workflows and edge cases
Not sure we need another dropdown menu in the âby attributeâ view. Or I donât quite understand how you imagine it.
See last paragraph of [GSoC 2024] Improving the Tracker Query Window - #17 by humdinger . The added âOtherâ menu item at the bottom of the attributes list would contain all attributes in the system. All indexed attributes that is, because only these can be searched by query. While limiting, it should simplify listing all possible attributes.
It all depends on how complex you want to make the simple case.
I donât have Haiku here and now, but I think you can get that search by building the query for audio files and, before executing, changing to formula mode and removing the BEOS:TYPE predicate.
In fact, you can query any attribute, as long as the query contains at least one indexed attribute.
I was talking on how to use and improve only the attributes mode, because this mode makes the hypothesis that the attribute you search is linked to the mime type of the file - which is not true in this case
I would like to focus only on this mode because if we can find a « simple » way to answer the question in the gui, it could be used more often and more easily by users.
Yes, I get it. I canât even say Iâm against it. Eh, Iâm not an UI guy, so even if I had a hard opinion, it wouldnât really matter. What I mean is that you can always find a use case for which the UI is almost there and be tempted to improve it. And then one day after a few of such small changes you notice new users are not using the Find window because itâs too complicated. So you have to be careful when you want to expand the possible uses.
You can also say you canât search on attributes that are not assigned to any mime type. I may, for example, give a deletion date to my files via an attribute and want to know which files are to be deleted next week. Even with your solution I wouldnât still be able to do it in that window.
Your use of links as a kind of dopplegĂ€nger looks to me as a contraption, something much more obscure than my example. But then we donât have a transparent fallback for filesystems that donât support our attributes, so itâs at least a good workaround for your case, most of the times.
That could make the âattributes modeâ GUI more versatile, but thatâs my opinion
Organizing attributes by mime type would mimic the previous behavior, but Iâm not sure if it would not make the GUI more complex to understand by a user.
What I would do is list other filetypes in the same menu as attributes. At the top of the menu you have a list of attributes that are associated with the filetypes you are querying (inyour example, only symlink attributes).
Below that, you get a separator and then a list of mime type submenus, where you can dive in for more attributes if needed. Maybe even in a âMoreâŠâ submenu. I think your use case with symlinks is specific enough that it is better implemented this way, not disrupting the basic use case too much. Having to select the mime type twice in the normal flow seems too confusing.
OTOH, this would be very hard to convey in a GUI. Add a âYou need to query on at least one indexed attributeâ? The user wonders, âWhatâs an âindexed attributeâ?ââŠ
Also, how would you build the list of âotherâ attributes, i.e. those that are not linked to a MIME type in the FileTypes prefs? As it could be any custom attribute added to any file, youâd have to works through every file in the system.
Limiting to indexed attributes - while not perfect for every use case - gives the user at least the power to use those attributes on arbitrary files. For example, you could add a MEDIA:Rating to your PDF files or search for META:url on ZIP archives you downloaded with Web+ (which adds this attribute to all downloaded files).
If I understand it right, this feels a bit convolutedâŠ
Why not query for âsymbolic linkâ âby attributeâ and choose the attributes you want from the new âOtherâ menu that will be present for every MIME-Type and lists all indexed attributes (among those Audio:Artist and Media:Title)?
At the end of the pop-up menu (after âmodifiedâ) a new âotherâ entry will propose the mime-type hierarchy like this before having the attributes ?
However If I have an attribute relative to âaudioâ and another one relative to âaudio/AC3 audio fileâ, itâs a bit complex to browse the possible attribute list.
Or maybe make a distinction between âmime-type groupâ (like audio) to propose first with attributes, versus âmime-type leafâ (like âaudio/AC3 audio fileâ) to propose after the groups ?
Another approach is to display all mime-type without hierarchy but I fear there will be too much linesâŠ
Or do you mean to list all the indexed attributes directly without hierarchy?
While attributes can be created in the FileTypes preferences under specific MIME types (like Audio:Artist for the âaudio/*â supertype), you can add any attribute to any file and query for it
To make the new âOtherâŠâ menu better navigable, Iâd suggest to sort those attributes into submenus according to their âsupernameâ. Doing a âlsindexâ shows Audio:, BEOS:, MAIL:, META:, Media:, plus a few special cases like _trk/qrylastchange and _trk/recentQuery.
