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, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist Request a meeting: https://doodle.com/mirkoboehm
