[Development] When the QPaintEvent is sent?

[Alexander Syvak]

What are the exact conditions when Qt may repaint an a screen?
I am interested in any visual change of a monitor screen. Hence, it is
sensible to wait for any repaint event.
E.g. in Windows it is repainted accord. to MSDN when
a control element is resized, moved, exposed after being covered by another
control element.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QNetwork problem in threaded application.

[Benjamin Zeller]

Hello,

i'm currently stress-testing a application at work and came across this
problem.
The application accepts connections and pushes the created sockets
to a worker thread (moveToThread), the worker thread then handles the
rest.
But sometimes when the socket was already closed in the thread i
get a SEGFAULT. It seems something in the mainthread tries to access
the socket engine.

After debugging it i saw that in the backtrace
QCoreApplication::sendEvent is used, instead of postEvent.




Backtrace Mainloop (stops in qabstractsocket.cpp line 741):

 if (readSocketNotifierStateSet && socketEngine &&
 >>readSocketNotifierState != 
socketEngine->isReadNotificationEnabled()) {
 socketEngine->setReadNotificationEnabled(readSocketNotifierState);
 readSocketNotifierStateSet = false;
 }
 return true;



In the Thread backtrace you can see the thread is closed
 Backtrace Thread --
Thread 17 (Thread 0x7f8fc0df3700 (LWP 5101)):
#0  0x7f8fe0d397fd in QLocalePrivate::plus (this=0x7f8f9c010260) at 
tools/qlocale_p.h:228
No locals.
#1  0x7f8fe0d363a0 in QLocalePrivate::unsLongLongToString 
(this=0x7f8f9c010260, l=15, precision=-1, base=10, width=-1, flags=0) at 
tools/qlocale.cpp:3036
No locals.
#2  0x7f8fe0ddc0af in QTextStreamPrivate::putNumber 
(this=0x7f8f9c0140e0, number=15, negative=false) at io/qtextstream.cpp:2220
 flags = 0
 dd = 0x7f8f9c010260
 result = {static null = {}, d = 0x7f8fe0f5bd60 
}
 numberFlags = {i = 0}
 base = 10
#3  0x7f8fe0ddc5f0 in QTextStream::operator<< (this=0x7f8f9c012420, 
i=15) at io/qtextstream.cpp:2296
 d = 0x7f8f9c0140e0
 __PRETTY_FUNCTION__ = "QTextStream& QTextStream::operator<<(int)"
#4  0x7f8fe17463e3 in QDebug::operator<< (this=0x7f8fc0df1cd0, t=15) 
at /opt/Qt/5.1.1/include/QtCore/qdebug.h:107
No locals.
#5  0x7f8fe17564f3 in Tufao::tDebug () at 
/home/zbenjamin/workspace.work/tufao/src/threadedhttprequestdispatcher.cpp:284
 t = 0xae1440
 __PRETTY_FUNCTION__ = "QDebug Tufao::tDebug()"
#6  0x7f8fe175c819 in Tufao::WorkerThreadControl::onRequestClosed 
(this=0x7f8fc0df2d50) at 
/home/zbenjamin/workspace.work/tufao/src/priv/workerthreadcontrol.cpp:46
No locals.
#7  0x7f8fe175c5bd in 
QtPrivate::FunctorCall, QtPrivate::List<>, 
void, void (Tufao::WorkerThreadControl::*)()>::call(void 
(Tufao::WorkerThreadControl::*)(), Tufao::WorkerThreadControl*, void**) 
(f=(void (Tufao::WorkerThreadControl::*)(Tufao::WorkerThreadControl * 
const)) 0x7f8fe175c800 , 
o=0x7f8fc0df2d50, arg=0x7f8fc0df1f30) at 
/opt/Qt/5.1.1/include/QtCore/qobjectdefs_impl.h:508
No locals.
#8  0x7f8fe175c550 in QtPrivate::FunctionPointer::call, void>(void 
(Tufao::WorkerThreadControl::*)(), Tufao::WorkerThreadControl*, void**) 
(f=(void (Tufao::WorkerThreadControl::*)(Tufao::WorkerThreadControl * 
const)) 0x7f8fe175c800 , 
o=0x7f8fc0df2d50, arg=0x7f8fc0df1f30) at 
/opt/Qt/5.1.1/include/QtCore/qobjectdefs_impl.h:527
No locals.
#9  0x7f8fe175c4bd in QtPrivate::QSlotObject, void>::impl(int, 
QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, 
this_=0x7f8f9c0132c0, r=0x7f8fc0df2d50, a=0x7f8fc0df1f30, ret=0x0) at 
/opt/Qt/5.1.1/include/QtCore/qobject_impl.h:147
No locals.
#10 0x7f8fe0ecc69b in QtPrivate::QSlotObjectBase::call 
(this=0x7f8f9c0132c0, r=0x7f8fc0df2d50, a=0x7f8fc0df1f30) at 
../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:130
No locals.
#11 0x7f8fe0ec9a02 in QMetaObject::activate (sender=0xc48dd0, 
signalOffset=3, local_signal_index=3, argv=0x0) at kernel/qobject.cpp:3471
 obj = {d = 0x7f8f9c0132c0}
 receiverInSameThread = true
 sw = {receiver = 0x7f8fc0df2d50, previousSender = 0x0, 
currentSender = {sender = 0xc48dd0, signal = 6, ref = 1}, switched = true}
 callFunction = 0x7f8f9c0132c0
 receiver = 0x7f8fc0df2d50
 method_relative = 0
 c = 0x7f8f9c011680
 last = 0x7f8f9c011680
 locker = {val = 140255935355400}
 connectionLists = {connectionLists = 0x1144920}
 list = 0xeeb188
 signal_index = 6
 empty_argv = {0x0}
 currentThreadId = 0x7f8fc0df3700
 __PRETTY_FUNCTION__ = "static void 
QMetaObject::activate(QObject*, int, int, void**)"
#12 0x7f8fe0ec934c in QMetaObject::activate (sender=0xc48dd0, 
m=0x7f8fe197e4a0 , 
local_signal_index=3, argv=0x0) at kernel/qobject.cpp:3354
No locals.
#13 0x7f8fe175d6c9 in Tufao::HttpServerRequest::close 
(this=0xc48dd0) at 
/home/zbenjamin/workspace.work/tufao-build/src/moc_httpserverrequest.cpp:193
No locals.
#14 0x7f8fe175d39c in Tufao::HttpServerRequest::qt_static_metacall 
(_o=0xc48dd0, _c=QMetaObject::InvokeMetaMethod, _id=3, 
_a=0x7f8fc0df2120) at 
/home/zbenjamin/workspace.work/tufao-build/src/moc_httpserverrequest.cpp:93
 _t = 0xc48dd0
#15 0x7f8fe0ec9afb in QMetaObject::activate (sender=0x11010b0, 

[Development] Qt's winrt port. Bringing it to dev and questions about networking

[Oliver Wolff]

Hi,

as some of you might have heard we are planning to get qtbase's winrt
branch integrated to dev in order to have a tech preview available at 
least for that part of Qt. In order to have it reviewed properly it 
would be awesome if some of you could have a look at the "winrt" topic
branch 
(https://codereview.qt-project.org/#q,status:open+project:qt/qtbase+branch:dev+topic:winrt,n,z)
and review changes there. Every other feedback is of course welcome as well.

We are still struggling with the network part of the code. I am
somewhat lost about how to activate socket notifiers for the port.
It looks like I can listen on ports and connect to servers but
example do not work. Neithger googlesuggest nor fortuneserver/-client
give any output. The WIP network change can be found here
https://codereview.qt-project.org/#change,64822 The approach to handling
sockets changed fundamentally so that mapping the options to the new
approach isn't always trivial.

The part I seem to be struggling with most is activating socket
notifiers as soon as something can be read from/written to a socket.
Handling of these events should done in qnativesocketengine_winrt.cpp 
(about line 417) but I don't know how to trigger something for the
notifiers from there. Ossi suggested to give the information about
data being available back to the event loop and have it handled there
but I could not find a way on how to do that. My issue basically seems
to be that the sockets do not know about their notifiers and I seem
unable to make a connection the other way around. Any input on that
problem would be highly appreciated :)

Thanks,
Olli

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] CI false positive.

[BogDan]

Hello,

    I'm trying to stage this https://codereview.qt-project.org/#change,64292 
patch, but CI complains that 2 files don't contain "a license header". But I'm 
pretty sure they do.
Some please help :) !

Cheers,
BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] CI false positive.

[Robin Burchell]

On Mon, Sep 9, 2013 at 3:21 PM, BogDan  wrote:
> I'm trying to stage this https://codereview.qt-project.org/#change,64292 
> patch, but CI complains that 2 files don't contain "a license header". But 
> I'm pretty sure they do.

At a guess, they are there, but aren't valid. Date ranges aren't
allowed by the license check script. There's a bug about this
somewhere in bugreports, but I don't have the time to go looking at
the moment.

BR,

Robin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QNetwork problem in threaded application.

[Shane Kearns]

moveToThread on a socket should do the following:
1. cancel socket notifiers
2. change thread affinity
3. (in new thread) re-enable socket notifiers.

Could be that step 1 doesn't remove already pending notifications when
using the gnome event dispatcher.

For a safe multithreaded server, you should pass the socket descriptor from
QTcpServer::incomingConnection to the thread that will handle that
connection.

See the note in
http://qt-project.org/doc/qt-5.0/qtnetwork/qtcpserver.html#incomingConnection


On 9 September 2013 10:32, Benjamin Zeller  wrote:

> Hello,
>
> i'm currently stress-testing a application at work and came across this
> problem.
> The application accepts connections and pushes the created sockets
> to a worker thread (moveToThread), the worker thread then handles the
> rest.
> But sometimes when the socket was already closed in the thread i
> get a SEGFAULT. It seems something in the mainthread tries to access
> the socket engine.
>
> After debugging it i saw that in the backtrace
> QCoreApplication::sendEvent is used, instead of postEvent.
>
>
>
>
> Backtrace Mainloop (stops in qabstractsocket.cpp line 741):
>
>  if (readSocketNotifierStateSet && socketEngine &&
>  >>readSocketNotifierState !=
> socketEngine->isReadNotificationEnabled()) {
>  socketEngine->setReadNotificationEnabled(readSocketNotifierState);
>  readSocketNotifierStateSet = false;
>  }
>  return true;
>
>
>
> In the Thread backtrace you can see the thread is closed
>  Backtrace Thread --
> Thread 17 (Thread 0x7f8fc0df3700 (LWP 5101)):
> #0  0x7f8fe0d397fd in QLocalePrivate::plus (this=0x7f8f9c010260) at
> tools/qlocale_p.h:228
> No locals.
> #1  0x7f8fe0d363a0 in QLocalePrivate::unsLongLongToString
> (this=0x7f8f9c010260, l=15, precision=-1, base=10, width=-1, flags=0) at
> tools/qlocale.cpp:3036
> No locals.
> #2  0x7f8fe0ddc0af in QTextStreamPrivate::putNumber
> (this=0x7f8f9c0140e0, number=15, negative=false) at io/qtextstream.cpp:2220
>  flags = 0
>  dd = 0x7f8f9c010260
>  result = {static null = {}, d = 0x7f8fe0f5bd60
> }
>  numberFlags = {i = 0}
>  base = 10
> #3  0x7f8fe0ddc5f0 in QTextStream::operator<< (this=0x7f8f9c012420,
> i=15) at io/qtextstream.cpp:2296
>  d = 0x7f8f9c0140e0
>  __PRETTY_FUNCTION__ = "QTextStream& QTextStream::operator<<(int)"
> #4  0x7f8fe17463e3 in QDebug::operator<< (this=0x7f8fc0df1cd0, t=15)
> at /opt/Qt/5.1.1/include/QtCore/qdebug.h:107
> No locals.
> #5  0x7f8fe17564f3 in Tufao::tDebug () at
>
> /home/zbenjamin/workspace.work/tufao/src/threadedhttprequestdispatcher.cpp:284
>  t = 0xae1440
>  __PRETTY_FUNCTION__ = "QDebug Tufao::tDebug()"
> #6  0x7f8fe175c819 in Tufao::WorkerThreadControl::onRequestClosed
> (this=0x7f8fc0df2d50) at
> /home/zbenjamin/workspace.work/tufao/src/priv/workerthreadcontrol.cpp:46
> No locals.
> #7  0x7f8fe175c5bd in
> QtPrivate::FunctorCall, QtPrivate::List<>,
> void, void (Tufao::WorkerThreadControl::*)()>::call(void
> (Tufao::WorkerThreadControl::*)(), Tufao::WorkerThreadControl*, void**)
> (f=(void (Tufao::WorkerThreadControl::*)(Tufao::WorkerThreadControl *
> const)) 0x7f8fe175c800 ,
> o=0x7f8fc0df2d50, arg=0x7f8fc0df1f30) at
> /opt/Qt/5.1.1/include/QtCore/qobjectdefs_impl.h:508
> No locals.
> #8  0x7f8fe175c550 in QtPrivate::FunctionPointer (Tufao::WorkerThreadControl::*)()>::call, void>(void
> (Tufao::WorkerThreadControl::*)(), Tufao::WorkerThreadControl*, void**)
> (f=(void (Tufao::WorkerThreadControl::*)(Tufao::WorkerThreadControl *
> const)) 0x7f8fe175c800 ,
> o=0x7f8fc0df2d50, arg=0x7f8fc0df1f30) at
> /opt/Qt/5.1.1/include/QtCore/qobjectdefs_impl.h:527
> No locals.
> #9  0x7f8fe175c4bd in QtPrivate::QSlotObject (Tufao::WorkerThreadControl::*)(), QtPrivate::List<>, void>::impl(int,
> QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1,
> this_=0x7f8f9c0132c0, r=0x7f8fc0df2d50, a=0x7f8fc0df1f30, ret=0x0) at
> /opt/Qt/5.1.1/include/QtCore/qobject_impl.h:147
> No locals.
> #10 0x7f8fe0ecc69b in QtPrivate::QSlotObjectBase::call
> (this=0x7f8f9c0132c0, r=0x7f8fc0df2d50, a=0x7f8fc0df1f30) at
> ../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:130
> No locals.
> #11 0x7f8fe0ec9a02 in QMetaObject::activate (sender=0xc48dd0,
> signalOffset=3, local_signal_index=3, argv=0x0) at kernel/qobject.cpp:3471
>  obj = {d = 0x7f8f9c0132c0}
>  receiverInSameThread = true
>  sw = {receiver = 0x7f8fc0df2d50, previousSender = 0x0,
> currentSender = {sender = 0xc48dd0, signal = 6, ref = 1}, switched = true}
>  callFunction = 0x7f8f9c0132c0
>  receiver = 0x7f8fc0df2d50
>  method_relative = 0
>  c = 0x7f8f9c011680
>  last = 0x7f8f9c011680
>  locker = {val = 140255935355400}
>  connectionLists = {connectionLists = 0x1144920}
>  list = 0xeeb188
>  signal_ind

Re: [Development] A QtCore class for event-driven jobs

[Sune Vuorela]

On 2013-09-09, Giuseppe D'Angelo  wrote:
> Indeed, but how about starting with an addon and then moving the
> classes inside QtCore? We can freely break API/ABI in addons -- when
> things get stabilized, we start including them in QTCore/QtNetwork...

I'm not sure what a addon containing 1 small class doing a multiple-year
long concept is going to be any good for. 

The api has been stabilized and well tested since like forever.

Let's get a QAbstractJob heavily inspired by KJob in now.

A nice side effect of getting it in now is that the myriad of nice
frameworks KDE is preparing for ship could be built on QAbstractJob and
KDE could skip shipping KJob and move everything over to QAbstractJob
now and not after we in KDE has made our first release where we promise
to keep ABI and API stability.

/Sune

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Development Digest, Vol 23, Issue 123

[Shane Kearns]

If you wanted to access a websocket service from native c++ or from QML
javascript, it would be quite hard to use webkit's implementation.
I expect you'd have to invoke some javascript inside the webkit engine to
do the request for you and get a result.

Websocket is an unpleasant workaround to the current state where many users
can only make outbound connections on TCP port 443, which prevents the TCP
ports being used as intended for multiplexing.


On 29 August 2013 00:51, Richard Gerd Kuesters wrote:

> **
>
> Thanks Kurt :)
>
> I've got some time today reading Qt 5.1.1 (and its Webkit) source code.
> What I found was a big mess :)
>
> I understand now that your implementation is valid, and I think it should
> continue as is until further notice. Unfortunately, there is already a
> websocket client implementation in Qt source code, in Webkit, provided by
> Google. I made some tests today and any call on Webkit using "wss*:\/\/" is
> not available to QNetwork, and ... Man, it would be a very, very huge
> effort to do it "in a flash". Even the most experienced C++ programmer
> wouldn't do it overnight, as you said.
>
> That brought me, otherwise, to the ultimate question: is the Qt community
> ready to start thinking about ripping this off the Webkit's webcore? If so,
> I'll be glad to help, somehow. // FYK, I just realized how intense your
> work was today, about 5 PM (local time), when I realized how much the
> Webkit code is a mess. A real, *real* mess; and I think that's why Shane
> (and other users) think your work must not stop. Now, it includes me :)
>
> Sorry if I made my assumptions just on top of Webkit, it is simply the
> module I use the most. I thought Qt was a little more uniform (assuming
> what they are requiring from you to make your websocket implementation
> initially an addon). I was terribly wrong :)
>
> Keep up your good work, I'm glad someone is carrying this with such
> enthusiasm!! :)
>
>
>
> My best regards,
>
> Richard.
>
>
>
> Em 2013-08-28 19:46, Kurt Pattyn escreveu:
>
>
>  On 29 Aug 2013, at 00:21, development-requ...@qt-project.org wrote:
>
>  *From: *Richard Gerd Kuesters 
> *Subject: **Re: [Development] [Feature Request] Websockets*
> *Date: *28 Aug 2013 19:28:11 GMT+02:00
> *To: *development@qt-project.org
>
> A couple of things got me thinking about the WebSocket implementation:
>
> 2. I believe that a websocket client would be directly attached to this
> network behaviour; it makes no sense to have a "headless" websocket in Qt -
> why not use a conventional socket? I think it might be useful, but just in
> some special cases. Other thing is: as I was looking into webkit source
> code, it already has a websocket client implementation. That brings another
> question: why is it there, after all? Why not in the network core?
>
> Hi Richard, this subject has been touched by Shane already. Indeed, you
> are right that this should be integrated into the QtNetwork module. But, a
> web socket is not just a socket, it is a tcp socket that is upgraded, after
> a handshake to a web socket. According to Shane, it is not that easy to
> integrate this into the current code.
> It has been decided, to put this code into the playground, so that
> 1. it at least integrates nicely with the Qt infrastructure
> 2. it is thoroughly reviewed and tested
> 3. we can wait and see what the demand is for this
> I can understand that turning the network module upside down to add some
> feature, is not something that is done overnight.
> Eventually, it can become an add-on or an integral part of the network
> module.
>
>  3. About the websocket server: it is, in fact, a new implementation for
> Qt.
>
> Yes, it is. Depending on how 'high' Qt wants to evolve, I don't see a
> reason why it wouldn't fit. Personally, I see it as an opportunity,
> especially for embedded devices that are more and more controlled via web
> browsers (at least, that is what I am using it for). Having a web socket
> server in there, could dramatically enhance the possibilities (monitoring,
> notifications, aso). But then there is of course node.js also.
>
>
> I'm not trying to be a pain in the a**, just the devil's advocate, random
> thoughts on the direction this intend to go.
>
>  It doesn't hurt. Discussion is sane, and questions are for free.
> Kurt
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Development Digest, Vol 23, Issue 123

[Richard Gerd Kuesters]

Thanks Shane! I'm aware of the workaround, I just didn't know that 
Webkit's WS implementation was not bound to the QNetworkAccessManager. 
With a little source code reading, I think it would not be possible to 
manage network connection from an unique entry point to all my Qt based 
apps. I'll have to address it any other way :)


Best regards,
Richard.

On 09/09/2013 02:45 PM, Shane Kearns wrote:
If you wanted to access a websocket service from native c++ or from 
QML javascript, it would be quite hard to use webkit's implementation.
I expect you'd have to invoke some javascript inside the webkit engine 
to do the request for you and get a result.


Websocket is an unpleasant workaround to the current state where many 
users can only make outbound connections on TCP port 443, which 
prevents the TCP ports being used as intended for multiplexing.



On 29 August 2013 00:51, Richard Gerd Kuesters 
mailto:rich...@humantech.com.br>> wrote:


Thanks Kurt :)

I've got some time today reading Qt 5.1.1 (and its Webkit) source
code. What I found was a big mess :)

I understand now that your implementation is valid, and I think it
should continue as is until further notice. Unfortunately, there
is already a websocket client implementation in Qt source code, in
Webkit, provided by Google. I made some tests today and any call
on Webkit using "wss*:\/\/" is not available to QNetwork, and ...
Man, it would be a very, very huge effort to do it "in a flash".
Even the most experienced C++ programmer wouldn't do it overnight,
as you said.

That brought me, otherwise, to the ultimate question: is the Qt
community ready to start thinking about ripping this off the
Webkit's webcore? If so, I'll be glad to help, somehow. // FYK, I
just realized how intense your work was today, about 5 PM (local
time), when I realized how much the Webkit code is a mess. A real,
*real* mess; and I think that's why Shane (and other users) think
your work must not stop. Now, it includes me :)

Sorry if I made my assumptions just on top of Webkit, it is simply
the module I use the most. I thought Qt was a little more uniform
(assuming what they are requiring from you to make your websocket
implementation initially an addon). I was terribly wrong :)

Keep up your good work, I'm glad someone is carrying this with
such enthusiasm!! :)

My best regards,

Richard.

Em 2013-08-28 19:46, Kurt Pattyn escreveu:



On 29 Aug 2013, at 00:21, development-requ...@qt-project.org
 wrote:


*From:*Richard Gerd Kuesters mailto:rich...@humantech.com.br>>
*Subject:**Re: [Development] [Feature Request] Websockets*
*Date:*28 Aug 2013 19:28:11 GMT+02:00
*To:*development@qt-project.org 

A couple of things got me thinking about the WebSocket
implementation:

2. I believe that a websocket client would be directly attached
to this network behaviour; it makes no sense to have a
"headless" websocket in Qt - why not use a conventional socket?
I think it might be useful, but just in some special cases.
Other thing is: as I was looking into webkit source code, it
already has a websocket client implementation. That brings
another question: why is it there, after all? Why not in the
network core?

Hi Richard, this subject has been touched by Shane already.
Indeed, you are right that this should be integrated into the
QtNetwork module. But, a web socket is not just a socket, it is a
tcp socket that is upgraded, after a handshake to a web socket.
According to Shane, it is not that easy to integrate this into
the current code.
It has been decided, to put this code into the playground, so that
1. it at least integrates nicely with the Qt infrastructure
2. it is thoroughly reviewed and tested
3. we can wait and see what the demand is for this
I can understand that turning the network module upside down to
add some feature, is not something that is done overnight.
Eventually, it can become an add-on or an integral part of the
network module.


3. About the websocket server: it is, in fact, a new
implementation for Qt.

Yes, it is. Depending on how 'high' Qt wants to evolve, I don't
see a reason why it wouldn't fit. Personally, I see it as an
opportunity, especially for embedded devices that are more and
more controlled via web browsers (at least, that is what I am
using it for). Having a web socket server in there, could
dramatically enhance the possibilities (monitoring,
notifications, aso). But then there is of course node.js also.


I'm not trying to be a pain in the a**, just the devil's
advocate, random thoughts on the direction this intend to go.

It doesn't hurt. Discussion is sane, and questions are for free.
Kurt


_

Re: [Development] A QtCore class for event-driven jobs

[Thiago Macieira]

On segunda-feira, 9 de setembro de 2013 19:38:20, David Faure wrote:
> I still think the best solution is:
> QtCore: QAbstractJob, and later QProcessJob and QThreadJob
> QtNetwork: QNetworkRequestJob (wrapping QNetworkReply)
> QtDBus: (later) QDBusCallJob (wrapping QDBusPendingCallWatcher)
> 
> The latter is another reason why a QtJobs library wouldn't work. In order
> to  provide an async-dbus-call job, it would have to link to QDBus, forcing
> a QDBus dependency onto every user of core-only jobs like QThreadJob.
> 
> Looking at my initial email, I think that's all. There isn't going to be 20 
> more job classes in qt itself, the only async operations that happen in
> there are all on top of sockets, processes and threads.
> (and timers, but a QTimerJob isn't terribly useful

Let's start with a playground to develop the idea and the API. You can freely 
separate the directories with corelib, network, dbus, eyeing for an eventual 
separation later.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


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] A QtCore class for event-driven jobs

[Giuseppe D'Angelo]

On 9 September 2013 19:38, David Faure  wrote:
>
>
> I understand that you want to limit the growth of QtCore, but, hmm, a separate
> library/module QtJobs seems very strange. It's not like it's separate
> technology, the core of QAbstractJob's technology is the QtCore event loop.
> Can you see yourself at the next Dev Days presenting the Qt modules with
> "Qt Core, Qt Gui, Qt Network, Qt Multimedia and ... Qt Jobs" ? It doesn't fit
> that list, because it's not a separate technology with separate dependencies.

Indeed, but how about starting with an addon and then moving the
classes inside QtCore? We can freely break API/ABI in addons -- when
things get stabilized, we start including them in QTCore/QtNetwork...
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A QtCore class for event-driven jobs

[David Faure]

On Friday 06 September 2013 17:20:59 Thiago Macieira wrote:
> On sexta-feira, 6 de setembro de 2013 19:52:47, David Faure wrote:
> > * relation to QNetworkReply?
> > If that one didn't exist yet, we'd definitely write it as a QJob subclass.
> > So  instead, I propose to wrap QNetworkReply into a QNetworkJob or
> > something, in order to offer the QJob interface for QNAM requests. On one
> > hand this doesn't have to go in at the same time as QJob itself, but OTOH
> > it could be a real- world testcase for it, proving its usefulness and
> > correctness...
> > 
> > Any other questions?
> 
> What if we put the QJob class and convenience derived classes like
> QNetworkRequestJob, QProcessJob, QThreadJob, etc. in one new library.
> 
> This library could be extended later with more job types.

I understand that you want to limit the growth of QtCore, but, hmm, a separate 
library/module QtJobs seems very strange. It's not like it's separate 
technology, the core of QAbstractJob's technology is the QtCore event loop.
Can you see yourself at the next Dev Days presenting the Qt modules with
"Qt Core, Qt Gui, Qt Network, Qt Multimedia and ... Qt Jobs" ? It doesn't fit 
that list, because it's not a separate technology with separate dependencies.

In addition, this prevents using these job classes within Qt itself:
if QNetworkReply didn't exist yet, and if QAbstractJob was in QtCore already, 
then surely we'd call it QNetworkRequestJob and make it derive QAbstractJob, 
and we'd put that in QtNetwork. The only reason we got QNetworkReply instead 
is that QAbstractJob didn't exist yet.
By putting the jobs "on top of everything else", we will always have the 
QNetworkReply/QNetworkRequestJob redundancy everywhere a Qt API would benefit 
from returning a job class.

I still think the best solution is:
QtCore: QAbstractJob, and later QProcessJob and QThreadJob
QtNetwork: QNetworkRequestJob (wrapping QNetworkReply)
QtDBus: (later) QDBusCallJob (wrapping QDBusPendingCallWatcher)

The latter is another reason why a QtJobs library wouldn't work. In order to 
provide an async-dbus-call job, it would have to link to QDBus, forcing a 
QDBus dependency onto every user of core-only jobs like QThreadJob.

Looking at my initial email, I think that's all. There isn't going to be 20 
more job classes in qt itself, the only async operations that happen in there 
are all on top of sockets, processes and threads.
(and timers, but a QTimerJob isn't terribly useful ;)

-- 
David Faure | david.fa...@kdab.com | Managing Director KDAB France
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] A QtCore class for event-driven jobs

[Konstantin Ritt]

2013/9/9 Sune Vuorela 

> The api has been stabilized and well tested since like forever.
>
> Let's get a QAbstractJob heavily inspired by KJob in now.
>
> A nice side effect of getting it in now is that the myriad of nice
> frameworks KDE is preparing for ship could be built on QAbstractJob and
> KDE could skip shipping KJob and move everything over to QAbstractJob
> now and not after we in KDE has made our first release where we promise
> to keep ABI and API stability.
>
>
That's indeed what I was afraid of. Your goal is KJob in Qt 5.2 so you can
use it by only linking to QtCore.
Once released, it's API become frozen up until 6.0...and you don't really
care about all others who may disagree with it's design or simply can not
use it due to it's limited API and so on.
All I've seen so far (following by David's links) is a piece of KIO where
some API is still hardcoded to be used by KIO. I'd say this is not a 5.2
material at all.

Let us see those nice QProcessJob and/or QThreadJob, that QDBusCallJob...or
usable drafts at very least.
Until then, I'm all in doubts about how useful would that be to the user.
In example, David said job's doStart() enqueues the runnable in the thread
pool; now looking at the code - it seems like we could have then
"started()" signal emitted, say, 5 seconds earlier than the runnable gets
dequeued and executed. So `for (int i = 0; i < 100; ++i) (job =
someoperation(params))->start();` gives us 100 "started" jobs where only
few of them got dequeued and really started; and thus all other jobs can
not report their actual execution state change because they were "started"
and become "started", once dequeued by worker thread...weird, isn't it?

First of all, put the initial implementation to Qt-project as a module.
Let's then gather such a use-cases and see where the current API is not
sufficient, then polish the API to make QJob usable in all those cases;
let's write some QJob-s based demonstration framework and polish the API
once again, if needed... and only then we'll see if it is good enough for
QtCore.

Kind regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A QtCore class for event-driven jobs

[Knoll Lars]

Full agreement with Konstantin. It's two weeks before the feature freeze and we 
haven't seen any more then a draft. I am against any new classes going into Qt 
essential modules that do not have direct and proven use cases.

Develop it in a playground project, show why it makes sense and once you have a 
stable API let's discuss into which module it should go.

Cheers,
Lars

From: Konstantin Ritt mailto:ritt...@gmail.com>>
Date: tirsdag 10. september 2013 00:40
To: "development@qt-project.org" 
mailto:development@qt-project.org>>
Subject: Re: [Development] A QtCore class for event-driven jobs


2013/9/9 Sune Vuorela mailto:nos...@vuorela.dk>>
The api has been stabilized and well tested since like forever.

Let's get a QAbstractJob heavily inspired by KJob in now.

A nice side effect of getting it in now is that the myriad of nice
frameworks KDE is preparing for ship could be built on QAbstractJob and
KDE could skip shipping KJob and move everything over to QAbstractJob
now and not after we in KDE has made our first release where we promise
to keep ABI and API stability.


That's indeed what I was afraid of. Your goal is KJob in Qt 5.2 so you can use 
it by only linking to QtCore.
Once released, it's API become frozen up until 6.0...and you don't really care 
about all others who may disagree with it's design or simply can not use it due 
to it's limited API and so on.
All I've seen so far (following by David's links) is a piece of KIO where some 
API is still hardcoded to be used by KIO. I'd say this is not a 5.2 material at 
all.

Let us see those nice QProcessJob and/or QThreadJob, that QDBusCallJob...or 
usable drafts at very least.
Until then, I'm all in doubts about how useful would that be to the user.
In example, David said job's doStart() enqueues the runnable in the thread 
pool; now looking at the code - it seems like we could have then "started()" 
signal emitted, say, 5 seconds earlier than the runnable gets dequeued and 
executed. So `for (int i = 0; i < 100; ++i) (job = 
someoperation(params))->start();` gives us 100 "started" jobs where only few of 
them got dequeued and really started; and thus all other jobs can not report 
their actual execution state change because they were "started" and become 
"started", once dequeued by worker thread...weird, isn't it?

First of all, put the initial implementation to Qt-project as a module.
Let's then gather such a use-cases and see where the current API is not 
sufficient, then polish the API to make QJob usable in all those cases; let's 
write some QJob-s based demonstration framework and polish the API once again, 
if needed... and only then we'll see if it is good enough for QtCore.

Kind regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Platform Extras

[Knoll Lars]

Ok, let's use QtWin for the namespace. For the module itself it makes IMO
to keep the 'Extras' in the name.

Cheers,
Lars

On 06.09.13 15:52, "Sorvig Morten"  wrote:

>I agree, QtWin::foo looks much better. We can rename the QtMacExtras
>namespace as well.
>
>What about the module name itself? Would we still say "import
>QtWinExtras" and "#include "?
>
>Morten
>
>On Sep 6, 2013, at 11:49 AM, Nurmi J-P  wrote:
>
>> I also very much like the idea of sticking the conversion functions
>>right into the respective classes in QtCore and QtGui.
>> 
>> At least QtWinExtras still has lots of helper methods that do not fall
>>into this category, though. All that Windows specific window blurring,
>>peeking, colorization etc. stuff will remain in QtWinExtras, and I'd
>>still prefer QtWin as the namespace for those methods.
>> 
>> So my original question still remains valid - can we rename the
>>QtPlatformExtras namespaces to QtPlatform? Friedemann already prepared
>>the first step for QtWinExtras:
>>https://codereview.qt-project.org/#change,64803.
>> 
>> --
>> J-P Nurmi
>> 
>> On Sep 4, 2013, at 2:35 PM, Tor Arne Vestbø 
>>wrote:
>> 
>>> Yes yes a thousand times yes!
>>> 
>>> On 9/3/13 14:41 , Sorvig Morten wrote:
 I think the advantages of having these functions available in
QtCore/Gui outweighs the risk of customers accidentally using
platform-dependent code. Maintenance will be easier since there is
less code duplication.
 
 Morten
 
 On Sep 2, 2013, at 11:38 PM, Joseph Crowell
 wrote:
 
> Most of the functionality was already in Qt 4 and was moved out for
>Qt 5
> because of maintenance issues and different code for different
>platforms
> exposed to the customer.
> 
> On 02/09/2013 10:35 PM, Sorvig Morten wrote:
>> I agree the "Extra" looks superfluous. In fact I'd like to go a bit
>>further and suggest we don't have platform extras at all and instead
>>integrate the functionality into Qt:
>> 
>> - Conversion functions for types in QtCore to QtCore
>> - Conversion functions for types in QtGui to QtGui
>> - Widgets to QtWidgets
>> - Non-trivial implementation to the platform plugin
>> - etc.
>> 
>> I've prepared a set of patches showing how (for parts of
>>QtMacExtras):
>> 
>> https://codereview.qt-project.org/64342
>> https://codereview.qt-project.org/64343
>> https://codereview.qt-project.org/64344
>> https://codereview.qt-project.org/64345
>> https://codereview.qt-project.org/64346
>> 
>> Notes:
>> - The platform extras will continue to exist as research
>>playgrounds.
>> - This approach works for platforms that has an Q_OS #define
>> - The function header is named "qmacfunctions.h",  the namespace is
>>"QMac"
>> - We can now use the public NSString conversion functions in QtCore
>>when implementing rest of Qt.
>> - Conversion functions in QtCore And Gui can be used without
>>bringing in QtMacExtras and its widgets dependency
>> 
>> One case is still unsolved: classes that wrap native UI elements
>>but are neither widgets nor Qt Quick Items. (Mac native tool bar and
>>windows task bar for example). A possible solution could be to add
>>the implementation to the platform plugin and add public API in
>>QtWidgets and Qt Quick Controls. QMacNativeWidget and
>>QMacCocoaViewContainer are done this way now, and are basically API
>>wrappers around the implementation in QCococaWindow.
>> 
>> Morten
>> 
>> 
>> On Aug 30, 2013, at 3:27 PM, Jake Petroules
>> wrote:
>> 
>>> +1 from me for doing it everywhere, including in the library names.
>>> --
>>> Jake Petroules
>>> Chief Technology Officer
>>> Petroules Corporation · www.petroules.com
>>> Email: jake.petrou...@petroules.com
>>> 
>>> On Aug 30, 2013, at 9:17 AM, Nurmi J-P  wrote:
>>> 
 Hi all,
 
 While we still have a chance to tweak things before releasing
5.2, I'd like to re-open the discussion about platform extras
naming.
 
 Short version:
 
 Could we rename the QtMacExtras & QtWinExtras namespaces to just
QtMac & QtWin? (QtX11Extras namespace doesn't exist, at least yet)
 
 Long version:
 
 The current status:
 
 - Classes: QPlatformFoo
 - QX11Info (*)
 - QMacNativeWidget, ...
 - QWinTaskbarButton, ...
 
 (*) The only thing in QtX11Extras - already released in Qt 5.1.
 
 - Stand-alone function namespaces: QtPlatformExtras::toType()
 - QtWinExtras::toHBITMAP(), ...
 - QtMacExtras::toCGImageRef(), ...
 
 
 I'm not entirely happy with how the current stand-alone function
namespaces look in application code. I would find it prettier if
we dropped the "Extras" pa