[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    QUrl in KDE 4
From:       Zack Rusin <zack () kde ! org>
Date:       2005-05-19 19:23:15
Message-ID: 200505191523.16154.zack () kde ! org
[Download RAW message or body]

Hey,

as was pointed out a while ago, one of the reasons QUrl was rewritten
was that it was supposed to replace KURL in KDE 4.

I wanted to provoke people to voice their concerns/bugs/opinions so that
we can incorporate them in QUrl and make sure it's perfect for KDE.

We already got some comments from Thiago and others which Andreas
answered in detail. Below you'll see the questions/comments and
answers.

Is there anything else? As Andreas said, if anything needs to be
changed, it's all open for discussion. :-)

"
> QUrl cannot:
> - deal with the file part of the URL path (except in Qt3 support mode)

Use QFileInfo on path(). The URI spec does not cover files.

> - 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 :-).

> - handle URL-looking non-URLs (example: ed2k://|file|
Ugly_looking[file]name|343928602|00000000000000000000000000000000|/)

QUrl follows the URI specification in this respect. QUrl does the right
thing in rejecting it. If KUrl accepted this stuff, then that's really
bad.

> QUrl has a strict parser
>> Apparently, QUrl accepts file:/path URLs (no ///)

I don't understand this. Both file:/path and file:///path are allowed
according to the spec.

> Docs have to make it clear which methods accept parsed and which
> accept raw inputs. For instance, setAuthority/setHost seem not to
> accept Unicode (non-ACE) form of hostnames.

This is the same bug as before.

> Warning: Verify that the extra folding mandated by IDNA is done! It
> does QUnicodeTables::normalize(labels.at(i),
> QString::NormalizationForm_KC, QChar::Unicode_3_1), but IDNA requires
> more than NFKC.

If so, then this has changed in the specification. If we do not do
exaclty what the spec does, then this is a bug.

> KURL can:
> - get/set all parts of the URL: protocol, user, password, host, port,
> path & file, (html) ref, query

Just to make things clear about this point; the URI spec does not cover
the specification of a file path, and the heuristics in KURL are
horrible and slow down the parser. QFileInfo has this as its major
responsibility.

> - manipulate the special query "charset" (called fileEncoding)

This _can_ be added to QUrl, but will probably not be.

> - manipulate the URL by doing chdir (cd)

Use QDir::cdUp().

> - convert non-ASCII hostnames to IDN, including in mailto: URIs

The spec says nothing about what comes after mailto:. So you are free to
call toPunyCode() and fromPunyCode() when generating mailto urls.

> - handle file names on Windows (i.e., convert drives to URL form)
> (when built on Windows)

Use QUrl::toLocalFile().

> - deal with "sub-URLs", which are hardcoded. See
> http://bugs.kde.org/show_bug.cgi?id=73821 

Suburls should be are gone in KDE 4, you can talk to David Faure about
this. We already agreed on this point. Suburls break the URI
specification, and are practically unused and totally confusing.

Andreas
"

--
This email brought to you by the language "C" and the number 2^32
[prev in list] [next in list] [prev in thread] [next in thread]