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 QUniquePoiner implementation: Couldn't we add a new branch to dev/stable/release, which is open for very experimental code? Creating a playground project just for one class is too complicated, and most people would not give them a try, but only switching a branch lowers the barrier a lot. We could base the branch on stable, so it is a good starting point for experiments, and it would be easy to try out these new features without the hassle of checking out (multiple) other repositories, or by cherry-picking stuff. Peter > > Cheers, > Lars > > From: Konstantin Ritt <ritt...@gmail.com <mailto:ritt...@gmail.com>> > Date: tirsdag 10. september 2013 00:40 > To: "development@qt-project.org <mailto:development@qt-project.org>" > <development@qt-project.org <mailto:development@qt-project.org>> > Subject: Re: [Development] A QtCore class for event-driven jobs > > > 2013/9/9 Sune Vuorela <nos...@vuorela.dk <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 > _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
