Re: [Development] API review for a new QDnsResolver class

2011-11-09 Thread Thiago Macieira
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 means they

Re: [Development] API review for a new QDnsResolver class

2011-11-09 Thread André Somers
On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé jeremy.la...@m4x.org 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

Re: [Development] Platform / compiler support

2011-11-09 Thread Olivier Goffart
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 7 aCC 6.10

Re: [Development] API review for a new QDnsResolver class

2011-11-09 Thread Jeremy Lainé
Le Nov 9, 2011 à 10:14 AM, André Somers a écrit : On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé jeremy.la...@m4x.org 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

Re: [Development] Platform / compiler support

2011-11-09 Thread Thiago Macieira
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)

Re: [Development] Platform / compiler support

2011-11-09 Thread David Faure
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

Re: [Development] API review for a new QDnsResolver class

2011-11-09 Thread André Somers
On Wed, Nov 9, 2011 at 11:26 AM, Jeremy Lainé jeremy.la...@m4x.org wrote: Le Nov 9, 2011 à 10:14 AM, André Somers a écrit : On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé jeremy.la...@m4x.org wrote: On 11/08/2011 10:57 PM, Thiago Macieira wrote: On Tuesday, 8 de November de 2011 19:40:13

Re: [Development] V8's location

2011-11-09 Thread Thiago Macieira
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*

Re: [Development] API review for a new QDnsResolver class

2011-11-09 Thread morten.sorvig
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 QtConcurrent,

Re: [Development] API review for a new QDnsResolver class

2011-11-09 Thread Peter Hartmann
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 B/

Re: [Development] API review for a new QDnsResolver class

2011-11-09 Thread Giuseppe D'Angelo
On 9 November 2011 18:35, Jeremy Lainé jeremy.la...@m4x.org 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

Re: [Development] API review for a new QDnsResolver class

2011-11-09 Thread Andre Somers
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 up to the user to

Re: [Development] Window{} API for QML

2011-11-09 Thread Alan Alpert
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 representation

[Development] Public Qt infrastructure update: Saturday 12th November 2011

2011-11-09 Thread mark.keir
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

Re: [Development] API review for a new QDnsResolver class

2011-11-09 Thread Jeremy Lainé
On 11/09/2011 07:41 PM, Giuseppe D'Angelo wrote: On 9 November 2011 18:35, Jeremy Lainéjeremy.la...@m4x.org 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