QUrl in KDE 4
faure at kde.org
Fri May 20 09:15:27 BST 2005
Thanks Thiago for pointing out the obvious: we need something that handles mailto:
type of links without any fuss (no complex class hierarchy), like KURL did.
On Friday 20 May 2005 09:28, Martijn Klingens wrote:
> > I, for one, wouldn't miss ed2k if it were completely dumped and regarded
> > as invalid (because it is). Users would not agree with me, nor would many
> > developers.
> Can ed2k can be converted to a proper URI by using URI filters? Or does
> the URI filter code already expect valid URI syntax to begin with?
URI filters are applied when *typing* a UR[LI], not when clicking on one.
Imagine if webpages started using <a href="gg:foo"> :)
> As for supporting them, people should be able to click on them, since like
> you said, that's what they expect. If it can be handled outside [QK]URL
> that doesn't really matter for the user, as long as it works.
Sure, but how would it work? What do you use instead of openURLRequest(const KURL&)
if the url can be a QUrl or a QString/KPseudoURL? This is all unnecessary messy for nothing.
The next step in this discussion is for someone to port kurltest to QUrl,
without removing any test except sub-urls. Then we can see what's missing.
(No time to do this myself for the next 2 weeks, but I'll do it afterwards if
nobody did before).
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel