Thiago Macieira wrote:
> I won't de-inline the encodeName and decodeName functions. I have no interest
> in changing them.
I'm fine with leaving them as they are, if you think it is too much hassle
(compatibility issues and such) to remove altogether. I don't think they are
the solution to the
On sexta-feira, 8 de junho de 2012 13.00.05, João Abecasis wrote:
> A file whose name starts with "file:///" could still be fully understood by
> prefixing it with "./". This is not very different from what a user needs
> to do to ensure a file name is not confused with a command line option
> (whe
Thiago Macieira wrote:
> On sexta-feira, 8 de junho de 2012 10.44.37, João Abecasis wrote:
>> I actually think a satisfactory solution would be to add limited support for
>> "file://" local path URLs, where percent encoding would be fully supported
>> as per URL rules. This would only support absol
Thiago Macieira wrote:
>> the lesser evil is imo assuming correct locale encoding when actually
>> interpreting external input, being consistent within the qt realm when
>> dealing with i/o functions, and having functions for 8-bit pass-through
>> when dealing with external things which are just pa
On sexta-feira, 8 de junho de 2012 10.44.37, João Abecasis wrote:
> > Anyway, what I recommend for now:
> >
> > 1) immediately, de-inline QFile::decodeName and QFile::encodeName
> > 2) un-deprecate them and update the text in changes-5.0.0
>
> As I said before, while I think these functions support
On quinta-feira, 7 de junho de 2012 14.58.03, Oswald Buddenhagen wrote:
> > Imagine a Qt application run from the command-line with:
> > qtapp *
> >
> > In that directory there is a file name with broken encoding. The shell
> > will not recode (which is why I don't by the command-line encoding
Thiago Macieira wrote:
> On quinta-feira, 7 de junho de 2012 10.06.31, Oswald Buddenhagen wrote:
>> it's not a no-op as soon as we actually implement some escaping
>> mechanism.
>> as joao pointed out, it is all about applying the decoding and escaping
>> at the right layer - which is exactly when
Thiago Macieira wrote:
>>> Later, we can decide whether to add escaping to those functions.
>>> However, I cannot agree with bringing the setter functions back. I do
>>> agree with removing them completely, though.
Lars Knoll wrote:
> Yes. No setters for the encode/decode functions. Either we hand
Thiago Macieira wrote:
>> On the other hand we already have Qt-only paths in resource files and
>> QDir::searchPaths(). We could easily use a well-known prefix for the
>> special paths: url-encoded:/usr/joao/R%E9sum%E9.txt, which only supports
>> absolute paths, but would already enable all items i
On Thu, Jun 07, 2012 at 01:02:31PM +0200, ext Thiago Macieira wrote:
> On quinta-feira, 7 de junho de 2012 11.52.34, Oswald Buddenhagen wrote:
> > > I disagree.
> >
> > you need to provide arguments which refute my "it only makes things
> > worse" stance.
> >
> > > Maybe you'll want to revert thi
On quinta-feira, 7 de junho de 2012 11.52.34, Oswald Buddenhagen wrote:
> > I disagree.
>
> you need to provide arguments which refute my "it only makes things
> worse" stance.
>
> > Maybe you'll want to revert this then:
> > https://codereview.qt-project.org/#change,22854
>
> indeed
My argument i
On Thu, Jun 07, 2012 at 10:20:58AM +0200, ext Thiago Macieira wrote:
> On quinta-feira, 7 de junho de 2012 10.06.31, Oswald Buddenhagen wrote:
> > it's not a no-op as soon as we actually implement some escaping
> > mechanism.
> > as joao pointed out, it is all about applying the decoding and escapi
On quinta-feira, 7 de junho de 2012 10.06.31, Oswald Buddenhagen wrote:
> it's not a no-op as soon as we actually implement some escaping
> mechanism.
> as joao pointed out, it is all about applying the decoding and escaping
> at the right layer - which is exactly when using posix file i/o
> functi
On Thu, Jun 07, 2012 at 12:33:04AM +0200, ext Thiago Macieira wrote:
> On quarta-feira, 6 de junho de 2012 21.21.28, Oswald Buddenhagen wrote:
> > > 3) make QProcess use QFile::encodeName for its arguments (no-op right
> > >now) 4) make QCoreApplication parse its arguments using QFile::decodeName
On 6/6/12 9:21 PM, "ext Oswald Buddenhagen"
wrote:
>On Wed, Jun 06, 2012 at 04:51:14PM +0200, ext João Abecasis wrote:
>> Thiago Macieira wrote:
>> > So you're asking that filenames be passed on the locale encoding
>>(say, UTF-8)
>> > on the command-line, regardless of what the filesystem enco
On quarta-feira, 6 de junho de 2012 21.21.28, Oswald Buddenhagen wrote:
> > 3) make QProcess use QFile::encodeName for its arguments (no-op right
> >now) 4) make QCoreApplication parse its arguments using QFile::decodeName
> >(no-op>
> > right now)
> >
> > 5) idem for Laszlo's command-line parser
On Wed, Jun 06, 2012 at 04:51:14PM +0200, ext João Abecasis wrote:
> Thiago Macieira wrote:
> > So you're asking that filenames be passed on the locale encoding (say,
> > UTF-8)
> > on the command-line, regardless of what the filesystem encoding is?
>
> I see no other sane way, unless your appli
On quarta-feira, 6 de junho de 2012 16.51.14, João Abecasis wrote:
> > From there, we come to the conclusion that the QString representing such a
> > file name must contain special processing instructions (e.g., one or
> > more special characters). One form of special processing instruction is
> >
Thiago Macieira wrote:
> On terça-feira, 5 de junho de 2012 16.48.58, João Abecasis wrote:
>> Thiago Macieira wrote:
>>> On terça-feira, 5 de junho de 2012 13.20.36, João Abecasis wrote:
I would not go as far as saying that the concept is broken, but it
definitely isn't portable. One big
On terça-feira, 5 de junho de 2012 16.48.58, João Abecasis wrote:
> Thiago Macieira wrote:
> > On terça-feira, 5 de junho de 2012 13.20.36, João Abecasis wrote:
> >> I would not go as far as saying that the concept is broken, but it
> >> definitely isn't portable. One big issue is that nowadays we
Thiago Macieira wrote:
> On terça-feira, 5 de junho de 2012 13.20.36, João Abecasis wrote:
>> I would not go as far as saying that the concept is broken, but it
>> definitely isn't portable. One big issue is that nowadays we don't
>> use an 8-bit encoding on Windows and those functions assume QStri
On terça-feira, 5 de junho de 2012 13.20.36, João Abecasis wrote:
> If they're no-op and we have no intention of reviving them, then this is
> the right time to completely remove them. Carrying around this cruft
> for no good reason doesn't help anyone.
We can remove them like we did QTextCodec::s
Hi,
I know I'm a bit late to this party, apologies for the disruption at
this point in the game. (There's a TL;DR/Summary at the end)
Thiago Macieira wrote:
> I'd like to deprecate those two functions, as well as the setters
> QFile::setEncodingFunction and setDecodingFunction. I'd like to go
> f
On segunda-feira, 14 de maio de 2012 12.26.53, lars.kn...@nokia.com wrote:
> Full support from my side for it.
https://codereview.qt-project.org/26155
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration
Full support from my side for it.
Cheers,
Lars
On 5/14/12 1:11 PM, "ext Thiago Macieira"
wrote:
>I'd like to deprecate those two functions, as well as the setters
>QFile::setEncodingFunction and setDecodingFunction. I'd like to go
>further and
>make the setters no-op, and the actual functions
I'd like to deprecate those two functions, as well as the setters
QFile::setEncodingFunction and setDecodingFunction. I'd like to go further and
make the setters no-op, and the actual functions be just an inline wrapper for
QString::to/fromLocal8Bit. However, I'll leave the encode/decodeName functi
26 matches
Mail list logo
