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

nt@qt-project.org Subject: Re: [Development] A QtCore class for event-driven jobs On Saturday 07 September 2013 00:55:26 Konstantin Ritt wrote: > Simply can not ignore this thread :) > Like Andre, I have written my own jobs implementation, too. > And I completely agree that not having so

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

On Tuesday 17 September 2013 15:08:15 Buddenhagen Oswald wrote: > agreed, but for the same reason composite jobs are a non-starter: they are > managers with unlimited potential for scheduling policy api growth. Don't > go there. Very different; composite jobs are an optional feature useful as an

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

Thanks Marc, that's exactly what I was saying about. The only difference is (seems to be) a user-visible "manager" that "owns" (or let's say "locks") the task up until it gets processed so no deletion may occur in the middle of execution, i.e. What the manager is and where/how it executes the task

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

On 2013-09-12 08:07, André Somers wrote: > Op 11-9-2013 17:19, David Faure schreef: >>> Couldn't such a class be part of the hopefully coming QtConcurrent >>> replacement? >> Can we forget about threads for a second? > No, I'd rather not forget that huge pink elephant in the room... In > this > ag

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

AFAIK, nesting event loops should be used with a great carefulness and in very limited set of cases, since it may break the expected order of event handling, i.e. when used as a signal waiter. Dunno if this changed since Qt 4.x, though. Regards, Konstantin 2013/9/12 André Somers > Op 11-9-2013

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

Op 11-9-2013 17:19, David Faure schreef: >> Couldn't such a class be part of the hopefully coming QtConcurrent >> replacement? > Can we forget about threads for a second? No, I'd rather not forget that huge pink elephant in the room... In this age of multi-core systems being the norm rather than e

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

On Tuesday 10 September 2013 21:09:55 Peter Kümmel wrote: > On 06.09.2013 19:52, David Faure wrote: > > connect(job, SIGNAL(result(QJob*)), > > this, SLOT(handleResult(QJob*))); > > This looks so old-school like in times of futures and monads. I'm an old-timer, clearly ;-) > Coul

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

On terça-feira, 10 de setembro de 2013 21:01:51, Peter Kümmel wrote: > On 10.09.2013 08:16, Knoll Lars wrote: > > 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. > An idea I already had when I saw the QUniq

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

september 2013 00:40 > To: "development@qt-project.org <mailto: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>> &g

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

On 06.09.2013 19:52, David Faure wrote: > > connect(job, SIGNAL(result(QJob*)), > this, SLOT(handleResult(QJob*))); This looks so old-school like in times of futures and monads. Couldn't such a class be part of the hopefully coming QtConcurrent replacement? Peter ___

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

On Mon, Sep 9, 2013 at 11:40 PM, Konstantin Ritt wrote: > > 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 >> frame

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

oject.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

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

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 >

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

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 QN

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

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 you

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

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

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

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 cl

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

Simon Fra: David Faure Sendt: 19:47 fredag 6. september 2013 Til: development@qt-project.org Emne: [Development] A QtCore class for event-driven jobs I would like to propose the inclusion of a QJob class in QtCore, based on years of experience with KIO::Job and KJob. The idea is to encapsu

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

On Sun, Sep 8, 2013 at 3:06 AM, Aleix Pol wrote: > Either that or not rushing into porting everything to QJob. Having it in a > separate library would mean having QtCoreJobs, QtNetworkJobs, etc. Doesn't > seem to be very flexible. > I also think it makes sense to have a separate playground modul

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

On Sat, Sep 7, 2013 at 2:20 AM, 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 QNet

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

On Saturday 07 September 2013 00:55:26 Konstantin Ritt wrote: > Simply can not ignore this thread :) > Like Andre, I have written my own jobs implementation, too. > And I completely agree that not having some kind of job manager makes QJob > API of quite limited usefulness I disagree. One can cho

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

On Friday 06 September 2013 22:22:20 Andre Somers wrote: > . However, I'd hope the design would > not limit itself to just event-driven jobs, if I understand correctly > what that means. Some of my jobs are just heavy processing that require > multi-threading. That sounds more like QRunnable t

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

On Friday 06 September 2013 13:56:51 Matt Broadstone wrote: > Is this code up somewhere already for early review? This is very much > needed in Qt imho, I imagine it's one of those patterns that people roll > themselves in many cases. The current code is at https://projects.kde.org/projects/kde/k

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

On Sat, 7 Sep 2013, Konstantin Ritt wrote: one would probably prefer [code] job =  someoperation(some parameters); manager->enqueue(job); [/code] , where "someoperation" could be manager's registered job factory or QJob sub-class, etc. I am not sure why everyone prefers to have a "manager" ;

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

I think it is a good idea to introduce a playground module until we have the API clean and stable, and then we might want to include it right into QtCore. Regards, Konstantin 2013/9/7 Thiago Macieira > On sexta-feira, 6 de setembro de 2013 19:52:47, David Faure wrote: > > * relation to QNetwor

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

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 Q

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

On Fri, Sep 6, 2013 at 1:52 PM, David Faure wrote: > I would like to propose the inclusion of a QJob class in QtCore, based on > years of experience with KIO::Job and KJob. > > The idea is to encapsulate an event driven asynchronous operation into a > job > class. Example use cases: > - a network

[Development] A QtCore class for event-driven jobs

I would like to propose the inclusion of a QJob class in QtCore, based on years of experience with KIO::Job and KJob. The idea is to encapsulate an event driven asynchronous operation into a job class. Example use cases: - a network download with QNetworkAccessManager. - operations (command+repl

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

Simply can not ignore this thread :) Like Andre, I have written my own jobs implementation, too. And I completely agree that not having some kind of job manager makes QJob API of quite limited usefulness (and like David mentioned earlier, QNetworkReply is a QNAM's "job", where QNAM is indeed a mana

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

Op 6-9-2013 19:56, Matt Broadstone schreef: On Fri, Sep 6, 2013 at 1:52 PM, David Faure > wrote: I would like to propose the inclusion of a QJob class in QtCore, based on years of experience with KIO::Job and KJob. The idea is to encapsulate an event