Bug 125458 - Improve KIOSLAVES for non-KDE apps
Summary: Improve KIOSLAVES for non-KDE apps
Status: RESOLVED DUPLICATE of bug 40115
Alias: None
Product: kio
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-13 00:17 UTC by Iñaki Baz Castillo
Modified: 2018-04-23 20:01 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Iñaki Baz Castillo 2006-04-13 00:17:54 UTC
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?
Comment 1 Thiago Macieira 2006-04-14 20:05:24 UTC
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?
Comment 2 Iñaki Baz Castillo 2006-04-17 18:39:18 UTC
> ------- 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?
Comment 3 Thiago Macieira 2006-04-17 22:15:28 UTC
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.
Comment 4 Iñaki Baz Castillo 2006-04-17 22:57:28 UTC
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?
Comment 5 Thiago Macieira 2006-04-18 03:28:27 UTC
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.
Comment 6 Iñaki Baz Castillo 2006-04-18 15:49:33 UTC
> ------- 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.
Comment 7 Thiago Macieira 2006-04-18 19:03:28 UTC
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.
Comment 8 Vincent Panel 2008-05-06 09:02:19 UTC
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.
Comment 9 Vincent Panel 2008-05-06 09:18:33 UTC
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
Comment 10 Nate Graham 2018-04-16 22:12:00 UTC

*** This bug has been marked as a duplicate of bug 75324 ***
Comment 11 Nate Graham 2018-04-23 20:01:41 UTC

*** This bug has been marked as a duplicate of bug 40115 ***