On 1/23/12 6:47 PM, "ext David Faure" <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
