Version: 4.4.0 (using KDE 4.4.3) OS: Linux Regularly I copy file names with their path by copying the file in konqueror file manager and I paste them in Kwrite. The annoying thing is that it always has a prefix like "file://", e.g. file:///usr/share/apps/katepart/syntax. Every time I have to remove the "file://" part because I don't need that info in my text. Gnome nautilus does it right without "file://". Another plus that Gnome has over KDE. Please fix this. Reproducible: Always
It looks correct: if you are browsing a filesystem the clipboard contains the complete URI, try to think if you are copying a remote file. IMHO the gnome implementation is not coherent. P.S: How altering the URI removing the substring "file:///" could affect the windows versione
No, it's not correct. The correct would be to copy the full thing, but, in paste to remove it. I know it's not possible, but, full URI for local storages? And, more importantly, it is an "expected" behavior to copy/paste the filename part only. The "file://" should be set automatically by applications, or power users that really need it. Another suggestion is to copy 2 versions. One without the URI and a second one with it. Users that really need the URI could use klipper to paste the correct string
Please please fix this! FiNeX said this feature makes KDE file manager more "coherent" than gnome. But what benefits does this coherency give to us? I haven't seen any. In contrast, this feature has many drawbacks. First, "file://" URIs are hardly useful on earth. I haven't seen a single software rely on "file://" URI to work. Can anybody name one? You can input an absolute path like "/home/myname" into a web browser's location bar(which expects an URL) and it will happily show the directory. Second, many softwares chokes with "file://" URI, especially traditional command line tools. Can you execute cd, ls, cat, find, tar... on a "file://" URI ? Of cause not! Should these tools be fixed? I don't think so. "file:///abc" may also be interpreted as a relative path -- a file "abc" under a directory "file:" ! How do these tools choose? Third, URI requires non-English characters being escaped, which makes these characters not human-readable. example: file:///home/duanyao/%E8%B5%84%E6%BA%90/%E4%B8%AA%E4%BA%BA%E4%BF%A1%E6%81%AF.txt For English-only URI, you can simply remove the "file://" prefix to get the path back; but if the URI contains non-English characters, you are out of luck! PS, I am Chinese.
A similar and related bug have been fixed long ago: Bug 170608 - copy location in dolphin should return regular path not file:// http://bugs.kde.org/show_bug.cgi?id=170608 Why this bug can't be fixed?
Resetting assignee to default as per bug #305719
(In reply to Duan Yao from comment #4) > A similar and related bug have been fixed long ago: > > Bug 170608 - copy location in dolphin should return regular path not file:// > http://bugs.kde.org/show_bug.cgi?id=170608 > > Why this bug can't be fixed? Because it's not a bug and "fixing" it would break features. Copy/paste within Dolphin would not work anymore. Also, Plasma's clipboard applet nowadays recognizes file:// URLs and shows additional actions on them (e.g. the "Open with"-like menu).
(In reply to Elvis Angelaccio from comment #6) > (In reply to Duan Yao from comment #4) > > A similar and related bug have been fixed long ago: > > > > Bug 170608 - copy location in dolphin should return regular path not file:// > > http://bugs.kde.org/show_bug.cgi?id=170608 > > > > Why this bug can't be fixed? > > Because it's not a bug and "fixing" it would break features. Copy/paste > within Dolphin would not work anymore. Also, Plasma's clipboard applet > nowadays recognizes file:// URLs and shows additional actions on them (e.g. > the "Open with"-like menu). I don't think fixing it must break other features. Xfce fixed this problem long ago after I filed a bug ( https://bugzilla.xfce.org/show_bug.cgi?id=8271 ), and I didn't notice anything was broken. Why must it be the case for KDE? Anyway, because Xfce fixed this problem but KDE didn't, I switched to Xfce since then.
*** Bug 408813 has been marked as a duplicate of this bug. ***