[Development] New QUrl implementation

[David Faure]

On Wednesday 28 December 2011 16:43:10 David Faure wrote:
> On Tuesday 27 December 2011 12:24:23 Thiago Macieira wrote:
> > On Tuesday, 27 de December de 2011 13.42.10, David Faure wrote:
> > > On Friday 23 December 2011 17:22:38 Thiago Macieira wrote:
> > > > QUrl: Always lowercase the scheme
> > > > Change-Id: I8d467014d22384f1be15fdd746e20b1153a82a4e
> > > > 
> > > > Do we want this? I think so.
> > > 
> > > I would say yes, too. This simplifies the checks in application code.
> > > 
> > > PS: great work on QUrl!
> > > 
> > > Isn't this going to go to gerrit for review before merging? I'm
> > > surprised
> > > that this is in gitorious branches for now, but I suppose that's because
> > > topic branches don't really work there iirc.
> > 
> > I'm not allowed to submit to Gerrit. I can only publish as open source.
> 
> Hmm, so what now? How do we get this into Qt?
> 
> (I suspect that this is a touchy legal issue I probably shouldn't dig into,
> but this has a huge effect on kde frameworks 5, so I need to know if this is
> going to be solved...)

After more discussion with Thiago, it turns out that Intel still hasn't signed 
the CLA that would allow him to contribute to Qt, which is why this work is 
blocked at the moment.

It looks like this might take a while still, but we really need these changes 
into Qt. If this is delayed too much, we won't be able to get it in at all, 
after the SC freeze.

So I have a proposal to make: how about I make the API and behavior 
incompatible changes now, while there's still time, so that later on Thiago 
can still commit his work even after the api freeze?

In concrete terms, the plan would be that I change the non-encoded methods, 
like toString and the QUrl(QString) constructor, so that they work on 
partially-encoded data.
This would fix the long-standing issue that toString() is basically unusable, 
except for displaying to the user in non-editable format. If a file contains a 
'#' in the name, toString doesn't escape it, so if that string is given back 
to a QUrl, it won't be parsed correctly.
Thiago's code rewrites the whole qurl internals, but as a short-term solution 
to get the API and behavior in place, I could just drop the QString members in 
the current Private, and pass the encoded form through some "pretty decoding" 
code. This would be slower, but the behavior would be fixed, and we can make it 
faster later.

After that we can deprecate all the "encoded" methods, but that in itself 
doesn't need to be done before the freeze, does it? It's SC/BC technically, 
like any deprecation that will happen for 5.1 or later.

I would prefer not to have to do this redundant work, but it seems like a 
better solution than having to live with Qt4's QUrl for the whole life time of 
Qt 5 (which also means keeping a KDE layer on top, to fix these issues, but I 
really want to get rid of that).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5