Version: (using KDE Devel) Installed from: Compiled sources Expected behaviour is that no more characters are hidden than is needed to make the name fit in the available space. This is however not the case, and a lot of space is wasted. See http://www.ping.uio.no/~mortehu/kde/quickbrowser.png for an example of this.
Subject: Re: New: Poorly chosen placement of '...' in long file names in Quick Browser On Freitag, 20. Dezember 2002 19:28, Morten Hustveit wrote: > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=52150 > Summary: Poorly chosen placement of '...' in long file names in > Quick Browser > Product: kicker > Version: unspecified > Platform: Compiled Sources > OS/Version: Linux > Status: NEW > Severity: normal > Priority: NOR > Component: general > AssignedTo: jfirebaugh@kde.org > ReportedBy: morten@debian.org > > > Version: (using KDE Devel) > Installed from: Compiled sources > > Expected behaviour is that no more characters are hidden than is needed to > make the name fit in the available space. This is however not the case, > and a lot of space is wasted. See > http://www.ping.uio.no/~mortehu/kde/quickbrowser.png for an example of > this. I fail to see what you see as bug here. What would you have expected to see instead? Greetings, Stephan
Subject: Re: Poorly chosen placement of '...' in long file names in Quick Browser http://www.ping.uio.no/~mortehu/kde/quickbrowser2.png shows what I think it should look like. The diff is available at http://www.ping.uio.no/~mortehu/kde/quickbrowser-diff In the original screenshot, the width of the names that got '...' in them varies heavily. Specifically, look at "Little Star -...olly mix).ogg" and the following "Los Ladrones ...blas mix).ogg". In the patched version, the maximum length of a string is 20 em (20 widths of the character 'm') rather than 30 characters, so all names with '...' occupy almost the same amount of horizontal space.
i agree that it looks quite a bit nicer like this. i've taken the patch and added methods to KStringHandler for em and pixel based (which the em based methods use) squeezing of strings. i have concerns for really large strings being passed through these methods as they aren't very efficient (though they could be improved upon by taking out larger chunks of text, or just calling fontmetrics.width() on substrings, etc). i don't notice a speed issue here with a quickbrowser showing my mp3 collection on my pII 400, though, so it can't be all that bad =) coolo: what do you think? worth committing?
this is now fixed in HEAD. due to requiring additions to the KDE API it won't appear until KDE3.2