Review Request 115016: Make KJob usable from QML

[Aurélien Gâteau]

On Wed, Jan 15, 2014, at 4:43, Kevin Krammer wrote:
> On Tuesday, 2014-01-14, 23:12:56, Aurélien Gâteau wrote:
> > > On Jan. 14, 2014, 9:20 p.m., Alex Merry wrote:
> > > > src/lib/jobs/kjob.h, line 92
> > > > <https://git.reviewboard.kde.org/r/115016/diff/1/?file=233991#file233991
> > > > line92>> > 
> > > >     I don't think this will work; I'm fairly sure that notify signals
> > > >     must have zero or one arguments, and the one argument must be the
> > > >     same type as the property.  The notify signal in this class has a
> > > >     preceding KJob* argument.> 
> > > Aleix Pol Gonzalez wrote:
> > >     Quoting the documentation:
> > >     "A NOTIFY signal is optional. If defined, it should specify one
> > >     existing signal in that class that is emitted whenever the value of
> > >     the property changes."
> > >     
> > >     Also I've been using this in a plasmoid I'm porting and it doesn't
> > >     seem to cause problems.
> > Quoting the *Qt 5* documentation:
> > (http://doc-snapshot.qt-project.org/qt5-stable/properties.html)
> > 
> > A NOTIFY signal is optional. If defined, it should specify one existing
> > signal in that class that is emitted whenever the value of the property
> > changes. NOTIFY signals for MEMBER variables must take zero or one
> > parameter, which must be of the same type as the property. The parameter
> > will take the new value of the property.
> > 
> > The fix is probably just a matter of introducing a "void
> > percentChanged(int)" signal, and emitting it wherever percent() is emitted.
> 
> No need, the percent property is not using the MEMBER option of the
> Q_PROPERY 
> macro, it is using the classic READ followed by getter function approach.

Oh, good point. I missed the "MEMBER" part (actually I didn't even know
about MEMBER properties, one always learns!)

Aurélien