WSearchRelatedTracksMenu: Elide action text

[uklotzde]

TODO:

• Rebase after Remove deprecated QDesktopWidget #3215 has been merged

Turned out to be trickier than expected.

• Separate query field and value by a right arrow an unquote the value
• Elide query values in the middle

[ronso0]

works with Qt 5.12.8

it seems to elide in the middle (at least the folder).
I'm not 100% sure how to format that string appropriately, but I think we should prioritize trying to show the entire folder name and elide the path before that. That will probably be redundant with the album name, but I don't see the necessity showig the path: the "Search related.." menu is for triggering searches, not for supplying track info. Users should Properties or Show in File Manager" for that.

[uklotzde]

works with Qt 5.12.8

it seems to elide in the middle (at least the folder).
I'm not 100% sure how to format that string appropriately, but I think we should prioritize trying to show the entire folder name and elide the path before that. That will probably be redundant with the album name, but I don't see the necessity showig the path: the "Search related.." menu is for triggering searches, not for supplying track info. Users should Properties or Show in File Manager" for that.

Qt::ElideMiddle has been chosen deliberately, a comment in the code explains why. The text is already split into a non-elided prefix and an elided suffix. Anything else would require a more sophisticated strategy.

But is it worth to complicate the code further? I don't think so. The value should only give a glimpse which query will be executed. No data will be modified. The full text becomes visible in the edit box when triggering the search.

[ronso0]

I just found that path/to/folder also finds path/to/folder copy.

[uklotzde]

I just found that path/to/folder also finds path/to/folder copy.

I guess currently we are searching just for the prefix, case-insensitive. This is desired to find files in all subfolders. Maybe we need two different folder searches? Or delimit the folder string with a terminating '/'. I will do that as a first step.

[uklotzde]

I just found that path/to/folder also finds path/to/folder copy.

I guess currently we are searching just for the prefix, case-insensitive. This is desired to find files in all subfolders. Maybe we need two different folder searches? Or delimit the folder string with a terminating '/'. I will do that as a first step.

Done. But we cannot exclude subfolders.

[poelzi]

Im a huge fan how the fish shell compresses the folderpath.
It uses only the first letter of each folder. Folders under home start at home with ~/

This is usually enough to know there you are but dont spam the ui with characters.

[uklotzde]

This PR is not the place for discussing custom elision algorithms.

[uklotzde]

I have already left a TODO comment in the code:

// TODO: Customize the suffix elision?

[ronso0]

Unfortunately this looks quite bold here:

I tried the hollow triangle, how does that look for you:

[uklotzde]

I tried the hollow triangle, how does that look for you:

Unfortunately, the hollow triangle looks like an ordinary character that doesn't distinguish the different parts field vs. value of the text very well.

[ronso0]

I go along with your screenshot at the top, but it looks different here. I wonder why it looks different eventhough we ship the fonts. maybe it's not included in Ubuntu or Open Sans

[uklotzde]

@Ronso How can we check that the bundled OpenSans font is actually loaded and used? The log file does not contain any messages.

[uklotzde]

Custom fonts are loaded as expected. But there is a system-wide Open Sans font in Fedora that might be picked instead.

[ronso0]

Naa, it's just that the triangle is not included in Ubuntu or OpenSans, both have a very limited set of glyphs and neither contains the Geometric Shapes range 25A0—25FF.
https://fonts.google.com/specimen/Open+Sans#glyphs
https://fonts.google.com/specimen/Ubuntu#glyphs
I guess the OS goes through the fallback fonts and tries to find one that contains the requested glyph.

So we have to live with that for now.

[ronso0]

Does it still look like the screenshot at the top for you?
I tested with Tango & LateNight (and OS font Open Sans) and it looks very dense and I think this might happen to others, too:

With an extra space before the triangle it's much more relaxed:

[Holzhaus]

I think the triangle looks weird. Why not just a colon (: ) or a dash (-)?

[ronso0]

We had the colon earlier, it just doesn't separate the prefix and search string enough, thus the triangle.
Dash is also not adequate IMO. It looks more like Artist - Title or a range.
And there's currently no easy way to for example highlight the search term with font styles like 'bold'.
That said: the triangle is an imprvement, unless yo can come up with a better unicode char.

[Be-ing]

I think a colon is fine. The triangle is okay, but it's a bit odd because it is similar to the submenu icon. I don't care much either way.

I agree that a dash would not be a good choice.

[uklotzde]

To stick with ASCII characters I have replaced the right triangle with the pipe symbol. This is more unlikely to appear in any metadata property than a dash symbol.

[Be-ing]

Please post a screenshot when significant GUI changes are made to a PR.

[uklotzde]

Final version. I will not try any other variants.

[ronso0]

Thanks, looks good!

[ronso0]

tbh I'm not happy with the pipe symbol, but we can tweak this later on.