Version: 1.4 (using KDE 4.4.0) OS: Linux Installed from: Fedora RPMs The file name, eg, "a+0#f+0#f" (w/o the quotes) displays as "a+0#0#f+f". When F2 is used to rename the file, the correct file name is displayed. The does not happen when then file name is, eg, "a+b#c+1#e". It appears that only two digits in prior to the "#"'s trigger the problem. A regexp problem, perhaps?
Thanks for the report, I can confirm this in trunk. A shorter name that is displayed incorrectly is "+0#z+0" (shown as "+0#0+z"). I cannot reproduce this in 4.3.1 (Opensuse) using Qt 4.5.3, so it seems that this is a regression.
Just checked - this is still happening.
And still happening with "Dolphin Version 1.6.1, Using KDE Development Platform 4.6.3 (4.6.3)" Surely, after more than a year, this bug can no longer be considered "NEW". And, equally surely, isn't it the duty of a file manager to correctly report the contents of the file system, no matter how weird the name of an object? Things like previews and icons are minor "bells and whistles" when compared to the need for an accurate depiction of the file system contents. If this name is being reported incorrectly, what confidence do we have that there aren't a whole class of names that are similarly affected?
Thanks for the update. I can confirm that the issue is still present in master. > Surely, after more than a year, this bug can no longer be considered "NEW". "NEW" is the state that a confirmed bug is in until it is fixed, no matter how old the bug is. I fully agree that this issue should be fixed. The problem is that finding the root cause of bugs like this is usually a very time-consuming task, and because there are lots of bug reports and only a few volunteer developers who work on Dolphin in their free time, fixing bugs often takes a lot longer than it would in a perfect world. I'll put this on top of my TODO-list and hope that I find some time to investigate the issue during the next month.
I haven't found the root cause yet, but it seems that something fishy is going on here with Zero-width space characters inserted by KStringHandler::preProcessWrap(...). If I remove the call to that function in KFileItemDelegate, the bug is gone. But that would cause other problems, so some more investigation is needed.
Created attachment 60893 [details] testcase This seems to be a Qt bug. I've narrowed it down to QString s = QString("a+") + zwsp + "0#" + zwsp + "f+" + zwsp; show(s); s+=QChar('0'); show(s); Complete testcase attached. However, the QChar::unicode() sequence of the characters looks reasonable. I guess it is a problem in the rendering routine for QString, but I have no idea where that might be (within Qt).
After your comment re how maintenance is done on KDE I decided to have a look for myself. (For the record, I've submitted a few patches in the, long distant, past) As detailed above, I'm using Fedora so I started with the SRPMS. To see if I was looking in the right place, I placed "abort()" bombs in the constructors of various classes in .../dolphin/src/views. But none of them fired!!! So, for my benefit only, in what module (model / view) is the data stored?
Kevin, thanks for helping to track down this issue. Any help is always appreciated. You don't need to look in Dolphin's code (not even in any KDE code) for the bug. The file name is stored correctly everywhere. The problem is, as Sebastian said in comment 6 (very nice test case, btw!) inside Qt. It seems that drawing the file name on screen goes wrong if zero width spaces are inserted. These spaces should actually not affect the look of the string at all. The best way to proceed is probably to start with Sebastian's Qt-only test case und trace the way the string takes through Qt's text drawing routines. These are quite complex though. Alternatively, one could just report the bug upstream to Qt and provide Sebastian's test case (or maybe a modified version of it where you could see the correctly displayed string next to the messed-up one, such that you can see the bug at first glance). Maybe there's somone at Qt Software who could then tell immediately where the buggy code might be and how it could be fixed.
Thank you for your response. I accept that the problem is within Qt code, not KDE. But, and I stress, purely for my own knowledge, what is the model & view that controls the main Dolphin display? And, thanks for giving this problem your attention.
>But, and I stress, purely for my own knowledge, what is the model & view > that controls the main Dolphin display? The "main Dolphin display" is controlled by the class DolphinView that internally either uses DolphinIconView, DolphinDetailsView or DolphinColumnView. The model is represented by KDirModel located in kdelibs (and with some custom extensions by DolphinModel in the Dolphin code). But before digging into those code-parts: Dolphin will get a new view-engine for 4.8 and as 4.7 will be out soon it makes no sense providing larger patches for those things.
I've created an upstream bug report: http://bugreports.qt.nokia.com/browse/QTBUG-19949
The Qt people have fixed this for Qt 4.8.0: http://qt.gitorious.org/qt/qt/commit/a5c3064439a9f1483565e5d9dfbf0342cd9236f0