Version: 4:4.0.83-0ubuntu1~hardy3 (4.1beta2) (using KDE 4.0.83) Installed from: Ubuntu Packages OS: Linux I posted this bug at https://bugs.edge.launchpad.net/ubuntu/+source/kdesdk-kde4/+bug/193071 and was asked to report it here. This issue is still present in 4:4.0.83-0ubuntu1~hardy3(4.1beta2), and I've been able to reproduce it every time. I don't use the mouse in any of these steps. NOTE: because some of the steps contain quotes, I will use () to indicate what is literally on the screen or to be typed in. 1. Open kate 2. press Ctrl+O to bring up the open dialog. At this point the Location box just has a blinking cursor 3. type (/etc/apt/sources.list) and press enter 4. press Ctrl+O to bring up the open dialog. at this point the location box says ("sources.list") with a blinking cursor at the end. 5. Close the dialog and close kate. I have mine set to save my session, so when I reopen sources.list will be open. 6. Reopen kate, and press Ctrl+O. This time you will see (sources.list) and the whole file name is selected so you can type over it. 7. type (/etc/bash.bashrc) over top of (sources.list) 8. When you press Ctrl+O to reopen the dialog you'll find that location is now ("bash.bashrc") Being a programmer that uses kate all day with many files, every time I go to open a file I have to stop and look at my location to see if it has quotes, if it opens with quotes I need to backspace (many times) to remove the name before typing my path or press Shift+Home and type over it.
I cannot reproduce the step 8 using current trunk. Each time I open the "open file" dialog, if I've previously opened a file, it show me the file name and the caret is at the end. Anyway it seems that the "open file" is under development because when I start to type a path with "/" the line input is a mess: it appears "file:///" and is quite unusable.
The quotes problem should be fixed by some days ago on trunk. However, I can also reproduce what FiNeX says, about the / => file:///. The quotes problem was fixed by myself some days ago, so in any case, please report the / => file:/// in a separate bug report. I will have a look at it anyway.