Bug in KURL handling(?)

[Ingo Klöcker]

On Wednesday 15 December 2004 10:06, David Faure wrote:
> On Tuesday 14 December 2004 13:31, Thiago Macieira wrote:
> > The current behaviour is not acceptable, in which it displays # in
> > the Location bar both for anchors and for %23.
>
> This is not true - the location bar shows %23 for %23 (e.g. for a '#'
> in a path).
>
> The confusion in this thread seems to come from the assumption that,
> in konq's locationbar, "when it starts with a slash it is a path" -
> it is not so, it is still a URL, just without file:// in front.

And that's probably the real problem. I'm 100% sure that my parents 
wouldn't identify a%23b (shown in the location bar) with the file 
called a#b. This is extremely confusing.

> And for this reason I don't see a reason for Ingo's patch to be
> applied. 

FWIW, I just tried to following (Reminder: I'm using KDE_3_3_BRANCH): I 
created a file called 'a#b' in $HOME. Then I opened Konqueror and 
started to type "~/a" into the location bar. The auto-completion offers 
~/a#b. I select it and press Enter. "The file or folder ~/a#b does not 
exist."
Huh? WTF? First Konqueror offers me the file via auto-completion and 
then it tells me the file doesn't exist? (Deja-vu? I have the uncertain 
feeling that I already brought exactly this example before.)

IMO this whole situation is completely broken. A path which is entered 
in Konqueror should be interpreted as path. Interpreting it as file URL 
with omitted "file://" is just wrong. No user will understand that he 
has to enter "~/a%23b" to open the file ~/a#b (even if auto-completion 
is fixed so that it offers ~/a%23b instead of ~/a#b).

The only sensible solution for this whole usability mess is that 
anything without protocol is interpreted as path. And, of course, file 
URLs which are not just simple path must not be crippled because 
otherwise Konqueror won't understand them anymore correctly.

Somehow this reminds me of the special handling of IDNs, with the 
difference that for IDNs it's done correctly (i.e. the user never has 
to enter xn--foo as domain name) while for path it's done wrongly 
(because the user has to know the hex code of '#').

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041215/5cf8d03d/attachment.sig>