Review Request: in KUrlCompletion do not percent encode to make it human readable

[Martin Koller]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106096/
-----------------------------------------------------------

(Updated Aug. 24, 2012, 4:01 p.m.)


Review request for kdelibs, David Faure and Thiago Macieira.


Changes
-------

according to Davids comment I changed the patch now so that instead of using QUrl::toPercentEncoding() I'm using now
KUrl::prettyUrl() to only encode the necessary characters and have the rest human readable.


Description
-------

when using konqueror and typing "man:" it starts to list possible entries which the kio_man slave generates.
However, konqueror displays percent encoded URLs, e.g. "man:%281%29/" instead of "man:(1)/", which is not human readable.
Also, there is some inconsistency in what konqueror shows in its completion list.
E.g. when typing "man:mklos" it shows "man:mklost%2Bfound" in the completion list,
but when I select this entry, the URL in the address line edit is changed and displays as
"man:mklost+found"
Even worse: when I now again type "man:mklos", I get 2 entries in the completion list
"man:mklost%2Bfound" and "man:mklost+found" (the one coming from the completion, the other from the history)
No matter which one I chose, the result in the address line edit is always the unencoded one, which - for a user - makes much more sense.

This patch removes the calls to make the matches percent encoded.
Why would I ever want to get a percent encoded string from a completer, which is about helping a human ?


This addresses bug 141157.
    http://bugs.kde.org/show_bug.cgi?id=141157


Diffs (updated)
-----

  kio/kio/kurlcompletion.cpp 269fdc1 

Diff: http://git.reviewboard.kde.org/r/106096/diff/


Testing (updated)
-------

man:, fish:, local dir /tmp and checking the completion in konqueror when using a dir e.g. named "some ö ä ü umlauts", "some file with#anchor" (this is a file literally named like this).
Tested also the case mentioned in bug #141157 with the zip ioslave


Thanks,

Martin Koller

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120824/305b4a3c/attachment.htm>