From kde-core-devel  Wed Aug 15 19:01:57 2012
From: Martin Koller <kollix () aon ! at>
Date: Wed, 15 Aug 2012 19:01:57 +0000
To: kde-core-devel
Subject: Re: KIO::UDSEntry and URL encoding
Message-Id: <201208152102.02933.kollix () aon ! at>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=134505764027817
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart3038380.Oj9XSSHoUW"

--nextPart3038380.Oj9XSSHoUW
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Monday, 13. August 2012 16:03:48 Thiago Macieira wrote:
> On segunda-feira, 13 de agosto de 2012 14.28.02, Martin Koller wrote:
> > Hi,
> > (using 4.9.0)
> >=20
> > when using konqueror and typing "man:" it starts to list possible entri=
es
> > which the kio_man slave generates. However, konqueror displays percent
> > encoded URLs, e.g. "man:%281%29/" instead of "man:(1)/" kio_man creates=
 the
> > KIO::UDSEntry as follows:
> >=20
> >             QString name =3D "man:/(" + *it + ')';
> >             uds_entry.insert( KIO::UDSEntry::UDS_NAME, sectionName( *it=
 ) );
> > uds_entry.insert( KIO::UDSEntry::UDS_URL, name );
> >=20
> > (sectionName(...) delivers a human readable text)
> >=20
> > What I do not find in the KIO::UDSEntry documentation is if the URL sho=
uld
> > use percent encoded strings or not. However doing a simple test where I
> > explicitely use QString name =3D "man:/%28" + *it + "%29"; does not work
> > either.
>=20
> That's not a decision of UDSEntry. That's a decision of who's displaying =
the=20
> URL.
>=20
> The two URLs are equivalent, so there's nothing wrong with the encoding. =
It's=20
> just a matter of whether konqueror decides to decode the parentheses.
>=20
> > Is this a general problem in konqueror (or the combobox it uses or I do=
n't
> > know where in kdelibs) or do I have to change something in kio_man ?
>=20
> It's not a problem. The behaviour you're describing is "general" though.

Well, it's a problem for the user.

I found out that the culprit is KUrlCompletion, which - for whatever reason=
 -
uses QUrl::toPercentEncoding() when an URL is to be shown.
I also found out that Qt seems to have a "bug" (in quotes because as you sa=
id percent encoding
is equivalent to unecoded chars): QUrl::toPercentEncoding() defines unreser=
ved chars as:
Unreserved is defined as: ALPHA / DIGIT / "-" / "." / "_" / "~"
but rfc2396 defines this set as:=20
unreserved  =3D alphanum | mark
mark        =3D "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"

I'd like to fix the problem in KUrlCompletion and tried to simply add an ad=
ditional
exclude array of "()!*'", which at least makes man:(1)/ etc. URLs human rea=
dable.

However, I see that there is still some inconsistency in what konqueror sho=
ws 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 a=
nd displays as
"man:mklost+found"
Even worse: when I now again type "man:mklos", I get 2 entries in the compl=
etion list
"man:mklost%2Bfound" and "man:mklost+found" (the one coming from the comple=
tion, the other from the history)
No matter which one I chose, the result in the address line edit is always =
the unencoded one, which
=2D for a user - makes much more sense.

So my main question is: would it hurt anyone to simply completely get rid o=
f QUrl::toPercentEncoding()
in the KUrlCompletion implementation ?
Why would I ever want to get a percent encoded string from a completer, whi=
ch is about helping a human ?

=2D-=20
Best regards/Sch=F6ne Gr=FC=DFe

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail=20
/\  www.asciiribbon.org   - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at

--nextPart3038380.Oj9XSSHoUW
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iD8DBQBQK/IqHmdPoI37D4YRAoBuAKDP9WUACDJ8kf/NiHEVIeBZNX3PWgCg0XTF
8BhY88YZuU5SFy3z5JTIpPA=
=VXRo
-----END PGP SIGNATURE-----

--nextPart3038380.Oj9XSSHoUW--