While it doesn't necessarily decode filenames _correctly_, it's major step up from the current behaviour where KDE (really, Qt) applications are incabable of even _touching_ files with broken filename encodings.
Background: Qt upstream considers files with invalid encodings in filenames to be "filesystem corruption" but has removed the "transition code" that dealt with it in the past. This results in cases where applications will simply silently ignore files with names that are improperly encoded...at best. (Or it will give you warnings about the file not existing, like when you try to rename it.)
Upstream has stated that this is nearly impossible to fix in Qt4 and has further steadfastly refused to fix this in Qt5.
I'm not sure if unzip upstream is still alive and working to improve filename encodings.
I haven't seen this issue with GTK et al.; as far as I can tell, it's unique to Qt.
I will add this to the agenda for the next KDE team meeting.
Do you have any links to Qt upstream stuff? Maybe it will be of some interest to Qt team.
(In reply to comment #1)
> I will add this to the agenda for the next KDE team meeting.
> Do you have any links to Qt upstream stuff? Maybe it will be of some
> interest to Qt team.
Yeah, this is first covered in a post on kde-core-devel outlining the limitations involved in Qt4:
Also, the comment thread on Thiago's blog is...enlightening (and painfully shortsighted). (i.e. Someone from usability needs to smack him.) This is relevant because he's the one writing it.
Is there anything we (qt) can do here?
(In reply to comment #3)
> Is there anything we (qt) can do here?
I'm not sure, I CCed because it appears to technically be a Qt bug, but primarily in case someone had further insight into the issue.
No problem to unCC if it's not worth tracking from a Qt point of view.
(In reply to comment #4)
Well, apparently this is not something Qt upstream can/is willing to fix, therefore can be considered CANTFIX from our point of view.
Done as per meeting decision.