On 11/09/2011 07:41 PM, Giuseppe D'Angelo wrote:
> On 9 November 2011 18:35, Jeremy Lainé wrote:
>> C/ you make QDnsReply's constructor public, and let the user manage the
>> lifetime of the
>> object. This is what the Q3Dns API looks like. What I don't like about
>> Q3Dns's API is that
>> it's
Dear developers,
Please be informed that the Public Qt infrastructure, JIRA, Greenhopper
(bugreports.qt.nokia.com), Fisheye, Crowd (bugdiffs.qt.nokia.com) and Gerrit
(codereview.qt-project.org) will be disrupted by a maintenance window this
weekend on Saturday the 12th November 2011 between 9:00
On Wed, 9 Nov 2011 06:43:34 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
> I agree with most of the things in this thread, but not everything. Here's
> my thoughts:
>
> We need a Window {} element to create surfaces on a physical screen. This
> Window object should IMO be more or less a direct representat
My thanks to you, MGrasslin, Aaron, Todd rme, and Thiago for
coaching me towards this achievement. The new code is small, and
VERY simple. We have no API changes (at least, not yet--- we should
implement a mouse button mask "getter" as a new feature, but that's
for later
Op 9-11-2011 19:35, Jeremy Lainé schreef:
> On 11/09/2011 07:21 PM, Peter Hartmann wrote:
>> On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote:
>>> (...)
>>> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);
>>>
>>> pro: easy to connect to the QDnsReply's signal
>>> con: it's entirely
On 9 November 2011 18:35, Jeremy Lainé wrote:
> C/ you make QDnsReply's constructor public, and let the user manage the
> lifetime of the
> object. This is what the Q3Dns API looks like. What I don't like about
> Q3Dns's API is that
> it's unclear when the request is actually made.
It starts af
On 11/09/2011 07:21 PM, Peter Hartmann wrote:
> On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote:
>> (...)
>> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);
>>
>> pro: easy to connect to the QDnsReply's signal
>> con: it's entirely up to the user to handle deletion. Judging by your
On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote:
> (...)
> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);
>
> pro: easy to connect to the QDnsReply's signal
> con: it's entirely up to the user to handle deletion. Judging by your
> comments above, I
> doubt you favor it?
>
> or
>
On Wednesday 09 November 2011 18:05:52 Jeremy Lainé wrote:
> This talk about QtConcurrent has me wondering: do we need an asynchronous
> API at all?
>
> The underlying system calls are blocking anyway, and we could maybe have a
> very simple API like:
>
> QDnsInfo QDnsInfo::lookup(QDnsInfo::Recor
On 11/09/2011 06:21 PM, Robin Burchell wrote:
> On Wed, Nov 9, 2011 at 6:05 PM, Jeremy Lainé wrote:
>> This talk about QtConcurrent has me wondering: do we need an asynchronous
>> API at all?
> I really dislike synchronous APIs, even more so when they're the only
> option. Reason being that most
On Wed, Nov 9, 2011 at 6:05 PM, Jeremy Lainé wrote:
> This talk about QtConcurrent has me wondering: do we need an asynchronous API
> at all?
I really dislike synchronous APIs, even more so when they're the only
option. Reason being that most 'normal' people won't make the effort
to get it right
This talk about QtConcurrent has me wondering: do we need an asynchronous API
at all?
The underlying system calls are blocking anyway, and we could maybe have a very
simple API like:
QDnsInfo QDnsInfo::lookup(QDnsInfo::RecordType type, const QString &domain)
And if you want asynchronous calls
On Nov 4, 2011, at 9:37 PM, ext Thiago Macieira wrote:
> On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote:
>> Me too. My point was, that we have slightly different patters for
>> basically the same sort of thing in different places in Qt. QFuture is
>> currently coupled with QtConcu
On Friday, 28 de October de 2011 12:38:38 lars.kn...@nokia.com wrote:
> We've been moving this lib quite a bit already. If we move it again, I'd
> prefer it would end up at it's final location. The move was done before we
> had the decision to keep QtCore independent of V8 and to separate the QJS*
On Wed, Nov 9, 2011 at 11:26 AM, Jeremy Lainé wrote:
>
> Le Nov 9, 2011 à 10:14 AM, André Somers a écrit :
>
>
>
> On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé wrote:
>
>> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
>> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
>> >> - t
On Wednesday 09 November 2011 11:32:31 Thiago Macieira wrote:
> Q_NO_DECLARED_NOT_DEFINED - no clue what this is
This sounds like the compilers where doing the usual trick of "defining a
constructor private and never implementing it, since it will never be called"
is not allowed.
No idea which c
On Wednesday, 9 de November de 2011 10:45:42 Olivier Goffart wrote:
> Also, it would be nice to have a wiki page listing which the features not
> supported by which compilers. (we use to have that in the very old trolltech
> wiki) Also, this should be reflected in qglobal.h (which deserve a cleanup
Le Nov 9, 2011 à 10:14 AM, André Somers a écrit :
>
>
> On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé wrote:
> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> >> - the QNAM-style API seems to be OK
> > Correct, but all function
On Wednesday 09 November 2011 10:10:36 Thiago Macieira wrote:
> On Wednesday, 9 de November de 2011 09:21:20 Turunen Tuukka wrote:
> > VS2005
> > VS2008
> > VS2010
> > MinGW 4.4
> > Gcc 4.2 - 4.4
> > Xcode 4
> > Sun Studio 12 (CC 5.9)
> > Sun Studio 12.2 (CC 5.11)
> > Integrity Multi IDE 6
> > xLC
On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé wrote:
> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> >> - the QNAM-style API seems to be OK
> > Correct, but all functions in QDnsResolver are static.
> >
> > That means they could
On Wednesday, 9 de November de 2011 09:21:20 Turunen Tuukka wrote:
> VS2005
> VS2008
> VS2010
> MinGW 4.4
> Gcc 4.2 - 4.4
> Xcode 4
> Sun Studio 12 (CC 5.9)
> Sun Studio 12.2 (CC 5.11)
> Integrity Multi IDE 6
> xLC 7
> aCC 6.10
>
> For us, if Qt 5 works with these, as well as new versions is a good
On Wednesday, 9 de November de 2011 09:17:59 Jeremy Lainé wrote:
> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> >> - the QNAM-style API seems to be OK
> >
> > Correct, but all functions in QDnsResolver are static.
> >
> > That m
On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
>> - the QNAM-style API seems to be OK
> Correct, but all functions in QDnsResolver are static.
>
> That means they could go into QDnsReply and we could rename the class simply
> QDns. It
23 matches
Mail list logo
