On segunda-feira, 14 de maio de 2012 18.29.23, Thiago Macieira wrote:
> == Proposal 2 =>
> So instead of adding decodedPath(), decodedUserName(), decodedPassword(),
> etc. and cluttering the Qt5 QUrl API like the Qt4 one was, there's a
> separate proposal:
>
> - add an option to QUrl::ComponentFor
; From: development-bounces+shane.kearns=accenture@qt-project.org
> [mailto:development-bounces+shane.kearns=accenture@qt-project.org]
> On Behalf Of Thiago Macieira
> Sent: 14 May 2012 17:29
> To: development@qt-project.org
> Subject: [Development] QUrl fully-decoded path API
&g
Hi Thiago,
reading through the whole thread, I am leaning towards proposal 2. It
might be slightly more difficult to document, but has less API clutter and
is probably easier for us to maintain in the longer term.
Cheers,
Lars
On 5/14/12 6:29 PM, "ext Thiago Macieira"
wrote:
>Hello
>
>David an
Hello
David and I have been discussing for the past week one of the consequences of
QUrl operating on encoded data only in Qt 5. There are a few use-cases where a
fully-decoded path is necessary.
== Rationale =(skip to proposal if you find this lengthy)
I've already had to implement the full dec
