Most of operations are disables when opening files from remote url. I can't save files or even check file properties. Reproducible: Always Steps to Reproduce: 1. Open any image from remote location e.g. gwenview https://cdn.kde.org/img/logo.plain.small.png Actual Results: Most of the options from File and Edit menu are disabled. Expected Results: You should be able to perform operations like "save", "open with" or "rotate"
The issue is still actual with 16.04.3 even on other distros (like Gentoo).
NB: it seems, it is a `contextManager()->currentUrlIsRasterImage();` fault: if I change call to it (in app/imegaopscontextmanager.cpp) to just "true", then all the actions becomes active.
NB: `urlKind(currentUrl())` (which `currentUrlIsRasterImage()` calls to detect return value) returns 8 every time for remote links, whether it jpg or png or whatever. While KIND_RASTER_IMAGE (another argument to check against) returns 16. That's why all of that functions become inactive. So, I have two notes for developers: 1) why do you disable that actions (including "save as") for non-raster images at all (even if we forgot about that broken thing)? Why can't we "save as" opened svg/eps/whatever file? 2) MimeTypeUtils->mimeTypeKind (lib/mimetypeutils.cpp line 130) gets "application/octet-stream" as an argument (although, that is pretty strange, since at least few servers I checked returns image/* content-type headers), and after all checks it returns it's "default" value (KIND_FILE). So, that's why `contextManager->currentUrlIsRasterImage` (lib/contextmanager.cpp line 263) returns false. So, as proper fix I'd suggest to: 1) get rid of all that mime checks for at least "save as" and related actions. 2) debug MimeUtils why the hell it gets octet-stream, and not the real mimetype (to keep intended behaviour for rotating/etc actions for raster images only, although, I personally would like ability to rotate vector images too :D). For users: As temporary solution, I'd suggest you to apply that patch (with patch -p1): === cut === --- a/lib/contextmanager.cpp 2016-07-25 03:59:24.704428867 +0700 +++ b/lib/contextmanager.cpp 2016-07-25 03:59:02.582209995 +0700 @@ -263,7 +263,7 @@ bool ContextManager::currentUrlIsRasterImage() const { - return MimeTypeUtils::urlKind(currentUrl()) == MimeTypeUtils::KIND_RASTER_IMAGE; + return MimeTypeUtils::urlKind(currentUrl()) != MimeTypeUtils::KIND_UNKNOWN; } QUrl ContextManager::urlToSelect() const ==== /cut === (in Gentoo — just put it in /etc/portage/patches/kde-apps/gwenview/ with any name and ".patch" suffix)
*** Bug 354714 has been marked as a duplicate of this bug. ***
Created attachment 103972 [details] fix_remote_readonly.patch Here is attached patch from my previous comment. Dear devs, please, apply it to the codebase... (with `-p1`, if any)
Alternative way to fix would be to fix urlKind, but I myself have no idea how to fix it. And, with my patch it works as intended anyway: even if buttons not disabled when looking vector image, gwenview will still throw awarning if it can't apply requested action on current image (although, I'm not sure, that it is too hard to rotate vector images, but it is a case of another request).
Created attachment 104170 [details] Proposed patch The issue is caused by porting from KMime to QMime. http://doc-snapshots.qt.io/qt5-dev/qmimedatabase.html#mimeTypeForUrl says: "If the URL is a local file, this calls mimeTypeForFile. Otherwise the matching is done based on the file name only, except for schemes where file names don't mean much, like HTTP." Could you test attached patch?
Scratch that.
(In reply to Christoph Feck from comment #7) > Could you test attached patch? ``` /var/tmp/portage/kde-apps/gwenview-16.12.2/work/gwenview-16.12.2/lib/mimetypeutils.cpp: In function ‘QString Gwenview::MimeTypeUtils::urlMimeType(const QUrl&)’: /var/tmp/portage/kde-apps/gwenview-16.12.2/work/gwenview-16.12.2/lib/mimetypeutils.cpp:128:15: error: ‘class QMimeDatabase’ has no member named ‘mimeTypeForFileName’ return db.mimeTypeForFileName(url.fileName()).name(); ``` // JFYI
Created attachment 104172 [details] Proposed patch, now compiles That should work, provided that the remote URL filename has the correct file type suffix.
> That should work, provided that the remote URL filename has the correct file > type suffix. Unfortunatelly, it is not always the case. Some image hostings always tell ".jpg" filename, while real file (Content-Type) can be png and even gif. And some others like akamai (probably in use by facebook and google) gives the url that ends like directory name (with slash ("/")).
And, btw, your patch seems to work in conditions mentioned by you :)
*** Bug 362302 has been marked as a duplicate of this bug. ***
*** Bug 375953 has been marked as a duplicate of this bug. ***
*** Bug 370740 has been marked as a duplicate of this bug. ***
*** Bug 398596 has been marked as a duplicate of this bug. ***