ThreadWeaver: using QObject's as Jobs

[Milian Wolff]

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:
> http://en.wikipedia.org/wiki/Decorator_pattern
> 
> 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
{
  Q_OBJECT
public:
  MyJob(QObject *parent)
    : 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.

Bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de