On Monday, 2013-11-25, 00:01:41, Mark Gaiser wrote: > On Sun, Nov 24, 2013 at 10:09 PM, Albert Astals Cid <aa...@kde.org> wrote:
> > Why? If you open a huge file by smb:// it'll copy it to the local file > > anyway, so why should not we copy it? > > Right. True but should it be like that? > Lets take playing a movie from smb as an example. If you do that now > in for example mplayer then kde will simply copy the movie to your > local drive and start playing it. But should that be the case? I > consider it a massive usability bug. One that isn't easy to fix. If > you would mount the same share as cifs then the system "thinks" it's > local and just plays the movie without copying. This is more likely a problem with mplayer's .desktop file. KIO usually hands over the URL when starting the program, unless the information it has about the program suggests that the program is not capable of handling the URL itself. To still be able to call the program KIO then first downloads the file and then calls the program using the temporary file as the program's argument. > That is how it should be. Copying to your local system is a nasty > workaround which should imho be prevented. I think it is also a difference how this is handled. I.e. if the file is downloaded first and then read locally, then there will be a significant delay between starting the "open" operation and content becoming available to the user. However, it might also be possible to consume received data right away and, additonally, save it to a local cache file in case the program needs to "go back". Depending on cache policy that would even allow use cases like quickly opening a file again if the viewer had been closed accidentally. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
