Re: [Development] QFileSystemWatcher and Recursive Monitoring

2012-07-19 Thread logic.cpp
#1 Clarification of original post: When I say "Making QFileSystemWatcher Recursive" I mean *adding* new functions for recursive monitoring, such as "addPathRecursively()". I don't mean to replace the current non-recursive functinality, which is very useful in its own right (for "A" category use ca

[Development] QFileSystemWatcher and Recursive Monitoring

2012-07-19 Thread logic.cpp
BH Hello, Hope you don't mind my less-waste-your-time more-get-to-the-point English. Begin ramble: Wanted to fix QFileSystemWatcher for Windows as per w00t's article: (also see his fix:

Re: [Development] About "finish" signal in QHttpNetworkConnectionChannel

2012-07-19 Thread song.7.liu
OK, you can ignore this mail thread now, it's the thread_pipe not implemented in our porting ... thanks. From: development-bounces+song.7.liu=nokia@qt-project.org [mailto:development-bounces+song.7.liu=nokia@qt-project.org] On Behalf Of Liu Song.7 (Nokia-MP/Beijing) Sent: Friday, July 2

Re: [Development] About "finish" signal in QHttpNetworkConnectionChannel

2012-07-19 Thread song.7.liu
It seem I know that it is avoiding "wake up" again if it's already alive. And the wakeUps._q_value is 1 in my case, but this main thread actually is pending at doSelect, so I don't know why wakeUps is not zero ! From: development-bounces+song.7.liu=nokia@qt-project.org [mailto:development-b

Re: [Development] About "finish" signal in QHttpNetworkConnectionChannel

2012-07-19 Thread song.7.liu
Hi, Thanks, and now the "root cause" is found, that the "finished" signal is posted to the main thread, and also it will try to wake up the main thread: void QEventDispatcherUNIX::wakeUp() { Q_D(QEventDispatcherUNIX); if (d->wakeUps.testAndSetAcquire(0, 1)) { char c = 0;

Re: [Development] Behaviour change of opacity property in QtQuick 2.0

2012-07-19 Thread Alan Alpert
On Thu, 19 Jul 2012 11:06:29 ext Sven Anderson wrote: > On 19.07.2012 03:29, Alan Alpert wrote: > > On Wed, 18 Jul 2012 19:00:01 ext Rafael Brandao wrote: > > > > There's a new enabled property which also prevents mouse input. It also > > affects keyboard focus, but if you aren't using keyboard fo

Re: [Development] Abandoning the container changes

2012-07-19 Thread joao.abecasis
Thiago Macieira wrote: > As you've shown, we need to duplicate everything that has QString, > QByteArray and QVector in our API. Not to forget QList, QVariant and potentially other classes we haven't considered changing yet. Besides, I'm sure we'd find places where we can't decide which one is th

Re: [Development] Suggestion on QML portability

2012-07-19 Thread martin.jones
> On Behalf Of ext Donald Carr > > > Not inside this tower ;) . But I wasn't talking about comparing to the > > proliferation of an unreleased version. All the QtQuick 1 I've seen so > > far is on the dead Symbian and Maemo platforms. Even if there were > > many of those applications, how many are

Re: [Development] Qt Project CI outage on 19th-20th July 2012

2012-07-19 Thread Rohan McGovern
Rohan McGovern said: > Hi all, > > Please be advised that tonight/tomorrow the Qt Project CI system > will have a temporary outage for planned maintenance of a site UPS. > > The system will stop accepting new builds at: > > 18:30 UTC, 19th > 20:30 CET, 19th > 04:30 AEST, 20th > > The outa

Re: [Development] Suggestion on QML portability

2012-07-19 Thread Donald Carr
> Not inside this tower ;) . But I wasn't talking about comparing to the > proliferation of an unreleased version. All the QtQuick 1 I've seen so far is > on the dead Symbian and Maemo platforms. Even if there were many of those > applications, how many are in continued development for both the old

Re: [Development] About "finish" signal in QHttpNetworkConnectionChannel

2012-07-19 Thread Markus Goetz
On 19.07.12 17:55, song.7@nokia.com wrote: Hi, I am using the QNetworkAccessManager::get to request content from http://www.google.com. Then the QHttpNetworkConnectionChannel will be created and worked on another thread, when all the data is received, the QHttpNetworkConnectionChannel:

[Development] About "finish" signal in QHttpNetworkConnectionChannel

2012-07-19 Thread song.7.liu
Hi, I am using the QNetworkAccessManager::get to request content from http://www.google.com. Then the QHttpNetworkConnectionChannel will be created and worked on another thread, when all the data is received, the QHttpNetworkConnectionChannel::allDone will be invoked, where: // queue the f

Re: [Development] Abandoning the container changes

2012-07-19 Thread Marc Mutz
hi Thiago, There are two sides to this coin. On Thursday July 19 2012, Thiago Macieira wrote: > On quinta-feira, 19 de julho de 2012 14.19.36, Marc Mutz wrote: > > Even with inline namespaces? Then they would have failed to achieve their > > goal to hide the fact that the type is in an inline na

Re: [Development] Moving QWindowSystemInterface out of QPA

2012-07-19 Thread Girish Ramakrishnan
On Thu, Jul 19, 2012 at 7:16 AM, wrote: > On 7/16/12 12:43 PM, "ext Stephen Kelly" wrote: > >>On Sunday, July 15, 2012 14:24:18 Holger Hans Peter Freyther wrote: >>> On Tue, Jul 10, 2012 at 11:53:33AM +0200, Thiago Macieira wrote: >>> > We have only two choices: >>> > >>> > 1) make QWindowSystem

Re: [Development] Moving QWindowSystemInterface out of QPA

2012-07-19 Thread lars.knoll
On 7/16/12 12:43 PM, "ext Stephen Kelly" wrote: >On Sunday, July 15, 2012 14:24:18 Holger Hans Peter Freyther wrote: >> On Tue, Jul 10, 2012 at 11:53:33AM +0200, Thiago Macieira wrote: >> > We have only two choices: >> > >> > 1) make QWindowSystemInterface a proper, public API class >> >> I thi

Re: [Development] Abandoning the container changes

2012-07-19 Thread Thiago Macieira
On quinta-feira, 19 de julho de 2012 14.31.52, Marc Mutz wrote: > namespace v50 { >class QVector ... ; // same as before > } > inline namespace v52 { > class QVector ... ; // new impl, with conversion to/from v50::QVector... > } > qFun(const v50::QVector&); // old version, explicit namespac

Re: [Development] Abandoning the container changes

2012-07-19 Thread Thiago Macieira
On quinta-feira, 19 de julho de 2012 14.19.36, Marc Mutz wrote: > Even with inline namespaces? Then they would have failed to achieve their > goal to hide the fact that the type is in an inline namespace. Yes. It breaks binary compatibility completely for all the code that uses QString in its API

Re: [Development] Can we bring back QT += declarative?

2012-07-19 Thread lars.knoll
On 7/19/12 1:03 PM, "ext Robin Burchell" wrote: >On Thu, Jul 19, 2012 at 1:58 PM, wrote: >> What do we want to do in the examples in that case? Can we there still >>use >> "QT += qtquick1"? > >I'm not sure how that is going to be less confusing. I'd say it's worse. > >QDeclarative* classes => o

Re: [Development] Multitouch on top of XInput 2.2

2012-07-19 Thread Christian Spielberger
> I noticed you deleted the code to deal with the valuators completely, so that > means in your branch there is no support for pressure or major/minor axes, > right? When I run fingerpaint against your branch, it is indeed insensitive > to pressure, I just get circles all the same size. I don't t

Re: [Development] Abandoning the container changes

2012-07-19 Thread Marc Mutz
On Thursday July 19 2012, joao.abeca...@nokia.com wrote: > Marc Mutz wrote: > > On Wednesday July 18 2012, joao.abeca...@nokia.com wrote: > >> I think it would be feasible to do a binary-only break somewhere > >> around the 5.2 timeframe (say, ~12 months) where we address this. > >> Technically, th

Re: [Development] Q_DECLARE_TYPEINFO and namespaced Qt

2012-07-19 Thread lars.knoll
+1 for fixing Q_DECLARE_TYPEINFO. Let's at least have the macros consistent with each other. Cheers, Lars On 7/11/12 10:48 AM, "ext Jedrzej Nowacki" wrote: > >It only shows how difficult is to work with namespaced Qt :-) In general >I agree with Olivier, let's fix Q_DECLARE_TYPEINFO, or just le

Re: [Development] Abandoning the container changes

2012-07-19 Thread Marc Mutz
On Wednesday July 18 2012, Olivier Goffart wrote: > On Wednesday 18 July 2012 14:00:08 Marc Mutz wrote: > > On Wednesday July 18 2012, Oswald Buddenhagen wrote: > > > On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote: > > > > We don't even need to break binary compatibility. We could us

[Development] Partial screen updates with Scenegraph

2012-07-19 Thread Dietrich . Gossen
Hi, Is it possible to set the new Grahpicsstack to do only partial screen updates? This would help me fixing some performance issues on embedded devices. Best regards Dietrich ___ Development mailing list Development@qt-project.org http://lists.qt-pr

Re: [Development] Can we bring back QT += declarative?

2012-07-19 Thread Robin Burchell
On Thu, Jul 19, 2012 at 1:58 PM, wrote: > What do we want to do in the examples in that case? Can we there still use > "QT += qtquick1"? I'm not sure how that is going to be less confusing. I'd say it's worse. QDeclarative* classes => old QML QT += declarative => old QML QQuick* classes => new

Re: [Development] Can we bring back QT += declarative?

2012-07-19 Thread casper.vandonderen
On 7/19/12 12:40 PM, "Knoll Lars (Nokia-MP/Oslo)" wrote: >On 6/29/12 11:37 PM, "ext Thiago Macieira" >wrote: > >>On quinta-feira, 28 de junho de 2012 23.53.51, martin.jo...@nokia.com >>wrote: >>> Reassigning "declarative" back to qtquick1 could be done. I'm not sure >>>that >>> is an improvem

Re: [Development] Can we bring back QT += declarative?

2012-07-19 Thread lars.knoll
On 6/29/12 11:37 PM, "ext Thiago Macieira" wrote: >On quinta-feira, 28 de junho de 2012 23.53.51, martin.jo...@nokia.com >wrote: >> Reassigning "declarative" back to qtquick1 could be done. I'm not sure >>that >> is an improvement since we have QtQuick 2 in the qtdeclarative module, >>so >> it a

[Development] Debugging qwindow-compositor with example/opengl/hellogl_es2

2012-07-19 Thread Elvis Lee
I tested qwindow-compositor with some examples and found that hellogl_es2 was not working. It’s because that the app was blocked in QWaylandDisplay::blockingReadEvents, waiting frameCallback. But the frameCallback is already read and it’s on wayland connection. Briefly, QWaylandWindow::waitForFr

Re: [Development] Behaviour change of opacity property in QtQuick 2.0

2012-07-19 Thread Sven Anderson
On 19.07.2012 03:29, Alan Alpert wrote: > On Wed, 18 Jul 2012 19:00:01 ext Rafael Brandao wrote: > > There's a new enabled property which also prevents mouse input. It also > affects > keyboard focus, but if you aren't using keyboard focus you can bind enabled: > opacity > 0 and get effectively th

Re: [Development] Abandoning the container changes

2012-07-19 Thread lars.knoll
Some comments to the thread as a whole: Thiago did the call to not pursue the container changes any more for Qt 5 and propably had good reasons to do so. That implies that we'll continue with the classes we have now (yes, with their downsides in some use cases as well) for Qt 5. The containers ar

Re: [Development] Patches for QPA KMS

2012-07-19 Thread laszlo.p.agocs
There is support for the kms plugin in configure since yesterday: https://codereview.qt-project.org/#change,30856 The compilation failures with recent Mesa have also been corrected, therefore 31059 should not be needed anymore. Regards, Laszlo From: developmen

[Development] Patches for QPA KMS

2012-07-19 Thread Elvis Lee
I know that kms is not included in configure yet. But I have used it for developing with qtwayland. Few days ago, I did update qtwayland, mesa and others. Then, I found that the kms didn’t work well. So I made two patches and tested in my environment. Could you review that? https://codereview