----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/#review41670 -----------------------------------------------------------
Why do it just for result and not finished, suspended, resumed? We end up with both mechanisms for private signals in the same header otherwise. - Kevin Ottens On Oct. 12, 2013, 6:30 p.m., Mark Gaiser wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113205/ > ----------------------------------------------------------- > > (Updated Oct. 12, 2013, 6:30 p.m.) > > > Review request for KDE Frameworks, kdelibs, David Faure, and Kevin Ottens. > > > Repository: kdelibs > > > Description > ------- > > The new signal/slot connection: > connect(job, &KJob::result,... > > does't like result to be private and throws an compile error: > error: 'void KJob::result(KJob*)' is private > > Making it public resolves the issue and makes this slot usable in the new > syntax. In my case i wanted to use the new syntax and directly use a lambda > as slot. Which isn't possible on this signal if it isn't public. > > > Diffs > ----- > > tier1/kcoreaddons/src/lib/jobs/kjob.h d663530 > tier1/kcoreaddons/src/lib/jobs/kjob.cpp f99a99f > > Diff: http://git.reviewboard.kde.org/r/113205/diff/ > > > Testing > ------- > > Works just fine. > > > Thanks, > > Mark Gaiser > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
