On domingo, 25 de agosto de 2013 00:18:01, Guido Seifert wrote:
> > 5.2 is in dev. It's a major rewrite of the QUrl encoding code. That's why
> > it's not in 5.1.
>
> A little bit more bleeding edge than I am used to, but why not? It is a fun
> and learn project. No problem when something breaks.
> 5.2 is in dev. It's a major rewrite of the QUrl encoding code. That's why
> it's
> not in 5.1.
A little bit more bleeding edge than I am used to, but why not? It is a fun and
learn project. No problem when something breaks. :-)
Guido
___
Interest
On sábado, 24 de agosto de 2013 22:54:24, Guido Seifert wrote:
> > > Changes %29 into ')'. I am sure, this is the problem, since according to
> > > wireshark this is the only difference between my client and rtorrent,
> > > which
> > > works and finds the torrents.
> >
> > It's fixed in Qt 5.2.
>
> > Changes %29 into ')'. I am sure, this is the problem, since according to
> > wireshark this is the only difference between my client and rtorrent, which
> > works and finds the torrents.
>
> It's fixed in Qt 5.2.
Great. Didn't do a 'git pull' for quite some time. Ok, I do it constantly, but
On sábado, 24 de agosto de 2013 21:55:51, Guido Seifert wrote:
> I add: "%B6%D5%CC%AD%A0%18%3C%A1%92%E7F9%D8C%14%16%ED%29%FEt" as encoded
> string, the stupid QUrlQuery class makes it
> %B6%D5%CC%AD%A0%18%3C%A1%92%E7F9%D8C%14%16%ED)%FEt.
>
> Changes %29 into ')'. I am sure, this is the problem, si
Hi,
following problem. I am trying to convert one of my programs from Qt4 to Qt5.
Qt4 uses QHttp. I want to switch to QNetworkAccessManager. So far, so good.
The program is a bittorrent client. My new version with QNetworkAccessManager
has only one problem: The trackers don't accept the info_has
On sábado, 24 de agosto de 2013 20:40:00, Simone wrote:
> I think i cannot use the standard x86 qmake.. Right?
That's exactly what I replied saying that is not supported.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
On sábado, 24 de agosto de 2013 20:46:31, Guido Seifert wrote:
> > > #define private public
> > > #include "Foo.h"
> >
> > Doesn't work with MSVC, since the protection level is encoded in the
> > member
> > function's name.
>
> This is interesting. How can this not work? This #define trick is a
>
On 08/24/2013 11:40 AM, Simone wrote:
> Yes, you are right,
> But in my case qt5 for ARM are built by yocto..
>
This is a separate topic, but I'd like to understand how.
I haven't seen Qt5 integrated, and the meta-qt5 package here
seems very much a work in progress:
https://github.com/met
> But I'd argue this: why the hell do you need to test the privates? If no one
> can call them, you should be able to change them freely. You should test only
> the interface available to others.
Haha, don't let us go down that road. There are two schools of thought,
fighting each other. One w
> > #define private public
> > #include "Foo.h"
>
> Doesn't work with MSVC, since the protection level is encoded in the member
> function's name.
This is interesting. How can this not work? This #define trick is a
preprocessor thing. The compiler never sees a 'private' So how can it know th
Yes, you are right,
But in my case qt5 for ARM are built by yocto..
There is a manual procedure to configure qt creator for cross development if I
don't have the "ready" qmake?
I think i cannot use the standard x86 qmake.. Right?
Il giorno 24/ago/2013, alle ore 18:44, Eric Nelson
ha scritto:
On sábado, 24 de agosto de 2013 19:16:19, Till Oliver Knoll wrote:
> Ha! I /knew/ it! MS is totally not adhering to "the standard" *rant*
> *rant*...
>
> Okay, you got me there, I never actually tried it myself, even though
> unit-testing private methods was also the first thing which came to my m
On 24 August 2013 19:16, Till Oliver Knoll wrote:
> I am pretty sure that even the naming might be overcome with a little #define
> wizardry, no? ;)
I don't think so. We're talking about the fact that MSVC mangles the
protection level into the symbol name:
http://en.wikipedia.org/wiki/Visual_C%
Am 24.08.2013 um 18:36 schrieb Thiago Macieira :
> On sábado, 24 de agosto de 2013 12:00:07, Till Oliver Knoll wrote:
>> C++ makes this easy for you:
>>
>> #define private public
>> #include "Foo.h"
>
> Doesn't work with MSVC,
Ha! I /knew/ it! MS is totally not adhering to "the standard" *rant
On 08/24/2013 09:38 AM, Thiago Macieira wrote:
> On sábado, 24 de agosto de 2013 17:50:17, Konstantin Tokarev wrote:
>> I don't know what is "qt-toolchain". ALl you need is to build Qt with your
>> toolchain, and you will get qmake and other utilities, as well as Qt
>> libraries.
>
> I think the OP
On sábado, 24 de agosto de 2013 17:50:17, Konstantin Tokarev wrote:
> I don't know what is "qt-toolchain". ALl you need is to build Qt with your
> toolchain, and you will get qmake and other utilities, as well as Qt
> libraries.
I think the OP is asking about the host-built Qt tools for cross-comp
On sábado, 24 de agosto de 2013 12:00:07, Till Oliver Knoll wrote:
> C++ makes this easy for you:
>
> #define private public
> #include "Foo.h"
Doesn't work with MSVC, since the protection level is encoded in the member
function's name.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Sof
24.08.2013, 15:58, "Simone" :
> Ok,
>
> in fact I built the toolchain with compilers and so on.
>
> But, probably I’m confused, what’s the difference between toolchain and
> qt-toolchain? Are both the same thing?
>
> Where is the qmake in the standard toolchain?
"toolchain" is basically gcc, bin
Ok,
in fact I built the toolchain with compilers and so on.
But, probably I'm confused, what's the difference between toolchain and
qt-toolchain? Are both the same thing?
Where is the qmake in the standard toolchain?
Da: Fathi Boudra [mailto:fbou...@gmail.com]
Inviato: sabato 24 ag
> There you go: all private members of class Foo have just become public! A hip
> hip horray for the preprocessor ;)
>
> Oh, by the way: should you feel the urge to pass on this "tip" to someone
> else: please don't mention my name, will you? ;)
Why not? I use this very useful trick constantly
On Sat, Aug 24, 2013 at 12:40 PM, Simone wrote:
> Hello Thiago and thank you for the reply!
>
> The recipe meta-qt5 already exist and I've used it to build the qt5
> libraries for my ARM.
> But the problem is the toolchain for qt5, seems that nobody has generate a
> recipe for that at the moment.
Am 24.08.2013 um 09:46 schrieb Constantin Makshin :
> Overriding a public method to make it private doesn't make much sense because
> this restriction can be easily circumvented by casting the pointer/reference
> to a base class (explicitly or by passing it to a function, in the context of
> th
Hello Thiago and thank you for the reply!
The recipe meta-qt5 already exist and I've used it to build the qt5 libraries
for my ARM.
But the problem is the toolchain for qt5, seems that nobody has generate a
recipe for that at the moment.
Without the toolchain, how i can cross-compile my qt5 app
People can do many things wrong. This is no argument. If this function would
have been private or protected, it would have been an alarm signal for me and I
would have looked into the docs. For me was QTemporaryFile just a QFile with a
little syntactic sugar for handling temporary files. It nev
> Now, here's another problem: on Unix, referring to the temporary file by
> anything besides its file descriptor means you're not in control. If the file
> is
> on a world-writable non-sticky directory, it's also a security risk: an
> attacker could delete the temporary file and replace it w
Overriding a public method to make it private doesn't make much sense
because this restriction can be easily circumvented by casting the
pointer/reference to a base class (explicitly or by passing it to a
function, in the context of this thread, expects a QFile or even more
generic QIODevice).
On A
27 matches
Mail list logo
