This is excellent! UI-wise, if it's clickable, it ought to look like a link all the time, not just when hovered (keep mind that hovering as a concept doesn't exist when using a touchscreen as the primary interaction method). That means also using the standard link color.

Also, I wonder if people might get confused by the fact that some things become clickable/searchable and others don't? What's the technical barrier to doing them all at once?

In D11483#229192, @ngraham wrote:

This is excellent! UI-wise, if it's clickable, it ought to look like a link all the time, not just when hovered (keep mind that hovering as a concept doesn't exist when using a touchscreen as the primary interaction method). That means also using the standard link color.

I followed the way tags are displayed (for consistence). Also I wanted them visually distiguishable from e.g. originUrl which is a link leading outside.

Also, I wonder if people might get confused by the fact that some things become clickable/searchable and others don't? What's the technical barrier to doing them all at once?

1. It's just a short collection of props to see if this patch is useable at all. It's far from exhaustive.
2. For some properties searching makes no sense (e.g. bitrate) so it has to be a curated list.

I followed the way tags are displayed (for consistence). Also I wanted them visually distiguishable from e.g. originUrl which is a link leading outside.

In general, text that changes the view should be made to look like a link. Consistency with solid UI design principles is more important than distinguishing them from originUrl (which is appropriately colored as a link, because it takes you elsewhere, just as this does).

For some properties searching makes no sense (e.g. bitrate) so it has to be a curated list.

Gotcha, that makes sense.

In general, text that changes the view should be made to look like a link. Consistency with solid UI design principles is more important than distinguishing them from originUrl

Agreed. My focus with this patch was the functionality. I think Tags and other clickable Properties (except originUrl) must have a consistent look. Changing the look of Tags (and other clickables) should be part of a separate patch.

Also please consider this:
When the file resides in a folder not indexed by baloo (or if baloo is disabled) only Tags can be clicked all other properties are passive. One can argue about this behaviour. But having them always clickable may lead to the confusing result of an empty search result although the user knows at least one file exists.

I really like the idea, but what if at some point in the future the tags will be made editable/writable? I think this could then interfere from an ui point of view. Can this somehow be implemented to allow both?
I plan to implement tag writing for KFileMetaData at some point to be able to edit tags in Elisa.

A little bit off topic: Are string lists now handled correctly in baloo or not? Searching should then not work properly? Also, in KFileMetaData there is the "shouldbeIndexed" variable for each property, giving a hint if a tag should be indexed or just stored. It is always disabled for numeric values. But apparently searching for the release year works? I'm confused.

In D11483#229497, @astippich wrote:

I really like the idea, but what if at some point in the future the tags will be made editable/writable? I think this could then interfere from an ui point of view. Can this somehow be implemented to allow both?
I plan to implement tag writing for KFileMetaData at some point to be able to edit tags in Elisa.

I don't think it would conflict, because the tag editing UX in Dolphin would need to be done in a separate mode or window anyway; i.e. an Edit information button would either bring up a separate editing window, or change the UI to an "editing" mode where the labels were editable. Either way that's a separate issue that doesn't really concern this patch.

In D11483#229497, @astippich wrote:

I really like the idea, but what if at some point in the future the tags will be made editable/writable? I think this could then interfere from an ui point of view. Can this somehow be implemented to allow both?

In principle that should not be a problem. Just add the 'Change' link like for Tags (happens when a property is not marked as read-only). Question is how to edit...? Another: How can baloo-widgets know if a property is writeable. Ideally kfilemetadata would announce that in PropertyInfo but that's not possible I'm afraid.

A little bit off topic: Are string lists now handled correctly in baloo or not? Searching should then not work properly?

Correct. Searching doesn't work when a string list is provided. (Same thing happens as you've experienced with calling toString() on QVariant::StringList) It's on my list.

Also, in KFileMetaData there is the "shouldbeIndexed" variable for each property, giving a hint if a tag should be indexed or just stored. It is always disabled for numeric values. But apparently searching for the release year works? I'm confused.

Don't be. baloo-widgets is handling releaseYear (and only that) as a string. Otherwise it would be displayed as "2.018".

In D11483#229526, @ngraham wrote:

You're too fast. Write Chinese next time. :-)

@ngraham : Is it possible to make the picture in the description smaller? Not the video itself just the display on this page.
@astippich : Nate is right. We should have discussions surrounding this in the appropiate task.

In D11483#229531, @michaelh wrote:

@ngraham : Is it possible to make the picture in the description smaller? Not the video itself just the display on this page.
@astippich : Nate is right. We should have discussions surrounding this in the appropiate task.

I don't think so. Images support the width tag, but as far as I can see, videos don't.

Well, the tags, comments and ratings are already editable with the links. The others cold be implemented in a similar way.

I still don't understand how the search for the year then works, but nevermind :)

In D11483#229535, @astippich wrote:

Well, the tags, comments and ratings are already editable with the links.

Good point: we're using the wrong UI element there too. In a desktop app, link-style text should always be used to change the current view, not to open a new window. Resolving that issue becomes important if we're going to use links (correctly) for something else. Perhaps a little plus button could work.

To jump into the little offtopic disccusion here. When it comes to edit tags and meta data I would prefer to just click on the label in the info panel and the label switches to an editline, where I can make my changes (or cancel with ESC) which would be saved when the focus changes.
This approach would look much sleeker and would be quite faster too but would then require another aproach for searching ... But back to topic, I really love your idea to make the infos baloo already has stored searchable great feature and improvement to find your files :-D