[Development] New QUrl implementation

[lars.knoll at nokia.com]

On 1/23/12 6:47 PM, "ext David Faure" <faure at kde.org> wrote:

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

Sounds ok to me, even though I hate seeing the duplicated work happen.

Lars