Version: (using KDE 4.2.0) OS: Linux Installed from: Fedora RPMs Dolphin often (but not always) truncate names of soft links in the contents panel, even if there's plenty of space available. I can't see a pattern. Sometimes a very short name is truncated to no letters at all (see first screenshot), other times long names are not truncated or are truncated in random places (see second screenshot).
Created attachment 31095 [details] A tree letters soft link name was truncated to zero letters The mnt folder is a soft link to /mnt. In contents panel, it appears as just "..."
Created attachment 31096 [details] Some soft link names are truncated, some are not All files listed are soft links. Some of them had their name truncated, others didn't. Names of real files are correctly truncated only if there's not enough space.
Created attachment 31097 [details] A very short name unecessarely truncated
Hmm, very strange. It's the first time such an issue has been reported... Do you know which Qt version you are using? I cannot reproduce this issue with the Suse packages of 4.2.0 or the self compiled version of 4.2.0... Thanks!
I can consistently reproduce this for the following names of symbolic links: as, asvn, sdavn, vnvnsvna, asfafwa, awfwaf, msvn, svna Exmampe: ln -s / asvn Happens in 4.2 with Qt 4.4 (qt-copy), and today's trunk with Qt 4.5 (qt-copy).
It's strange, indeed. This did not happen before the upgrade to KDE 4.2. I have qt 4.4.3 installed: $ rpm -qa | grep qt-4 qt-4.4.3-10.fc10.i386
Maybe it has something to do with the text being italic? Like, it reserves some space based on normal text size (highlighted area when you hover over the name), and then it figures out italic text won't fit because it's a bit longer than normal text?
Thanks Ambroz, that is a good hint and sounds very reasonable -> a fix in KFileItemDelegate is required. I changed the subsystem to kdelibs, but leave the assignment to me.
Created attachment 31252 [details] Trunk screenshot
I wanted to fix this issue, but have the problem that I cannot reproduce it on trunk (see attached screenshot from trunk) and also not on KDE 4.2.0 :-( On trunk I'm using Qt 4.5 (qt-copy) and on 4.2.0 Qt 4.4 (qt-copy). I even thought that it might be style related, but all screenshots use Oxygen. Any hints how that help me to reproduce the issue are welcome (I also tried the links from comment #5).
*** Bug 190103 has been marked as a duplicate of this bug. ***
*** Bug 191670 has been marked as a duplicate of this bug. ***
Although I couldn't reproduce this with most of the examples provided here, I found a truncated symlink in my home directory the other day. I can now reproduce this easily if a symlink name contains two or more 'x's ("xx", "xxx", etc.), but also two or more 'w's work as mentioned in one of the duplicates. Adding some kDebug output to KFileItemDelegate showed me that Ambrosz was right in comment 7. More precisely, 'maxLabelSize' in KFileItemDelegate::Private::layoutTextItems() is just large enough for non-italic text, but too small for the italic text, and then "size.width() > constraints.width()" is true in KFileItemDelegate::Private::layoutText(), causing the name to be truncated. I looked a while for the origin of this too small size and found it in DolphinFileItemDelegate::paint(). @Peter: Is it OK to commit the patch below? It fixes the issue for me in trunk. Index: src/dolphinfileitemdelegate.cpp =================================================================== --- src/dolphinfileitemdelegate.cpp (revision 968518) +++ src/dolphinfileitemdelegate.cpp (working copy) @@ -48,6 +48,10 @@ const QModelIndex dirIndex = proxyModel->mapToSource(index); const KFileItem item = dirModel->itemForIndex(dirIndex); if (!item.isNull()) { + // Symbolic links are displayed in an italic font + if (item.isLink()) + opt.font.setItalic(true); + const int width = nameColumnWidth(item.text(), opt); opt.rect.setWidth(width); }
Created attachment 33703 [details] My Font Settings This is a screenshot of my font settings - maybe that makes it reproducible more easily.
Thanks Frank! The patch looks good IMO, please commit and do a CCMAIL with fredrikh@kde.org (he is the maintainer of kfileitemdelegate).
SVN commit 968589 by freininghaus: Set the font to italic for symbolic links before calculating the size of the area which is made available to KFileItemDelegate::paint. Fixes the problem that Dolphin truncates the names of some symbolic links if the italic version of the font needs more space than the non-italic one. BUG: 183620 CCMAIL: fredrikh@kde.org M +4 -0 dolphinfileitemdelegate.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=968589
SVN commit 968598 by freininghaus: Set the font to italic for symbolic links before calculating the size of the area which is made available to KFileItemDelegate::paint. Fixes the problem that Dolphin truncates the names of some symbolic links if the italic version of the font needs more space than the non-italic one. Fix will be in KDE 4.2.4. CCBUG: 183620 M +4 -0 dolphinfileitemdelegate.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=968598
This bug should be reopened as I experience it on Fedora 19 with qt-4.8.5-10 and kde-workspace-4.11.2-1 - symbolic links are truncated in the end unnecessary where normal files are not truncated.
Created attachment 82911 [details] screenshot of bug The screenshot shows how the symbolic links are truncated while the normal file name is not truncated. In the bottom part are the full names of the links.
(In reply to comment #18) > This bug should be reopened as I experience it on Fedora 19 with qt-4.8.5-10 > and kde-workspace-4.11.2-1 - symbolic links are truncated in the end > unnecessary where normal files are not truncated. Thanks for reporting this. I'd prefer if you could open a new bug report for this issue. Even though the symptoms are the same as for the earlier bug, we don't use the code where the "old" bug was located any more, so the cause of the bug must be something different. It would also help if you could include your font settings in the new report (like what I did in comment 14), because I cannot reproduce the problem. Thanks for your help!
The new bug is here: https://bugs.kde.org/show_bug.cgi?id=326210