QUrl in KDE 4

[Andreas Aardal Hanssen]

Some more stuff here..

On Thursday 19 May 2005 22:38, Thiago Macieira wrote:
> >> - convert a hostname back from ACE automatically (fromPunycode is
> >> never called)
> >That's a bug; I've made a task of it. Of course QUrl should call
> >fromPunycode :-).
> Good. Just make sure we can get both "forms" of the URL: the presentation
> form (ToUnicode) and the internal form (ToASCII). Currently
> KURL::prettyURL also converts %20 into spaces, and the printable high
> characters are decoded.

QUrl has a QString and a QByteArray representation. You will probably see from
 the API that you can basically encode or decode whatever you like. The 
default encoding is the minimal encoding necessary.

> By the way, the "proper" names for the IDNA transformation are ToUnicode
> and ToASCII. Punycode is a Unicode encoding, just like UTF-7, UTF-8,
> UTF-16 or UCS-4. Punycode would probably be better named if it were a
> QTextCodec (I'm not sure if it's been assigned a MIB number).

We would never call the punycode functions ToASCII and ToUnicode; we don't 
require people to read the IDNA RFCs to understand the signature. Besides, 
those names completely clash with the rest of the API.

> >>> Apparently, QUrl accepts file:/path URLs (no ///)
> >I don't understand this. Both file:/path and file:///path are allowed
> >according to the spec.
> Which one does it generate? The other-desktop developers will yell at us
> if we start generating file:/path URLs again.

Just have them use QUrl. The path() function always returns /path anyway.

> >The spec says nothing about what comes after mailto:. So you are free to
> >call toPunyCode() and fromPunyCode() when generating mailto urls.
> True. mailto: isn't a URL, so QUrl doesn't have to handle it.

But it does. :-)

Andreas

-- 
Andreas Aardal Hanssen - andreas . hanssen @ trolltech.com
Trolltech AS - Waldemar Thranes gt. 98, NO-0175 Oslo, Norway