ThreadWeaver: using QObject's as Jobs
mail at milianw.de
Tue Nov 25 11:14:49 GMT 2014
On Monday 24 November 2014 23:00:45 Mirko Boehm wrote:
> Hi Milian!
> Man, I totally thought this is absolutely intuitive :-) I will write
> something up as a blog post over the weekend. In the meantime, I am trying
> to answer your question below.
> > On 24 Nov 2014, at 01:57, Milian Wolff <mail at milianw.de> wrote:
> > Could you please document, e.g. by adding another example, on how one is
> > supposed to use Job classes that are QObjects, i.e. have signals/slots?
> > There is this strange QObjectDecorator thingy which I don't quite get, it
> > looks like its supposed to add some signals to another job. But what if
> > my job already is a QObject, since it has its own signals that it emits
> > when data is received? Can I inherit from QObjectDecorator and pass
> > "this" as the JobInterface *decoratee?
> The decorator wraps and object and acts as a QObject. It does not really
> care if the wrapped job is a QObject already. It will add defined signals
> to the job.
> There are two ways to use it: The decorator can be used to wrap another job
> without defining a new class. Or it can be inherited to give the result a
> new name. By default it assumes that it owns the wrapped object, this can
> be turned off in the constructor.
> Decorators act like Matroska puppets, multiple decorators can be stacked.
> They are the proxy models of jobs :-) The additional complexity in C++ is
> that if the decoratee is not a shared pointer, it needs to be memory
> managed. The concept is explained here:
> Hope this helps,
Yes, I know the decorator pattern, that's fine. But I wonder about how to use
job classes with their own signals. Inheriting from the QObjectDecorator leads
to an infinite recursion in ::status for me. This is what I tried:
class MyJob : public ThreadWeaver::QObjectDecorator
: QObjectDecorator(this, parent)
So if I understand you correctly, I'll have to use the second ctor, but still
- what do I pass as decoratee? nullptr? It's completely undocumented and not
clear at all.
I now resorted to copying the signals and implementation of defaultBegin/End,
adapted to my usecae, into the job class. This works, but I really think it
should become simpler. I don't want to decorate anything after all. I just
want a QObject job, with custom signals _and_ those of the decorator. Having
that in two objects is useless bloat I'll refrain from coding up.
mail at milianw.de
More information about the kde-core-devel