Version: 0.4.0 (using KDE KDE 3.5.3) Installed from: Gentoo Packages OS: Linux It is currently not possible to edit files through KIO slaves like sftp. This feature is needed for using ShowFoto as an allround image viewer/editor.
*** Bug 142112 has been marked as a duplicate of this bug. ***
Related to http://bugs.kde.org/show_bug.cgi?id=132745 http://bugs.kde.org/show_bug.cgi?id=154183
Johannes, This file is fixed now. right ? Gilles Caulier
I don't think so, you can only open an image, but not edit. Saving will not work (just tested it with FTP and SSH).
Andi, well, this commit from Johannes : https://bugs.kde.org/show_bug.cgi?id=132745#c12 ... do what exactly ? Gilles
Saving works via kio, if that is the only thing that has to be done for this bug... or I don't understand why it is not marked as a duplicate of the other bug I closed. ;)
(In reply to comment #5) > Andi, > > well, this commit from Johannes : > > https://bugs.kde.org/show_bug.cgi?id=132745#c12 > > ... do what exactly ? > > Gilles For me it does nothing... in dolphin it works...
Ok there must be a regression, when I closed the other bug it worked.
Andi, did you try saving only with an imported raw file? For normal files it works for me. Raw doesn't work because for some strange reason the thread receives RAW as image format to save instead of the format selected in the saving dialog.
Johannes, RAW loaded in DImg has read only property. This can be the problem... Gilles
Yes, but it shouldn't have selected raw at all. I found out that there are some errors in how the KFileDialog is used (reading mime but using filters etc.) and currently try to fix it.
Created attachment 38127 [details] patch to enable remote saving of raw files Gilles, Andi This patch enables remote saving also for raw files. To fix this I refactored a big part of the saving method. Could you please check that I didn't break anything? Some things to notice: - The file dialog was initialized with filters and afterwards it was tried to read mime information. This isn't possible as the api documentation said and never worked. So there was a fall back to the other variants for determining the target file format. - Remote saving didn't succeed for raw files, because the first fall back method tried to get the extension of the target url to determine the format and used QFileInfo for that purpose. However this only works for local files. So I added string manipulation for local files to extract the extension - Because the above check didn't work for remote methods, the format of the source file was taken (which could be raw). Unfortunately this wasn't checked against the writeable formats. So I added this check to avoid writing RAW format. - I've removed the KImageIO filter "all image types" from the dialog, because this doesn't clearly allow to determine the desired format from the filter, which also means that special format options could not be displayed.
(In reply to comment #9) > Andi, did you try saving only with an imported raw file? For normal files it > works for me. Raw doesn't work because for some strange reason the thread > receives RAW as image format to save instead of the format selected in the > saving dialog. No, normal JPGs. Maybe we are misunderstanding each other, but I opened a JPG via FTP, edited it, but when I want to save it, it is saved in /tmp/xjjdhsdjhsdjsdhsj (some strange temp name). It is not uploaded directly as for example Kate does when I edit files remotely on my XBOX.
(In reply to comment #13) > No, normal JPGs. Maybe we are misunderstanding each other, but I opened a JPG > via FTP, edited it, but when I want to save it, it is saved in > /tmp/xjjdhsdjhsdjsdhsj (some strange temp name). > It is not uploaded directly as for example Kate does when I edit files remotely > on my XBOX. Ok, that's a use case I did not think of. I will have to check that.
Well this is my understanding of "editing non-local files" :-)
Created attachment 38132 [details] also allows opening and later saving of remote files This enables opening of remote files and saving them later. There's still on thing I don't know how to fix: If you save the remote file you are first asked if the local temp file should be overwritten. I can't remove this question for remote files because it is invoked before the template method save() tells the real destination url via startSaving(). Only with this url one can decide if the file is a remote on or not. Any ideas how to fix this?
You mean that promptForOverWrite() is invoked from slotSave() using m_canvas->currentImageFilePath()? You could solve that by adding a virtual method returning the current URL (documented to return non-local URLs as well). Or make prompForOverwrite as a whole virtual. Or move the calls to m_canvas->load() including KIO::NetAccess downloading to EditorWindow and store the "true" current URL there.
Created attachment 38140 [details] Now also with removed request for overwriting the temp file Patch includes now Marcel's proposed solution with a virtual hook method that returns the destination url. To my mind everything is solved now. Should we apply it before beta6?
If you have done some basic testing, apply it now so it goes into beta6 tomorrow.
SVN commit 1046235 by jwienke: * Allow editing remote files with showfoto * fix handling of raw files for remote saving BUG: 132079 M +2 -1 NEWS M +14 -5 showfoto/showfoto.cpp M +1 -0 showfoto/showfoto.h M +211 -67 utilities/imageeditor/editor/editorwindow.cpp M +48 -0 utilities/imageeditor/editor/editorwindow.h M +5 -0 utilities/imageeditor/editor/imagewindow.cpp M +1 -0 utilities/imageeditor/editor/imagewindow.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1046235