Version: desconocido (using KDE 3.5.2, Debian Package 4:3.5.2-2 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.15 The actual process to use kioslaves with non-KDE apps is the following (with an example): 1) I open fish://host in Konqueror (or any kioslave). 2) I open a file called My_Document.odt with OpenOffice. 3) The file is copied to my computer in /var/tmp/kdecache-user/krun/28808.0.My_Document.odt. 4) I modify the file and press "Save", so the local copied is updated. 5) When I close OpenOffice (and just in that moment) a dialog appears asking me to send the modified file to the server. 6) I press "Ok" and the file is copied in the server and deleted from my system. The problem in this process is obvious: what happens if the user saves the modified file but doesn't close the app? then the file is not updated in the server. I've seen a lot of confusion related to this issue. So I propose the following (and hope to be feasible): 1) I open fish://host in Konqueror (or any kioslave). 2) I open a file called My_Document.odt with OpenOffice. 3) The file is copied to my computer in /var/tmp/kdecache-user/krun/28808.0.My_Document.odt. 4) I modify the file and press "Save", so the local copied is updated. But KDE in anyway notes that the file has been updated (it can monitor the "last modification time" of the local copy) and send automatically the modified file to the server. If this method is feasible it could help improving the integration of non-KDE apps in KDE. So, what do you think? is it feasible? could FAM help here?
No. In step 4, we could watch the file for modifications, but we'd prompt the user if he wants to upload it again. So, every time you hit Ctrl+S, you get a nice popup dialog asking if you want to upload. How does that sound?
> ------- Additional Comments From thiago kde org 2006-04-14 20:05 ------- > No. > > In step 4, we could watch the file for modifications, but we'd prompt the > user if he wants to upload it again. So, every time you hit Ctrl+S, you get > a nice popup dialog asking if you want to upload. > > How does that sound? Exactly as the kioslaves with KDE apps? If I open a fish:// file with Kwrite and press Ctrl+S the document is automatically saved in the server. So, what is the difference?
If you want that, you have to convince the application author to use libkio. We cannot do that on our own. There are several small differences and incompatibilities that don't work with a program waiting for the file to be saved. For instance, the Save As dialog. Another is the name on the title bar. So, no, the dialog box will not go away. At most, we can annoy the user by asking if he wants to upload, every time he saves.
There are two different behaviors when managing remote files with kioslaves: using KDE apps and non-KDE apps, and this issue is annoying for common users that don't know about kioslaves or KDE and non-KDE apps. Two behaviors: 1) Open a kio remote document with Kword, so when the user presses Ctrl+S the file is AUTOMATICALLY uploaded to the server. There are no annoying pop-ups and the user doesn't need to close Kword to update the file in the server. 2) Open a kio remote document with OpenOffice, so the title bar is the name of the local temp file. When the user presses Ctrl+S only the local copy is saved and when closed OpenOffice there appear a pop-up asking to upload the file to the server. My suggestion is just to minimize the difference between those two behaviors. Note that using KDE apps the user is not asked with a pop-up when he presses Ctrl+S. So, my suggestion is to modify the second behavior and set it as follows: 2-b) Open a kio remote document with OpenOffice, so the title bar is the name of the local temp file. When the user presses Ctrl+S the file is automatically uploaded to the server (as when using Kword!), and when he closed OpenOffice there doesn't appear a pop-up (as when using Kword!). In this way the two behaviors are more similar so this way could be more easy for the users. Of course I know the the issues of the kisolaves and non-KDE apps (like the title bar and the "Save as..."), but those issues occur the same in 2) and 2-b) modes. So, why is a bad idea the 2-b) suggestion?
Because of general incompatibilities. For instance, propagating the information that the source was read-only is difficult. If you open an HTTP file on a non-KDE application, you'll get a local temporary file, which the application may decide to write to (even if we make it read-only). Then KIO cannot upload it to the server and we have no easy way of telling the user of that. At the same time, users may be already expecting that opening a remote file creates a local copy, so they save to the temporary file. They would be surprised if suddenly the remote copy started to be modified. Finally, saving in the background may not be a good idea. In a normal KDE application, saving to a remote file may be a slow operation and the user will get a progress dialog blocking the UI while the operation is happening. There's no way to do that in a non-KDE application, which means that the user doesn't get feedback for the operation. So, in a few words, if apps want to get the full power of KIO, they should link to libkio.
> ------- Additional Comments From thiago kde org 2006-04-18 03:28 ------- > At the same time, users may be already expecting that opening a remote file > creates a local copy, so they save to the temporary file. They would be > surprised if suddenly the remote copy started to be modified. I'm not sure of that. I think many people using Windows is used to open and modify files in the server using SMB/CIFS protocol. They just must open "Network sites" for a transparent acces to remote files. When they do this they don't expect to manage a local copy. I don't know is all the Windows applicaitions understand and support the SMB resources \\netbios or \\host URL's), or maybe Windows really mounts these remote resources and provide transparent acces for all the apps. > Finally, saving in the background may not be a good idea. In a normal KDE > application, saving to a remote file may be a slow operation and the user > will get a progress dialog blocking the UI while the operation is > happening. There's no way to do that in a non-KDE application, which means > that the user doesn't get feedback for the operation. Ok, I really thank you for this explanation that has convinced me. ;) > So, in a few words, if apps want to get the full power of KIO, they should > link to libkio. Or use a system with FUSE :) Thanks again for your explanations.
Also note that I did not close your wish report because, although I don't agree with your suggestion (and I have many arguments against implementing it), I am not the one to make the decision to not implement this.
FYI, gnome is switching to gvfs (a new framework based on fuse) : http://live.gnome.org/GioPort. I've been using it for a few days and it's quite confortable to be able to access you remote files from any app, including the command-line, whether it's a KDE, GtK, whatever app... I've read the original thread and this bug report. My personal opinion is that KDE is missing an important step in Linux evolution if not supporting FUSE. Just think that all KIO slaves code could be used to improve fuse modules and make the situation better on every desktop. I've never understood why so critical system things such as "mount/unmount" operations were handled by the desktop : the kernel should handle this, not the desktop. If other os'es than linux don't support mechanism such as fuse, then it's a limitation of these OS and I don't understand why KDE should carry such a burden.
Note that another choice would be to have a separate program handling fuse mounts and unmounts, a bit like smb4k. I tried to start the discussion on smb4k mailing list a while ago (but didn't get many answers) : https://lists.berlios.de/pipermail/smb4k-general/2007-September/000259.html
*** This bug has been marked as a duplicate of bug 75324 ***
*** This bug has been marked as a duplicate of bug 40115 ***