QUrl in KDE 4
frans.englich at telia.com
Thu May 19 21:56:23 BST 2005
On Thursday 19 May 2005 19:23, Zack Rusin wrote:
> 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
> Is there anything else? As Andreas said, if anything needs to be
> changed, it's all open for discussion. :-)
Sometime back KURL was discussed, and one issue being discussed was whether it
should be splitted into KURI & KURL in order to handle the more generic type
URIs; possible for speed reasons.
How does QUrl handle URIs? Is there anything particular to say?
From what I can tell it should be just fine, although APIs looks really ugly
when a function has as return value KURL/Qurl when it actually is a URI..
How would the performance impact be if QUrl was splitted into QUri and
Qurl(inheriting QUri)? E.g, constructing time for the two, memory footprint,
and performance of the various functions of them both.
I wouldn't mind a very light and simple(basically decoding/encoding) QUri
class, because URIs are becoming more central in software design and there's
multiple RFCs in development for URI schemes, IMHO. For example, if one wants
to implement a class with semantics specific for a URI scheme one doesn't
want to inherit from QUrl(which has irrelevant and exsessive functionality),
Also, on the topic of IRIs, QUrl handle that nice, I presume.
More information about the kde-core-devel