Re: ThreadWeaver: using QObject's as Jobs
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
Re: ThreadWeaver: using QObject's as Jobs
On Tuesday 25 November 2014 12:07:27 Milian Wolff wrote: On Monday 24 November 2014 19:28:57 Thiago Macieira wrote: On Monday 24 November 2014 23:00:45 Mirko Boehm wrote: 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. Please don't create new classes named Q + Capital letter unless you're doing that inside the Qt Project. This object lives in the ThreadWeaver namespace, so that should be fine, no? It's decorating a QObject after all. Ah, then it's ok. It's the global namespace that's a problem. As long as no one builds Qt with -qtnamespace ThreadWeaver :-) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: ThreadWeaver: using QObject's as Jobs
On 25 Nov 2014, at 04:28, Thiago Macieira thi...@kde.org wrote: 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. Please don't create new classes named Q + Capital letter unless you're doing that inside the Qt Project. Yeah, I noticed that a little too late. It is already released, but I am thinking about renaming it and deprecating the original class. Cheers, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist Request a meeting: https://doodle.com/mirkoboehm
Re: ThreadWeaver: using QObject's as Jobs
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
Re: ThreadWeaver: using QObject's as Jobs
On Monday 24 November 2014 23:00:45 Mirko Boehm wrote: 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. Please don't create new classes named Q + Capital letter unless you're doing that inside the Qt Project. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
ThreadWeaver: using QObject's as Jobs
Hey All, esp. Mirko. 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? Bye -- Milian Wolff m...@milianw.de http://milianw.de
