Re: [Development] API review for a new QDnsResolver class
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 could go into QDnsReply and we could rename the class simply QDns. It worked for Qt 3... The methods are not static, the QDnsResolver instance initially owns all QDnsReply objects it returns. It also owns the QThreadPool used to perform the lookups. No need if all functions are static. And since they are not? They should be. There's no need for a QDnsResolver public object like QNetworkAccessManager. The idea of a manager in QNAM was to share settings, open connections and cookies. Usually, applications have only one QNAM and that's enough for them. However, in some circumstances, connections with different settings are necessary. Not so for DNS: the are no settings to be changed. So all queries use the same settings and resources, which are shared behind the scenes. All lookup functions should be static returning QDnsReply*, or it should be able to create the lookup using QDnsReply's constructor. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
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 they could go into QDnsReply and we could rename the class simply QDns. It worked for Qt 3... The methods are not static, the QDnsResolver instance initially owns all QDnsReply objects it returns. It also owns the QThreadPool used to perform the lookups. Initially? What does that mean exactly? When does QDnsResolver stops owning the QDnsReply objects? - I have implemented QDnsReply::abort() to cancel a lookup request Good. I forgot to mention: you can delete the QDnsReply at any time, as both QDnsReply and QDnsResolverRunnable access QDnsReplyPrivate via a QSharedPointer. In that case, wouldn't it make more sense then to return a QDnsReply (so not a pointer)? Hmmm... but that is of course not possible because it derives from QObject, right? - Robin mentioned adding a static QDnsResolver::instance() method, does anyone else have an opinion on this? No need if all functions are static. And since they are not? As I argued before: I think they should be, as the class you showed up contains no actual data (from the user's perspective of it, anyway). It causes problems with having to keep the instance alive while the DNS request is running, even though the object itself can not really be interacted with anymore. It doesn't even provide API to know if it can be savely deleted, or if it is still in the background managing running requests. So, when can the API user savely get rid of the requester object? IMHO, it would make sense to have the methods on QDnsResolver be static, and let those static methods reference some private (singleton?) instance of the object that owns stuff like a threadpool and the QDnsReplies. That frees the user from having to care about the lifetime of the resolver object. Andre ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
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 For us, if Qt 5 works with these, as well as new versions is a good starting point. Making sure that Qt 5 works with latest compilers such as VS2011 is important, as they typically provide significant advantages over the previous version. It would be good to have more compilers supported, especially for the embedded platforms. And definitely it is very important that as few as possible compilers are ruled our by design choices in Qt. Hello Tuukka Thanks for posting, this is important to us. The first compilers on the list above are already taken into account and should be no problem. XCode 4 isn't a compiler, it's just an IDE using either gcc or clang, which we've already discussed. As for the rest, they are compilers most developers do not have access to. It will be very hard for the community to support, so my recommendation to Digia, if permitted by the licenses you acquired there, is to provide a server for the community to log in and attempt compilation (on request, it doesn't have to be all the time). Still, for those platforms above, I recommend upgrading to the latest compilers and discarding the very old ones. For example, discard Sun CC 5.9 and use 5.11 only; discard xLC 7 and upgrade to xLC 10. But you're the one with the customers, so we need to know from you what your customers are likely to really need. We'd like to know your team's opinion for a 2012-2014 timeframe, not word-for-word what the customers say (they'll ask to support exactly what they already have). And we'll need some help to map out the features of those compilers. Remember: this exercise is to map out what features we can use everywhere and which ones could have an impact on existing or future support for a given compiler. 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) (In qglobal.h, yhere is still stuff like Q_NO_DECLARED_NOT_DEFINED, Q_NO_USING_KEYWORD, Q_NO_EXPLICIT_KEYWORD, Q_NO_BOOL_TYPE, Q_FULL_TEMPLATE_INSTANTIATION, Q_BROKEN_DEBUG_STREAM, Q_BROKEN_TEMPLATE_SPECIALIZATION, Q_NO_TEMPLATE_FRIENDS, ... Which of them are still required? Which of them do one remember the meaning?) My point is that it should be known why do don't use a feature of the C++ language, but also which feature need not to be used or only within #ifdef. And if there is no reference telling us that, how are developper supposed to know? So if a feature is not explicitly listed in that wikipage as something we should not use, then we can use it. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
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 all functions in QDnsResolver are static. That means they could go into QDnsReply and we could rename the class simply QDns. It worked for Qt 3... The methods are not static, the QDnsResolver instance initially owns all QDnsReply objects it returns. It also owns the QThreadPool used to perform the lookups. Initially? What does that mean exactly? When does QDnsResolver stops owning the QDnsReply objects? It means you can use QDnsReply::setParent() to take over ownership of the reply (like QNetworkReply). - I have implemented QDnsReply::abort() to cancel a lookup request Good. I forgot to mention: you can delete the QDnsReply at any time, as both QDnsReply and QDnsResolverRunnable access QDnsReplyPrivate via a QSharedPointer. In that case, wouldn't it make more sense then to return a QDnsReply (so not a pointer)? Hmmm... but that is of course not possible because it derives from QObject, right? Correct, QDnsReply has both an abort() slot and a finished() signal. - Robin mentioned adding a static QDnsResolver::instance() method, does anyone else have an opinion on this? No need if all functions are static. And since they are not? As I argued before: I think they should be, as the class you showed up contains no actual data (from the user's perspective of it, anyway). It causes problems with having to keep the instance alive while the DNS request is running, even though the object itself can not really be interacted with anymore. It doesn't even provide API to know if it can be savely deleted, or if it is still in the background managing running requests. So, when can the API user savely get rid of the requester object? IMHO, it would make sense to have the methods on QDnsResolver be static, and let those static methods reference some private (singleton?) instance of the object that owns stuff like a threadpool and the QDnsReplies. That frees the user from having to care about the lifetime of the resolver object. Currently, QDnsResolver can be deleted at any time without fear of a crash. However if there are outstanding requests, this will block until the QThreadPool has finished. I agree that it looks as though QDnsResolver methods should be static, although it does once again raise the question of QDnsReply ownership since the replies can no longer be owned by the QDnsResolver. However, I am unsure about putting the methods in QDnsReply (even if it gets renamed to just QDns), I don't find it very descriptive in terms of API. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
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) +1 (In qglobal.h, yhere is still stuff like Q_NO_DECLARED_NOT_DEFINED, Q_NO_USING_KEYWORD, Q_NO_EXPLICIT_KEYWORD, Q_NO_BOOL_TYPE, Q_FULL_TEMPLATE_INSTANTIATION, Q_BROKEN_DEBUG_STREAM, Q_BROKEN_TEMPLATE_SPECIALIZATION, Q_NO_TEMPLATE_FRIENDS, ... Which of them are still required? Which of them do one remember the meaning?) Hopefully we can get rid of these: Q_NO_DECLARED_NOT_DEFINED - no clue what this is Q_NO_USING_KEYWORD - Symantec C++, Digital Mars, Borland C++, Comeau, others Q_NO_EXPLICIT_KEYWORD - Symantec C++, Digital Mars, Borland C++ Q_NO_BOOL_TYPE - Borland C++, Compaq C++ 6, Q_CC_DIAB Q_BROKEN_DEBUG_STREAM - Apple's gcc 3.1 - 3.3 Q_BROKEN_TEMPLATE_SPECIALIZATION - xlC 4, old EDG compilers Q_FULL_TEMPLATE_INSTANTIATION - gcc 2.95 Q_NO_STL_WCHAR - gcc 2.95 Q__NO_PACKED_REFERENCE - was broken code I guess Q_TYPENAME - xlC 4 The member-template and partial-specialisation macros are gone already. We should also remove all those compilers above that aren't tested by anyone anymore. These need more investigation as they are probably still enabled for current compilers. My guess is they can be gone too. Q_NO_DEPRECATED_CONSTRUCTORS - gcc on __APPLE__ Q_CANNOT_DELETE_CONSTANT - xlC 4, MSVC QT_NO_TEMPLATE_TEMPLATE_PARAMETERS - only enabled for Sun CC currently, but I'm told 5.10 has them This is currently the only we need to keep: Q_NO_TEMPLATE_FRIENDS - GCC only for now, but the code says Sun CC 5.10 has it Then there are all the C++11 features, but they are Q_COMPILER_* My point is that it should be known why do don't use a feature of the C++ language, but also which feature need not to be used or only within #ifdef. And if there is no reference telling us that, how are developper supposed to know? Well, we currently have one certain macro for C++98 features, one potential (TTPs), then we have C++03 and TR1 features, C++11 and extensions (like C99 support). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
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 compiler that would be though. MSVC 6? -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
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 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 worked for Qt 3... The methods are not static, the QDnsResolver instance initially owns all QDnsReply objects it returns. It also owns the QThreadPool used to perform the lookups. Initially? What does that mean exactly? When does QDnsResolver stops owning the QDnsReply objects? It means you can use QDnsReply::setParent() to take over ownership of the reply (like QNetworkReply). OK. I would like it more if that was more explicit in the API (also for QNAM), but ok. I am not a big fan of ::setParent() in such contexts, it doesn't feel natural to me. - I have implemented QDnsReply::abort() to cancel a lookup request Good. I forgot to mention: you can delete the QDnsReply at any time, as both QDnsReply and QDnsResolverRunnable access QDnsReplyPrivate via a QSharedPointer. In that case, wouldn't it make more sense then to return a QDnsReply (so not a pointer)? Hmmm... but that is of course not possible because it derives from QObject, right? Correct, QDnsReply has both an abort() slot and a finished() signal. QFuture solves this by having the QFuture itself be a value class, and have a QFutureWatcher that supplies the signals. Might be overkill though here, and is nicer if the two are combined IMO. - Robin mentioned adding a static QDnsResolver::instance() method, does anyone else have an opinion on this? No need if all functions are static. And since they are not? As I argued before: I think they should be, as the class you showed up contains no actual data (from the user's perspective of it, anyway). It causes problems with having to keep the instance alive while the DNS request is running, even though the object itself can not really be interacted with anymore. It doesn't even provide API to know if it can be savely deleted, or if it is still in the background managing running requests. So, when can the API user savely get rid of the requester object? IMHO, it would make sense to have the methods on QDnsResolver be static, and let those static methods reference some private (singleton?) instance of the object that owns stuff like a threadpool and the QDnsReplies. That frees the user from having to care about the lifetime of the resolver object. Currently, QDnsResolver can be deleted at any time without fear of a crash. However if there are outstanding requests, this will block until the QThreadPool has finished. I agree that it looks as though QDnsResolver methods should be static, although it does once again raise the question of QDnsReply ownership since the replies can no longer be owned by the QDnsResolver. However, I am unsure about putting the methods in QDnsReply (even if it gets renamed to just QDns), I don't find it very descriptive in terms of API. I agree with you on the putting methods in QDnsReply (and calling it QDns). I prefer to keep the reply just that: an object representing a (future) reply to a query, not the query itself. On the ownership: It looks like you will need to have an object with some state somewhere anyway. Somebody has to own that QThreadPool, for instance. So, why not make that object the (first) parent then? Problem then is: who will cleanup the reply objects, and when will that happen, as the user has no control over the lifetime. I don't like having the delete of QDnsResolver block untill are requests are finished. Once again: returning a shared pointer to the QDnsReply object would solve that (the QDnsResolverPrivate class would keep a shared pointer around as long as the request is active), but it seems that is not a favoured solution. Would it be difficult to have QObject::connect support QSharedPointerQObject as the QObject* argument? Or rather, I guess, classes that overload operator-() that return a QObject*? Andre ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
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* classes and the QML engine into it's own module. With the above decision it might make sense to move V8, the QJS* classes and the QML engine all into the same shared library. Kent Aaron, any thoughts? Since they don't seem to have an opinion, can we please move it to top-level inside qt5.git? I've just caught a bad commit in my tree that updates the commit link to v8 and I'm trying to fix it with an interactive rebase. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
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, but is there a strong reason why is must be? I was not privy to that IRC chat, perhaps you could tell us the reasoning why it would not be possible? There's no reason why it has to be coupled with Concurrent. Or, to put in other words, it could be changed to work without Concurrent. However, the problem is, it is currently too tightly coupled with QtConcurrent. Unless someone is volunteering to do this work right now... Actually, is it tightly coupled at all? qfutureinterface.h contains the (undocumented) backend class that run/map/filter uses to produce results for QFuture. That class could be polished up and documented if we want to use QFuture in other places. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
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/ static QSharedPointerQDnsReply QDnsReply::lookup(QDnsReply::Type, QString); pro: memory ownership is explicit con: how used are our users to manipulating QSharedPointer with respect to signals and such? I rather favour option B (lessons learned from QNAM), because I think option A might lead to undeleted replies, which is what we experienced in the case of QNetworkReply *QNetworkAccessmanager::get(...). We probably can mitigate the complexity introduced by QSharedPointer by having a simple example in the documentation. However if people more favour option A, that would not be a problem for me either. Peter Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
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 made. It starts after you return to the event loop, just like all the other socket classes. -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
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 handle deletion. Judging by your comments above, I doubt you favor it? or B/ static QSharedPointerQDnsReply QDnsReply::lookup(QDnsReply::Type, QString); pro: memory ownership is explicit con: how used are our users to manipulating QSharedPointer with respect to signals and such? I rather favour option B (lessons learned from QNAM), because I think option A might lead to undeleted replies, which is what we experienced in the case of QNetworkReply *QNetworkAccessmanager::get(...). OK, there is always another option: 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. You mean, like this? //user code QDnsReply* dnsReply = new QDnsReply(this); QDnsResolver::lookup(dnsQuery, dnsReply); Not a big fan... Lets stick to either A or B. *I* prefer B, but that much should be clear by now. I also suggest we ask somebody with more template fu than I can wield to look into if it would be feasable to let this work: QSharedPointerQDnsReply dnsReply = QDnsResolver::lookup(dnsQuery); connect(dnsReply, SIGNAL(finished()), this, SLOT(dnsFinished())); //directly connect, instead of: connect(dnsReply.data(), SIGNAL(finished()), this, SLOT(dnsFinished())); //currently needed connect statement André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
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 of
QQuickView in QML.
So far we all seem to agree. But I also do not see a need to limit the
Window {} API to the mobile use cases. I'd rather that we expose the full
functionality in one Object, and rather document some of the differences
in behavior between mobile and desktop.
I'm wary of trying to expose desktop APIs for desktop use cases, especially
before Desktop QML is fully realized. We might end up exposing the wrong then
and then we're at the same point as before plus we're maintaining and
supporting use-impaired code. I'm also not fond of providing an element for
use in mobile contexts with functionality that basically says: Don't use
this. If it's not to be used on those platforms, why even have it available
for those platforms?
As far as I'm aware there is a lot of features in this gap. Window
decorations, modality, even geometry could be construed as desktop only.
Using the Window {} object anywhere in QML creates a new top level window.
This implies that a Window{} as the root item of a QQuickView would create
an empty QQuickView and a second top-level created through the WIndow
object. But at least this would mean there's no magic involved.
Yep.
Like that we can change the default way of using QML to be symmetric
between Desktop and Mobile. You instantiate a QQuickEngine, and then load
a QML file that contains a WIndow {} as the outermost element. If we
remove the Window {} in QtComponents and use this instead, we can then
make this fully symmetrical on the QML side between desktop and mobile.
The only difference would be in the default behavior of Window (most
likely full screen on mobile, windowed on desktop).
One of the changes talked about on the qt-components mailing list is that with
this approach you no longer have a Window{} as the outermost element in
desktop components.
I would rather have the C++ controlled windows exposed manually through C++
and have the QML Window{}'s separate. This sounds easily exposed through
ApplicationWindow{} anyways.
Differentiation between mobile and desktop can then happen on the
ApplicationWindow level in QtComponents, where the ApplicationWindow for
the desktop would support menu- and toolbars, the mobile version would
support pages and whatever else is needed there.
In addition, it should be easy to associate a Window {} with a certain
physical screen. For this I'd propose, we somehow expose the list of
screens as objects in Qt.application, and give Window {} a screen property
that can be bound to a screen.
So
Window {
screen: Qt.application.primaryScreen // the default behavior
}
would create a Window on the primary screen.
The main question I'm unsure about is what to do with Windows on screens
that are going away (by unplugging the VGA cable going to the projectorŠ).
I've been thinking about the screen issue, and my conclusion was that this
approach wouldn't work. Exposing the screens this way through Qt.application
wasn't deemed useful in the QScreen API thread, and a lot of the same problems
arise here. Aside from the primary screen, it will be very difficult to bind
this window to the right other screen, you can't just go off of list index
(except perhaps in the common case of external displays) so you need to query
the new screens on screenAdded/startup and imperatively assign windows. If
you're going to do it the imperative way anyways, you may as well do it in C++
and just move Window{} objects out of the main QML file into another canvas
(that way they were created in the same engine and have useful bindings).
So here's my suggestion for what would work. Leave the general case for C++ as
explained above, and offer a convenience of the common case of an external
display. Example:
ExternalDisplay{
Rectangle{
anchors.fill: parent
}
}
Arguably you could require a Window instead and automatically rescreen it, but
I prefer relaxing the restriction to any QQuickItem and it's just like the
root item in another view.
As you can guess, the effect of the ExternalDisplay{} is that it will
dynamically load and unload the child component and place it on any secondary
display when it's available. The root item for that display will be scaled
much like a QQuickView.
I've been trying to prototype it recently, but my efforts are currently
stalled by the XCB plugin crashing when you try to do any GL on a secondary
screen :( . So I'm sorry, but I don't have the code for this yet.
So my proposal would be something exposing most of the QWindow API:
Window {
property Screen screen
property Orientation orientation // { Portrait,
[Development] Public Qt infrastructure update: Saturday 12th November 2011
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-18:00 CET. The core outage will be an update of the Atlassian products JIRA, Greenhopper, Fisheye and Crowd to new versions for security, performance and functionality reasons. As the Gerrit server is dependent on this infrastructure for authentication via HTTPS, this service will also experience some loss of functionality. The maintenance window allows for an upgrade, validation and rollback period so that the total outage period could be roughly half the projected window. All being well after the upgrade, the Fisheye system configuration will be updated to begin tracking the module git repos for Qt5 to allow an enhanced binding between issues in JIRA and the code that has been merged to correct them. Best Regards Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
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 that it's unclear when the request is actually made. It starts after you return to the event loop, just like all the other socket classes What I mean is that the Q3Dns has setters as well as a constructor with arguments, so for instance: Q3Dns *dns = new Q3Dns; dns-setLabel(foodomain.org);// will a request be triggered if I stop here and don't specify the record type? dns-setRecordType(Q3Dns::); .. later .. dns-setLabel(bardomain.org); // will a new request be issued, since I changed the queried domain? What happens to the existing results? Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
