Bug 125458

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 ***