KDE Base

Bug #510018
Comment #100

Comment 100 for bug 510018

Revision history for this message

In KDE Bug Tracking System #165044, Kde-bugger (kde-bugger) wrote on 2010-10-04:

#100

Guys,

if I insulted anybody with my last comment I apologize.

But please stop your ranting here, it is not productive at all. On the contrary, you are about to scare potential developers like me away because you make the KDE users sound like an ungrateful bunch of people. I have a rough idea how this could be fixed but it would probably have to happen in Qt and is a bit of work for which I currently don't have the time.

Essentially my idea boils down to:

* The issue of displaying the invalid filenames (with question marks and stuff) is solved quite easily: QFile and QDir store the raw representation of the filename in an extra QByteArray member and if that string fails to be converted to a UTF-8 QString, it has a flag/method like isValidFileName and a method to retrieve the representation of the invalid file.

* But, since we can't convert the display file name back to the original one, once this string representation is inside an application, we lose track of the link between the original FS entry and the displayed one. I'd probably solve this by overloading the QFile/QDir members which return a QString with one which returns a new class of QFileName (and QPathName). That one could be a rather thin wrapper around QString which adds the QByteArray I mentioned above. Both could even be thrown into an union to save RAM if anybody is afraid of losing any of that.

* Hopefully, that wouldn't change anything for all existing applications, since they's still request QStrings. To make use of this representation, Dolphin and friends had to use QFileNames everywhere they use QString to represent filenames now. So all applications handling files would have to be changed. Lot of work.

* There are still corner cases, like how to represent these filenames in URLs and stuff I probably didn't think about. But at least Dolphin should be able to manage these broken files again. Or not, I don't know until I (or somebody else) tried. Probably Thiago can point out at least ten flaws in my idea :)

Anyway, I hope this convinces you that there are actually people thinking about this bug and this might be fixed one day. But until then, please keep the noise on this bug down.

Guys,

if I insulted anybody with my last comment I apologize.

But please stop your ranting here, it is not productive at all.  On the contrary, you are about to scare potential developers like me away because you make the KDE users sound like an ungrateful bunch of people.  I have a rough idea how this could be fixed but it would probably have to happen in Qt and is a bit of work for which I currently don't have the time.

Essentially my idea boils down to:

* The issue of displaying the invalid filenames (with question marks and stuff) is solved quite easily: QFile and QDir store the raw representation of the filename in an extra QByteArray member and if that string fails to be converted to a UTF-8 QString,  it has a flag/method like isValidFileName and a method to retrieve the representation of the invalid file.

* But, since we can't convert the display file name back to the original one, once this string representation is inside an application, we lose track of the link between the original FS entry and the displayed one.  I'd probably solve this by overloading the QFile/QDir members which return a QString with one which returns a new class of QFileName (and QPathName).  That one could be a rather thin wrapper around QString which adds the QByteArray I mentioned above.  Both could even be thrown into an union to save RAM if anybody is afraid of losing any of that.

* Hopefully, that wouldn't change anything for all existing applications, since they's still request QStrings.  To make use of this representation, Dolphin and friends had to use QFileNames everywhere they use QString to represent filenames now.  So all applications handling files would have to be changed.  Lot of work.

* There are still corner cases, like how to represent these filenames in URLs and stuff I probably didn't think about.  But at least Dolphin should be able to manage these broken files again.  Or not, I don't know until I (or somebody else) tried.  Probably Thiago can point out at least ten flaws in my idea :)

Anyway, I hope this convinces you that there are actually people thinking about this bug and this might be fixed one day.  But until then, please keep the noise on this bug down.