Version:            (using KDE Devel)
Compiler:          GCC 3.4.4 (with visibility patch) Some kind of Slackware
OS:                Linux

Forwarding troubles...

This happens since a long time ago, but i then figured i should let some time to the media:/ ioslave to mature so that maybe those bugs would just disappear...

But now were quite close to KDE 3.5 and i think i should report what i consider nasty bugs...

Cant open compressed archives...

A. Copy a .tar.bz2 (or .tar.gz, etc.) you have to your home dir.
B. Go to system:/home (not ~)
C. When you try to open the archive, konq asks you what you would like to do, instead of just opening it inline.

D. Now go to ~
E. Open the same archive; konq will open it and show it like a normal dir. (this is the normal behavior since KDE 0.0 i think :)

Its just one example, but it happens in many other places that the system:/, media:/, etc. ioslaves are not consistent with the expected behavior.

Other examples : 
(from memory, be forgiving please if they are not perfectly exact)

Browse a cdrom with the media ioslave and try to open an image with the GIMP... gimp complains the image is not found...

Try to drag that same image to an already opened instance of the gimp... again gimp complains the image is not found.

In fact, the problem here is that any programs that dont talk kioslaves are unable to work with them (quite normal) but the behavior is quite anormal... 
How do you explain to a '"non-techie" "non-long-time-knowlegdeable-kde user"' that they cant open images with the gimp from konqueror?

Why cant the media slave simply send a user clicking on media:/hdd to the real file:///media/hdd (or /mnt/cdrom, etc.)? Isnt it aware of the mount point anyway? Cant it convert URLs on the fly? And maybe keep an internal/virtual tree in memory so that when a user clicks "up" in konq it does not go to file:///media but to media:/ 

As a side-effect it would solve the chronic problems with non-kde apps, wouldnt it?