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 <m...@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 m...@milianw.de http://milianw.de