Bug 117524 - system:/ kio-slave in KDE 3.5 needs some work
Summary: system:/ kio-slave in KDE 3.5 needs some work
Status: RESOLVED INTENTIONAL
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: system (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Kevin Ottens
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-02 18:42 UTC by Daniel Frein
Modified: 2007-07-16 10:21 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Frein 2005-12-02 18:42:35 UTC
Version:            (using KDE KDE 3.5.0)
Installed from:    Ubuntu Packages

FAM is not used: konqueror doesn't update if directory is changed. similar other apps like kate are unable to detect changes in files or directories if system:/home/ is used (I am using gamin in ubuntu)<p>
<p>
moving of files/folders in paths like system:/home (on the same hd partition) results in slow copying instead of a quick mv<p>
<p>
'info list' view of directories in konqueror not working; only the filename is shown<p>
<p>
some apps like kate and kedit are losing file permissions after saving files (in my case all permissions are set to 0644 on saving). But I'm not sure if this is kio_systems fault.
Comment 1 Christophe Dumez 2005-12-11 20:21:52 UTC
I agree, and when I try to play a video in "system:/home/" it has to copy the whole video into "file:///tmp/kde-chris/" before opening the video with kaffeine. It is very slow and I hope this is not the correct behaviour :)
Comment 2 Fabio Erculiani 2005-12-13 15:32:35 UTC
I agree!
KIO Slaves in KDE 3.5.0 seem incomplete and broken!!

In KDE 3.4.x they were a lot more usable.

PLEASE FIX THAT !!!
Comment 3 Fabio Erculiani 2006-01-17 20:07:22 UTC
Still nothing...?
Comment 4 Doncho N. Gunchev 2006-01-26 11:33:51 UTC
*** This bug has been confirmed by popular vote. ***
Comment 5 Doncho N. Gunchev 2006-01-26 11:40:44 UTC
Furthermore when trying to edit file permissions (properties) on system:/home I can't see any ACL related setting, "Meta Info" and "Share" tabs. Same with system:/users/me and any other.
Comment 6 Altmenorg 2006-03-07 10:31:07 UTC
Confirmed, and I totally agree too.
Apart from giving a nice rendering in the address bar (homogenous system:/foo thing), nothing is really improved, and more than that, lots of issues are added.
The old way to work, while system:/ was linking to £HOME instead of system:/home was way better, and bugfree...
Comment 7 Achim Bohnet 2006-03-07 10:40:30 UTC
Similar problems with media:  Lots of apps can't handle this and need
special treatment just to file out there the file is on the local
FS :(

Achim
Comment 8 Yuriy Kozlov 2006-03-20 23:19:07 UTC
Some more problems:
from https://launchpad.net/distros/ubuntu/+source/kdebase/+bug/32159/

"1 - system:// protocol can not be undertand by GTK apps at all. If you "Opern with" GIMP system://home/file.png any image you will see "no such file" error.

2 - it can not be understand corrently with KDE apps too. If you will enter folder with many picture you would be able to open just one and will not be able to scroll to next image. It will also be hard to open large AVI movie, because KDE will copy it first to /tmp which is redundant and long to wait."
Comment 9 Stefan Monov 2006-03-21 10:08:00 UTC
Re: comment #8
1. KIO is a technology specific to KDE, and therefore no GTK app can support it.
Comment 10 Daniel Frein 2006-03-21 10:33:15 UTC
Re: comment #8
indeed, KIO works only in KDE. But it is one of the goals of KDE to work with other applications as well as with native ones. And there are methods which can translate KIO-specific URLs to generic ones or absolute paths, if possible and necessary. And within the local file system this translation should always be possible, just the integration is missing. konqueror just has to check if an application is a KDE-one or not, and in doubt only pass the translated URL to the application. Nobody requests the impossible, but all of the mentioned 'little' problems could/should be solved within the KDE-3.5 series, which will last at least one more year. 
there are places were users will hit by chance upon the "system:/" URLs, and if once inside, they will stay in this hierarchy, just discovering that nothing is working as it used to be. and for the normal user the source of the problems as well as the internal difference between "file:/" and "system:/" is not obvious.
Comment 11 Janet 2006-03-23 02:05:29 UTC
Please also look at:
Bug 123783   settings:/ is missing in system:/
Bug 123784   it is not possible to access / from system:/ anymore
Bug 123786   since KDE 3.5(.1) it isn't possible anymore to have a picture/sound preview in directories accessed through system:/
Bug 124110   kio system wish: user shall be able to decide and choose which modules are shown in system:/

Comment 12 Nicolas Dumoulin 2006-03-27 15:58:54 UTC
This one is related too :
#117516
Comment 13 Janet 2006-05-19 21:16:57 UTC
KDE's new device hotplug technology opens the content of a camera with the kioslave system:/. That prevents the user from scrolling through the pictures on the camera (with *KDE* programs like kuickshow and gwenview) because the current picture is being copied to the tmp-directory. Instead you now scroll through pictures in your tmp-directory... :( Therefore the whole device dialog is unusable for all you can do when you want to work with the files on your usb device is hitting cancel, do nothing - and then open the "system folder" (which confusingly does *not* use system:/ as its name says) of it via the context menu. When I look at the content of a cdrom (and I have many picture CDs), browsing through them with the standard KDE picture viewers also is not possible.

And those kioslaves should not cover real addresses. Looking at the content of a cdrom with konqueror (via the automatic "hello, I have found a cdrom" dialog) the address shown in the address bar of konqueror is system:/media/hdc/ - when I open a konsole (F4) I end up in /media/cdrom0 - that's confusing. So I have two different addresses for one place. And if I don't open a terminal but just want to have the real folder to browse the files I cannot just delete the system:/ in the address bar because the folder is *not* /media/hdc but (what I don't know without opening a terminal) /media/cdrom0. To make it even more confusing erasing the system:/ part in the address bar works using a usb stick (system:/media/sda1 is /media/sda1).

Even more confusing (and usuable) is the terminal emulator of konqueror. Instead of following the behaviour of the terminal it (opened in a kioslave directory) does *not* show the current directory but always opens in my home directory.  

The usage of system:/ really messes up simple working processes and unnecessarily consumes a lot of internal bandwidth (cpu, memory, hard disk space).

At least it would be nice if those system:/ addresses were redirected to real addresses if the target program is a non-KDE program like e.g. the very common Gimp and if action is required to more than one file (e.g. viewing pictures with gwenview/kuickshow). And the automatic media dialog should also offer a "open system folder" to bypass the system:/ kioslave to enable browsing  through files with a picture viewer (no copying to tmp directories please). Or maybe someone has managed to add an option like that to device dialog and can tell me? 
Comment 14 Fabio Erculiani 2006-05-30 17:34:26 UTC
You can workaround that by enabling the preview of media kio-slave files under the konqueror configuration.
Comment 15 Stefan Monov 2007-07-16 10:21:09 UTC
system:/ no longer exists - see http://commit-digest.org/issues/2007-07-08/moreinfo/684518
closing.