https://bugs.kde.org/show_bug.cgi?id=395296
--- Comment #2 from Theo <alpha0...@yahoo.de> ---
(In reply to Theo from comment #1)
> else if ("model/x.stl-binary") {
Obviously, this must read
else if ("model/x.stl-binary" == mimtype) {
but this turns out to not work that well after all because MIME type detection
seems to be unreliable, even if we ignore the false detection as
"model/x.stl-binary", which, as opposed to my earlier claim, has been fixed
recently:
https://bugs.freedesktop.org/show_bug.cgi?id=106330#c21
Testing some more ISO images, I came across a image file that is detected as
"text/plain", while others are correctly detected as "application/x-cd-image"
by kmimetypefinder5, but are passed as "application/octet-stream" to
KIso::prepareDevice in iso/kiso.cpp. So to make it work with all of my sample
ISOs, I used the following atrocity:
else if ("model/x.stl-binary" == mimetype ||
"application/octet-stream" == mimetype ||
"text/plain" == mimetype) {
setDevice(new QFile(filename));
}
I think KIso::KIso and KIso::prepareDevice (kiso.cpp) need some attention by
someone who knows how to handle MIME type detection. Right now it seems to be
quite a mess: Why is KIso::KIso considering compressed tar filed? Why does it
care about KOffice docs? Why are gzip and bzip2 treated explicitly, as opposed
to xz, which also works? Why are ISOs detected as "application/octet-stream",
although kmimetypefinder5 sees them as "application/x-cd-image"?
--
You are receiving this mail because:
You are watching all bug changes.
