> On Jan. 14, 2014, 8:20 p.m., Alex Merry wrote: > > src/lib/jobs/kjob.h, line 92 > > <https://git.reviewboard.kde.org/r/115016/diff/1/?file=233991#file233991line92> > > > > 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.
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. - Aleix ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115016/#review47395 ----------------------------------------------------------- On Jan. 14, 2014, 8:16 p.m., Aleix Pol Gonzalez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115016/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2014, 8:16 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kcoreaddons > > > Description > ------- > > Add a couple of Q_PROPERTY and Q_SCRIPTABLE to KJob, so that it can be > consumed elsewhere. The idea isn't to be able to implement KJobs, but to be > able to keep track of them from QML and check if it succeeded. > > > Diffs > ----- > > src/lib/jobs/kjob.h 24dbaec > > Diff: https://git.reviewboard.kde.org/r/115016/diff/ > > > Testing > ------- > > Everything still builds, shouldn't be a big deal. > > > Thanks, > > Aleix Pol Gonzalez > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
