If Parley is creating files with damaged names, then it is an issue of that application not handling the QString conversions correctly and safely. Please file a bug at bugs.kde.org. ( If System Settings can handle the .desktop files with Hebrew, Arabic, etc. characters fine, then i'm sure Parley can also )

Just to clearify: you think it is ok to have files on my filesystem that KDE4 cannot open, not even rename

bcooksley wrote:If Parley is creating files with damaged names, then it is an issue of that application not handling the QString conversions correctly and safely. Please file a bug at bugs.kde.org. ( If System Settings can handle the .desktop files with Hebrew, Arabic, etc. characters fine, then i'm sure Parley can also )

I know that, but this is not the important point of the discussion.

And I report the bug when I found it https://bugs.kde.org/show_bug.cgi?id=208109.

samhain wrote:Just to clearify: you think it is ok to have files on my filesystem that KDE4 cannot open, not even rename

Ok, I agree with you. I faced this situation once when I get unknown filename encoding from a friend who use Windows. Something like this: ���� ��� � I try to rename it but I can't. Moreover, I can not delete it !! Dolphin keeps saying that file does not exist.

Do you have bug number to vote for it?

I've never seen a file where every letter is unrecognised, but I did meet the single-letter issue years ago under windows - or was it even before windows? Anyway, the way to rename them was to rename through the command line, substituting a ? for the missing letter. The same method should work here, too. If all else fails, is it possible to drag the file that has every letter misrepresented into an empty directory then use 'mv * testing.*' substituting the desired name for testing. This should re-write the name with your encoding, I would think.

I know some businesses are years behind on this sort of thing, but someone is going to have to tell them that in the world of international trading, anyone with a different encoding set may have problems with their settings. Believe it or not, there are some people that do not live in the USA and do not use USA settings. Ideally, get them to have alternate encodings, so that they can read everyone else's encoding. In any case you can also have alternate encodings set. There's no reason why not.

Zayed wrote:

samhain wrote:Just to clearify: you think it is ok to have files on my filesystem that KDE4 cannot open, not even rename

Ok, I agree with you. I faced this situation once when I get unknown filename encoding from a friend who use Windows. Something like this: ���� ��� � I try to rename it but I can't. Moreover, I can not delete it !! Dolphin keeps saying that file does not exist.

Do you have bug number to vote for it?

There is several reported bugs about this problem but Thiago Macieria mark all as WONTFIX, so broken encoding support don't be fixed in KDE 4. I recommend you reading discussion in https://bugs.kde.org/show_bug.cgi?id=165044 and draw your own conclusions about Thiago decision.

You must use other file managers for other desktops (Gnome, KDE 3, etc...) or console to rename or delete broken encoding files.

If you like you can vote this wish, https://bugs.kde.org/show_bug.cgi?id=204768, that I created as a workaround but, is an encoding problem, so don't expect that be resolved soon.

@samhain: I never said that.

In KDE / Qt applications, all strings are handled by a class called "QString" which has a number of methods to convert out the contained string to various formats. If applications use the wrong method then you will end up with a screwed up filename, etc.

So just tell me who is to blame? KDE4? QT4? "the-application(tm)"?

All I hear in this forum - when an unwanted thigs shows up - is "It's not me, it's them!" or "Oh, it's me? Won't fix!". Well, thats a promising way to handle.

It is a bug, and a bad one, too. If you are in mixed environment, what do you do? It's definitly nogo for KDE4 in business environment. (Converting archives? Gooood idea ...)

Qt4.3+ lack the conversion methods previously present. Even they didn't cover all the possible methods either as Thiago stated, so even that might not solve everything.

@samhain

"So just tell me who is to blame? KDE4? QT4? "the-application(tm)"? "

KDE 4, because users use KDE4 and not QT.
People dont say that libraries are bad. No, thay said OS is bad.

This is getting utterly ridiculous. Users go to the supermarket - does that make the supermarket to blame? Just drop this, please. Blaming is pointless in any case - it solves nothing. This same subject, with several of the same participants, has been kicked around endlessly on several mailing lists as well as the original bug report.

In the end, the developer decides what he will or will not work on. Get real. You make your decisions, he makes his.

bcooksley wrote:@samhain: I never said that.

In KDE / Qt applications, all strings are handled by a class called "QString" which has a number of methods to convert out the contained string to various formats. If applications use the wrong method then you will end up with a screwed up filename, etc.

Sorry but I disagree. If your class has several methods and an erroneous choice of method creates a broken encoding than it can be handled by itself, class must raise an exception. If you try to create a file name in your system with an incorrect name, error is launched and file is not created so, the same for QString.

That is one of my points about bad design of QString, QByteArray and QTextCodec. Another one is that previous code must be rewriten, there is a lot of encoding bugs in KDE 4 for this reason (ktts, search engines and, practically, all code from KDE 3 that was not revised or rewriten).

For example, I can't use ktts for japanese or web shorcuts in EUC-JP and was one of the reasons I don't use konqueror anymore. An yes, both bugs are reported long time ago .

> In the end, the developer decides what he will or will not work on. Get real. You make your
> decisions, he makes his.

Yes, that is what happens now. But what would you suggest to change it? Tell all offended users "hey, we know it sucks but please don't complain, our developers are so sensible, and btw it has been decided that this does not suck"?

>>annew wrote:
"In the end, the developer decides what he will or will not work on. Get real. You make your decisions, he makes his."

And I say: "In the end, the developer will stay without users."

Ok, as the topic title already states "enough is enough", this should now come to an end.
We have now 5 sites of discussion about 1-4 topics, and that is not where it should go. So either open a new topic for _one_ topic or discuss it directly via a bug report and the corresponding comments with the developers directly.

Comments like

And I say: "In the end, the developer will stay without users."

don't make it better. It is
1) not helpful
2) probably disrespectful for all the work that was already done
3) don't even show an option for a solution
4) and along with that don't follow the CoC

This topic will now be closed. Use another one to discuss ONE topic at a time. Just give others the chance to even follow, without too much blaming.