Em seg 03 fev 2014, às 16:26:21, Thiago Macieira escreveu:
> As I said above, that is the plan because it changes the parsing itself.
> endpos == NULL implies that the parsing must consume the entire string,
> which is the current behaviour.
I'd like to point out that the patches are ready now, on
On 10 Feb 2014, at 20:17, Thiago Macieira wrote:
> Em seg 10 fev 2014, às 19:54:18, Kurt Pattyn escreveu:
>> Well, this is what I propose: use a delegate class that handles the creation
>> of a random 32-bit number. This would avoid having to subclass QWebSocket
>> just to overwrite the randomis
Em seg 10 fev 2014, às 20:34:20, Olivier Goffart escreveu:
> > > static QElapsedTimer t;
> > > return qsrand(t.nsecsElapsed());
> >
> >
> >
> > You forgot to start() the timer. Which means this is a really poor choice
> > for seeing the random engine, since a newly-started elapsed timer will be
>
On Sunday 09 February 2014 21:35:18 Thiago Macieira wrote:
> Em dom 09 fev 2014, às 23:57:24, Olivier Goffart escreveu:
> > I think you are making it more complicated than it need to be.
> > qrand has maximum 32bit entropy (because it uses rand_r internally which
> > only has 32 bit state), there
Em seg 10 fev 2014, às 19:54:18, Kurt Pattyn escreveu:
> Well, this is what I propose: use a delegate class that handles the creation
> of a random 32-bit number. This would avoid having to subclass QWebSocket
> just to overwrite the randomiser.
I don't think we need a class. We just need to make
On 10 Feb 2014, at 08:58, Konrad Rosenbaum wrote:
> Hi,
>
> I'll have to read and analyze this code in more detail to give you a
> qualified
> opinion. I'll do this later...
>
> On the surface it looks a bit complicated and I'm not entirely sure about the
> seeding, but I'll have to study t
On 09 Feb 2014, at 23:57, Olivier Goffart wrote:
> On Sunday 09 February 2014 22:40:22 Kurt Pattyn wrote:
>
> I think you are making it more complicated than it need to be.
> It turns out 32 bit entropy is enough because that's the size of your mask,
> so
> just use qrand with a decent prope
+1 from another interested party :)
> QmfClient => QtMail
> QmfMessageServer => QtMessageServer
Two modules in one repo (aka QT += mail messageserver), right?
BTW, are you planning an API review/refactoring for it?
Regards,
Konstantin
2014-02-10 Robin Burchell :
> Hello folks,
>
> After some
> > >I’ve now gone through all changes. The set looks pretty good overall, and
> > >testing on Linux showed no regressions compared to 5.2.
> >
> > One correction here: The paperRect as shown in the preview of the dialogs
> > manual test shows some slightly different results, that look like a
> > r
On 10-Feb-14 16:58, Thiago Macieira wrote:
> It's actually not a constructor. It's the ages-old C++ mystery: what does this
> declare?
>
> QStringList(other);
>
> It's actually a function declaration.
Aaahh right. Which explains why the function *call* works.
Joerg
___
Hello folks,
After some build system reworking recently and a little discussion
amongst the interested parties (Matt Vogt, Valerio), I'd like to
propose renaming QMF (Qt Messaging Framework) to QtMail with the
longer term goal of making it a module of Qt properly - no longer a
labs project.
QMF's
Em seg 10 fev 2014, às 16:27:56, Joerg Bornemann escreveu:
> On 10-Feb-14 15:23, Joerg Bornemann wrote:
> > Looks like __typeof__, which is used when building with a recent gcc,
> > behaves differently when passing a c'tor?
>
> Well it seems to be the type of the constructor, not the type of the
>
On 10-Feb-14 15:23, Joerg Bornemann wrote:
> Looks like __typeof__, which is used when building with a recent gcc,
> behaves differently when passing a c'tor?
Well it seems to be the type of the constructor, not the type of the
constructed object.
This patch fixes the incompatibility between MSV
Em dom 09 fev 2014, às 23:57:24, Olivier Goffart escreveu:
> I think you are making it more complicated than it need to be.
> qrand has maximum 32bit entropy (because it uses rand_r internally which
> only has 32 bit state), therefore calling it several time in a row is
> totally useless and don'
Consider the following piece of code:
QStringList other;
foreach (QString str, QStringList(other))
;// do something
This builds fine with Visual Studio 2013.
With gcc 4.7.2 and clang 3.0-6.2 we get:
error: request for member 'brk' in '_container_', which is of non-class
type 'QForeachC
> Sadly there is no easy migration path and this implies a full rewrite.
Do you have a writeup of the options you looked at and results of each one?
QtQuick might be the best way forwards but a full rewrite is usually
something to be very wary
of unless the requirements for the product itself hav
16 matches
Mail list logo
