Bug 173647 - Long filenames have unintellligent line breaks
Summary: Long filenames have unintellligent line breaks
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords:
: 175899 193483 194740 228157 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-10-27 01:02 UTC by Matt Hubert
Modified: 2010-08-16 21:33 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Hubert 2008-10-27 01:02:37 UTC
Version:           1.1 (using 4.1.2 (KDE 4.1.2), Kubuntu packages)
Compiler:          gcc
OS:                Linux (i686) release 2.6.24-21-generic

In Dolphin (and Konqueror for that matter), long filenames have line breaks in very unintelligent places. For instance, a long name like:
ailib_cpp_unix.zip
gets broken to:
ailib_cpp_un
ix.zip

I feel like this is a step backward from KDE 3, which broke the filename like:
ailib_cpp_unix
.zip

Granted the longest portion of the file name in KDE 3 is longer than that in KDE 4, but it also seems to expand to accommodate longer files without breaks. For instance, in KDE 4 a directory called 'Instrumental' becomes:
Instrumenta
l
whereas it was just 'Instrumental' in KDE 3. I feel like blindly breaking to the next line after 11 characters (what it seems to be doing) is really unappealing and makes things significantly harder to read. The KDE 3 way of intelligently breaking at periods and underscores, or whatever it was, still seems like the better choice.
Comment 1 David Dempster 2008-12-04 00:27:38 UTC
Moreover, if there is no punctuation, it should break in the middle of the word, at a syllable or morpheme boundary.  For example:

instru-
mental

To make it clear that there is no space in the name
(i.e. it isn't "instru mental"), it would be a good idea
to follow the standard practice in printed material of
displaying a hyphen at the end of the broken line.
You could grey it out so that it is obviously not
part of the file name.
Comment 2 Frank Reininghaus 2008-12-05 22:14:21 UTC
*** Bug 175899 has been marked as a duplicate of this bug. ***
Comment 3 Frank Reininghaus 2009-05-31 12:16:00 UTC
*** Bug 194740 has been marked as a duplicate of this bug. ***
Comment 4 Dario Andres 2009-10-22 00:39:02 UTC
*** Bug 193483 has been marked as a duplicate of this bug. ***
Comment 5 Fred Wells 2009-11-14 19:56:29 UTC
I completely agree with this bug report.  Although this may seem like a petty complaint, I would argue that this little lack of detail has a much bigger visual impact and contributes substantially to an unpolished KDE appearance.  There are a number of areas within KDE where visual detail is lacking.  This is but one.  I hope someone takes an interest in resolving this.  Although, judging by the age of this report, it seems sadly unlikely.  :(
Comment 6 Fred Wells 2009-11-14 20:15:33 UTC
One additional thought....  Before someone argues that the challenge is determining where to break, let me suggest this very simple solution. If a single word will force a line break, don't bother. Regardless where it is. For example:

   Konquer...

Is much more visually acceptable than...

  Konquer
  or

In fact this is already done for the last line, as follow:

  Firefox
  Web B...
Comment 7 Peter Penz 2009-11-15 14:52:34 UTC
For Dolphin in KDE 4.5 it is planned not to add new features, but only concentrate on polishing. This point is something which I'll try to solve for KDE 4.5...
Comment 8 Fred Wells 2009-11-15 20:55:26 UTC
Nice.   Can't wait!  Thanks!!  :)
Comment 9 Rick Smith 2010-06-17 19:54:21 UTC
Another case to consider...
Long names that start with a . should not create a new line after the dot.  For example, 

.xscreensaver

wraps like this

.
xscreensaver

Which looks really confusing.
Comment 10 Peter Penz 2010-08-08 13:35:29 UTC
*** Bug 228157 has been marked as a duplicate of this bug. ***