This is a duplicate of https://bugs.kde.org/show_bug.cgi?id=97167, https://bugs.kde.org/show_bug.cgi?id=161777 and https://bugs.kde.org/show_bug.cgi?id=167755 Konqueror opens kwrite for viewing source of HTML documents and knows their encoding from HTTP headers, but the existing specifications don't specify a way to pass the "--encoding ???" switch to kwrite. The result is that this useful switch is not passed by konqueror, and kwrite assumes that the document is in the system locale encoding, which is not always true. The user sees garbage characters and has to correct the encoding through the menu in kwrite, even though konqueror knew it. Please extend the desktop-file and mime-database specifications so that the statement "if the encoding of the document is known, it should be passed to the program after this switch" can be expressed. I.e.: it should be possible to write a desktop file that tells that kwrite should be started as "kwrite" if there is no document, as "kwrite /home/user/document.txt" if the encoding of document.txt is not known in advance, and as "kwrite --encoding KOI8-R /home/user/document.txt" if the application that wants to run kwrite knows in advance that document.txt is in KOI8-R. Also it should be possible to say: "I don't know the encoding of document.txt, but want to open it anyway with the user's preferred application" (resulting in "kwrite document.txt") and "I know that the encoding of document.txt is KOI8-R and want to open it with the user's preferred application, passing the encoding information to it" (resulting in "kwrite --encoding KOI8-R document.txt").
Hrm. We don't have a good way to say "use kwrite %f" when this and "use kwrite --endoding %s %f" when that. Not sure how we can handle that. (also, we have no flag for the encoding, but that's fixable -- although it's rather weird to add a flag for something like this, which is only useful for a few apps).
Maybe add to desktop file a new field, ExecEnc or something like that, that should be used instead of Exec (with the obvious fallback) when the encoding of the document is known, and use Exec in other cases?
(In reply to comment #2) > Maybe add to desktop file a new field, ExecEnc or something like that, that > should be used instead of Exec (with the obvious fallback) when the encoding of > the document is known, and use Exec in other cases? That's not a good idea. We don't want to add a new key for 0.01% of the use cases of .desktop files. Else we'd have tons of keys.
So let's search for alternatives (including closing this bug as "wontfix, don't use desktop files and mime database for viewing page source"). OTOH, these 0.01% are important enough to have three duplicate bugs.
(In reply to comment #4) > So let's search for alternatives (including closing this bug as "wontfix, don't > use desktop files and mime database for viewing page source"). A very very crude hack if you need some fast reply would be to support some X-Exec-if-encoding-available key. No need to change the spec. But I don't have an idea of how to fix it the right way at the moment.
IMHO, the use cases for additional arguments are nearly the same as for the need to pass additional information after the main Content-Type HTTP header (i.e., where the standard MIME type such as text/plain would be too generic and thus unusable - indeed, there is no text/plain, there is always text/plain in some charset). I hope this analogy would help you in finding a proper solution and establishing formal criteria when a use case warrants a new key.
Sorry for the noise, reassigning to new (since 2 years) maintainers (Ryan & David).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/desktop-file-utils/issues/50.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.