system:// protocol

GTK apps don't support KIO slaves.

Not sure about no. 2

1 - Yes, GTK does not support KOI. But that is not a reason to start GIMP with "File not found" message. May be that's a reason to turn "system://" to a "testing" state? It adds nothing to functionality.

2 - Try to open directory with pictures with kuickshow or big movie with Kaffeine. That would be really not you expect.

I hadn't run into #2 before I tried it just now and that really shouldn't happen.
I have run into #1 several times and it's annoying. I agree that "system:/" adds no functionality and only confusion and extra work when the system tries to do something "automatically" like open files from a CD.

This is definitely confirmed, and I agree that it should not happen. I'm not sure what is the source of the problem but, for usability, #1 and #2 should not happen.

in the first case, the problem is obvious: GTK apps don't support kio-slaves.

I could not reproduce the problems stated in #2, but it seems that some KDE applications will have problems. kmplayer itself did not work, understandably, when launched in a window. When using "Preview in embedded...", it worked fine.

In all cases, the file I've tried to launch were in my home directory, so it is not a matter of the applications not being able to reach the file through an protocol unknown to them. The file is there and reachable, but the plugin does not feed the associated application an understandable path.

Update already.

http://bugs.kde.org/show_bug.cgi?id=117395

This is a bug with .deskopt of the associated application. If you change %U to %f in the launch options, it fixes most, if not all, problems.

The problem now is that if you replace %U with %f everywhere, that means the stated #2 problem will happen more since KDE will copy files to a temporary directory.

The solution would probably be to use X-KDE-Protocols more in .desktop files.

This is a bit beyond me now. I'd like to know what people more involved with KDE packages think of that.

Among other non-kde apps for which you can't open files through system:/ is openofffice.org, it just shows a splash screen and doesn't start.

>Posted by Jonathan Riddell at 2005-12-30 14:59:30 UTC
>Openoffice can't handle URLs. The %U's in the .desktop files need
>changing to %F's. Any objection to me doing
>this doko?

Any follow-up?

In the ooo-wrapper system: is now replaced by file://
the proper fix should be made in KDE

Adding "X-KDE-Protocols=http;ftp;smb;" to the end of the .desktop file, does indeed, fix the problem. Any update on whether the .desktop files for OpenOffice will be modified?

What my openoffice does now is if I go to open a file from system:/home it says the file isn't there, with the path /home/document.odt (should be /home/yuriy/document.odt)

system:/ skips /username/ in the path, and gives openoffice an incorrect/incomplete path to the file.

Kaffeine Changelog for 0.8.1:
 * fixed: system:/media urls

I haven't tried it, but I guess that's the bug here. Too bad 0.8.x won't be in dapper AFAIK.

https://launchpad.net/distros/ubuntu/+source/kdebase/+bug/39887

This bug was reported by me some hours ago. It goes into a bit more detail about other problems system:/home creates. It's now been marked as a duplicate of this bug here - maybe some of you want to check it out.

Whats happening here now? I still don't see why system:/home is there in the first place. are you now 'fixing' desktop files to work with system:/home or will system:/home finally be gone for good. Although I'm a bit upset about the troubles system:/home is giving me right now it's still probably the most absurd abstraction layer I've seen used throughout a desktop environment. What exactly is the benefit of system:/home above a normal path like /home/user ?

I totally agree. system:/home is getting in my way. I cannot open files with OOo or gimp or....

I'm all for dropping this abstraction.

I noticed in the latest kdebase changelogs the following message:

kdebase (4:3.5.2-0ubuntu7) dapper; urgency=low

  * konqueror: Put the system tab back in sidebar now that we deal with the
    kio properly.

 -- Raphaël Pinson <email address hidden> Fri, 14 Apr 2006 00:59:01 +0200

So, if this is true, why are programs still having trouble dealing with the kio-slave? Are the .desktop files being updated, or are the maintainers for affected packages not allowing the changes? I'm curious.

Looks like it has been fixed for openoffice and kaffeine, and the home link now redirects to /home/username/
It's kind of a dirty workaround IMO (well, only if you want to use system:/ in the first place, otherwise I think it's good to go to the real home directory), and you can still go to the messed up system:/home, but it's some kind of solution for dapper.

GTK apps still don't open files right from system:/

Yuriy: The .desktop files for GTK and other non-KDE apps have to be patched to work with the system:/ kio. I've noticed that the most recent OpenOffice packages have been patched for this, it's just a matter of getting the other major non-KDE packages to patch it as well.

I applaud the Kubuntu team for it's work in getting most of the kinks of the system:/ kio-slave fixed. Hell, even Amarok works with files in a system:/ location now.

Fixed as far as possible (without changing the .desktop files for every non-KDE app.