If the okteta part is the only available service for the selected
mimetype, but there is an external application available for that
mimetype, the application probably knows better how to handle that file
and should be preferred to the okteta part.
Details
Details
Double-click an excel in some archive and make sure it opens in libreoffice instead of the okteta part.
Diff Detail
Diff Detail
- Repository
- R36 Ark
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 12339 Build 12357: arc lint + arc unit
Comment Actions
Note: as side-effect of this patch, now binaries/libraries in an archive will open in Okular, because there is a okularapplication_fb desktop file registered with application/x-sharedlib.
@aacid why is okular associated with that mimetype?
Comment Actions
It is not?
okular$ wcgrep -i sharedlib
./generators/CMakeLists.txt:21: URL "http://www.digikam.org/sharedlibs"
Comment Actions
Ah, weird. Then why is okularApplication_fb.desktop associated with binaries? (even if I right-click any binary in /usr/bin from dolphin)
Can someone else reproduce or maybe it's a local fuckup in my system?
Comment Actions
What is so wrong with hex editor previews? Spot your trojans while they enter your system in a zip !;)
More serious: I am not sure if users want a full-blown application started instead of the previewer. Even more if this cannot be foreseen when triggering the preview, what actually will happen.
I would rather expect no preview if there is no (wanted) previewer available. And have a dedicated "Open" instead.
| part/arkviewer.cpp | ||
|---|---|---|
| 236 | Perhaps other than hardcoding "oktetapart" one might want to catch services which support the mimetype "application/octet-stream". So do something like (untested) offers.constFirst()->mimeTypes() == QStringList(QStringLiteral(""application/octet-stream")) | |
Comment Actions
BTW, this is an old generic problem, which has been already present with embedded previews in Konqueror. With MIME types inheritance there is information missing, if the inheritance is something like a format change, i.e. if the base type is a generic container format. E.g. with a SVG file (application/octet-stream->text/plain->application/xml->image/svg+xml), the user usually does not want the see the hex view, the plain text or the XML view, With a ODT file (application/octet-stream->application/zip->application/vnd.oasis.opendocument.txt), the user does not want to see the hexview or the zip archive structure.
It's a bit limiting to only do something against hex editor displays ;)
Comment Actions
See the test plan: I wanted to open an excel in some archive, I got hex numbers instead. I think that's not what the average user would expect.
You are right that I shouldn't hardcode the okteta name though. I'll fix that.
Comment Actions
But why not do open the full app for all mimetypes? This seems a bit of a surprise box then. And questions the purpose of the preview mode.
Comment Actions
Or, in other words: this seems a pretty single symptom driven fix, which does not reflect the overall UI of Ark. There are "Preview", "Open", "Open with" actions available. As user I would expect certain different things to happen for each action. The LMB click seems bound to "Preview", so it should do a preview, not a normal open. If preview is not supported for a file, that should be shown instead IMHO, instead of without preannouncement acting as if one had chosen "Open".
My passive suggestion would be to rethink the UI instead to reflect the challenges there are with the limited set of preview modules matching the actual mimetypes.
Comment Actions
Well, the point of the preview is that I don't need the full app if I just want to have a quick glance at some file. I don't need the full kate or the full okular if I just want to quickly see what's in a text file or in a PDF.
We could show an error if the preview is not supported, yes. But we would need to change the default binding to the LMB (from "Preview" to "Open"). Which is something I've been trying to avoid because I think KParts are nice and we shouldn't hide them.