Bug 404625 - When text labels have a maximum line count, items with elided text should display full text when hovered or selected
Summary: When text labels have a maximum line count, items with elided text should dis...
Status: CONFIRMED
Alias: None
Product: dolphin
Classification: Applications
Component: view-engine: icons mode (show other bugs)
Version: 18.12.2
Platform: Neon Linux
: HI normal (vote)
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2019-02-20 22:28 UTC by Ashram
Modified: 2020-05-06 08:23 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Multiple files selected for dolphin without elided filenames (169.53 KB, image/png)
2020-05-02 02:06 UTC, Christian Christiansen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ashram 2019-02-20 22:28:58 UTC
SUMMARY

Files & folders with long names creates abnormal spacing between elements which makes it hard to search to the naked eye due to high inconsistency .

I'm aware you can limit the number of lines used for names on Dolphin's option... which fix the weird spacing but on a real-life scenario working with multimedia files that needs A LOT of informative tags that you need to check while working with those files & folders... the readability is totally ruined and makes it really hard to spot the full name ( you can check the status bar if the folder/file is highlited... but let's agree this is far from ideal ) .

This seems to be an old but i'm surprised nobody else mentioned before... from what i've seen this doesn't happen on other Linux DE's ( on other DE's you can see the full long name when the file/folder is highlighted/ selected )

STEPS TO REPRODUCE
1. On Icons-view creat one folder
2. Inside that folder create 3 + 3 rows of files & folders with random names using 2-3-4-5-6 lines

OBSERVED RESULT

You should be looking at the weirdest spacing between elements, with the max space between elements being determined by the file/folder with the longest name... and a lot of empty space below files/folders with short names .


EXPECTED RESULT

Files & folders should keep equal distance between elements despite the file/folder name's length. It's been like that on other DE's & OSs for years, you can check any other popular DE for reference .


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: KDE Neon user edition ( 18.04 based ) up to date
KDE Plasma Version: 5.15.1
KDE Frameworks Version: 5.55.0
Qt Version: 5.12.0
Comment 1 Nate Graham 2019-02-22 22:28:12 UTC
If we increase the spacing for all items to be equal to the spacing needed for the item with the longest label, then people will complain that there's a huge amount of wasted space.I don't think we can do that.

What makes some sense to me is that when you have the maximum line number for labels capped, Dolphin will show a tooltip with the full name when hovered over.

Does that make sense to you? FWIW You can kind of get this behavior right now by setting the maximum label line number and turning on tooltips.
Comment 2 Ashram 2019-02-23 12:34:13 UTC
(In reply to Nate Graham from comment #1)
> If we increase the spacing for all items to be equal to the spacing needed
> for the item with the longest label, then people will complain that there's
> a huge amount of wasted space.I don't think we can do that.
> 

Maybe i didn't explain myself properly, really sorry.

The main issue with the current behaviour is - precisely - that one single file or folder with a long label ( and the "unlimited lines" option marked to show the full name )  will "break" the visual alignment, creating plenty wasted space .

Not suggesting we should always see the full name regardless of their length ( besides, that's something we can do already by allowing unlimited lines ) .

> What makes some sense to me is that when you have the maximum line number
> for labels capped, Dolphin will show a tooltip with the full name when
> hovered over.
> 

I've tried with tooltips right now ( admittedly, never used this option before myself ) ... but feels way too invasive, eats up too much visual space. 

Not implying tooltips are unnecessary in any way, i'm sure it has its own use case, but it's not what i'm after.

I'd say most popular linux DEs & other OSes have this tiny visual issue figured out since ages... only i've been unable to explain myself properly.


> Does that make sense to you? FWIW You can kind of get this behavior right
> now by setting the maximum label line number and turning on tooltips.

Full disclosure: i install linux to as much people as possible & also offer support ( don't charge a penny, i see it as my way to contribute... and while i try to present all avaliable options, can't deny i favor KDE/Plasma and have installed KDE Neon to dozens & dozens of people ) .

This also helps me collect some feedback about potential problems people find on different use cases... although there's some many bugs squashed so fast that most of the times those are gone before i even mention anything :) .

However, one person made me aware of this issue a good while ago and his use case is that of a person that works with many multimedia files and need to move 'em fast ( using GUI, not a terminal ) ... and he showed me how he works to make me understand this current behaviour makes everything slower... compared to his previous DE ( Gnome ) .

He needs to be able to check the full name ( and this is the important bit ) when the file or folder is selected ... same way most DEs on Linux or other OSes do.

Pictures are worth a thousand words so check this :

https://imgur.com/a/DQEcR6u

These are two screencaps of a folder with 3 lines of folders on Gnome. Can you see how the third folder ( starting from top-left to right ) looks when it's selected/unselected ?

Essentially that's what i'm asking about. On Plasma you can't see the full file/folder name when it's selected .

Admittedly... you can read the full name on the status bar, i noticed and pointed that out to this person with this specific issue... but after some time working with that, he told me that it doesn't work for extended periods of time organizing files/folders... instead of focusing your eyes on the area where you're doing stuff you are forced to avert your eyes "down there" to the status bar again & again . You end up more tired than usual .

What's funny is that i didn't notice before... and also that this only does seem to happen on Plasma ( didn't try LXQT or Nomad for other QT based references though ) .

Final thought : this kind of standarized behaviour ( showing the full name when selected ) makes sense; doesn't create unnecessary spacing and displays all info when really needed ( and when it's "really" needed all you need to do is select it ) .

Do you think it's doable ?
Comment 3 Nate Graham 2019-02-23 15:19:57 UTC
Right, so when text labels have been configured with a maximum line count and a particular item's label is long and gets elided, you want the full label text to be displayed when the item is hovered-over or selected. Seems reasonable. I could have sworn we already had a bug tracking this but now I can't find it. Let's use this one.
Comment 4 Ashram 2019-02-23 23:23:52 UTC
That's correct :) . 

Was amazed myself nobody else noticed before given this functionality is avaliable on all popular DEs & other OS... but couldn't find any filed bug matching this one ( did find something remotely related, but not this ) .
Comment 5 Ashram 2019-06-05 19:11:00 UTC
Not sure if there's some "etiquette" concerning updating status of certain bugs... and can't hide i'm also wondering if this particular one has had some visibility since it was filed... but just wanted to confirm:

Using KDE Neon user edition up to date... this bug is still present .
Comment 6 Christian Christiansen 2020-05-02 02:06:48 UTC
Created attachment 128090 [details]
Multiple files selected for dolphin without elided filenames

What should happen when multiple files with long filenames are selected? One trouble with allowing longer filenames to overflow is that files underneath end up covered by the text and can no longer be seen. (Attachment included)
Comment 7 Ashram 2020-05-03 13:45:29 UTC
@Christian Christiansen:

I noticed this bug from complaints received from a small group ( under 200 ) of linux users i offer assistance to ( free of charge, i see it as my way to help expand Linux / KDE / Plasma ) .

All complaints came from a particular group of people working on creative/artistic/design fields that work with large numbers of media files that must ( mandatory ) include all kind of additional info on filenames as well ( yes, info that's redundant as metadata for those files ) like dates, codecs, dates, etc, etc... for a number of reasons they all need that extra info and therefore all files name are pretty large .

For the record: all of 'em couldn't dislike more the latest update that shortens file names with three dots... in fact, i had to help some of 'em to transition to Gnome - even though they absolutely loved Plasma - because that was the last stab that killed their workflow .

For the time being, the particular use-case for displaying full long names at the risk of overlapping over folders/files below is checking individual filenames, one by one ( whether it is to check that particular file name or double check name sequences... whatever the case they only need to check one full long name at a time ) . 

The moment i read your comment i couldn't come up with any particular use case where any user might need to have full visibility of multiple long files/folders names at the same time... after all, the moment you select multiple ones is the moment you're about to execute a batch-action ( copy/move/rename/etc... ) and can't think of a real-life scenario where such visibility is mandatory/vital for any particular workflow.

Sent some messages asking for potential scenarios where this particular group of users i mentioned might need to have a better alternative when it comes to the case you're pointing at... but none of 'em saw any reason to check multiple long files/folders names simultaneously ... and all of them suggested the same i did ( you do such a thing when you're about to perform batch-actions ) without even suggesting nor hinting anything previously .

That said, it saddens me to confirm that such a small detail is becoming a deal breaker for this group of users that deal with files that are more & more & more common nowadays. I love Plasma and it's my DE of choice and the one i try to promote but the users i had to help transition to Gnome because of this are creating a domino effect and afraid in the end that all of 'em are going to migrate to Gnome at this rate... even though they love plasma, all the options, Krita integration, Krunner... but they're tired of stumbling upon the same painful stone on a daily basis .
Comment 8 Christian Christiansen 2020-05-06 08:23:45 UTC
@Ashram

Thank you for detailing that only when a single item with elided text is hovered or selected, should the full text be displayed. 

It may be possible to use another file browser in the interim (although from briefly looking PCManFM-qt and Konqueror also have the same behaviour as Dolphin); otherwise turning off elided text in Dolphin currently may be the best option.

I have taken a look into it, but I am not familiar with Dolphin's code and have been unable to come up with a solution, let alone a solution which isn't completely hacked together. Hopefully by including some information below, the job will be made easier for somebody else.

@Anybody wishing to patch this

So far as I can see, it is mainly the function KStandardItemListWidget::updateIconsLayoutTextCache() which needs to be adapted. It is easy to determine whether the item is selected (if isSelected()), and if so, for the name not to be elided.

Troubles I ran into:
1. Determining whether the item is the _only_ one selected. (Solving this could be pretty nasty, or maybe there's some neat way I've completely overlooked.)
2. Having the overflowing text always render neatly (as only the part where Dolphin expects the icon to be is re-rendered, leaving off the bit with the overflowing text).