Review Request 113205: Make KJob::result public for the new signal/slot syntax.

[Mark Gaiser]

On Oct. 11, 2013, 9:51 p.m., Mark Gaiser wrote:
> > We are here making a 'hole' for people to do  'bad things' that wasn't possible in the past. I'm not sure we want that.

Interesting.
So that mean we simply can't use the new signal/slot syntax because of it? That would seem rather strange to me..

If you do a stat call, or listEntry or <any of the others>...
Then you are supposed to connect to the result slot. For listEntry you are supposed to connect to the finished signal. Both of those are defined as:
signals:
private:

AKA. Private signals.
I really don't see how you can work around this besides perhaps QSignalMapper, but that would be very odd as well. I'm really curious to see how that "bit of magic" is supposed to work. Do you have some links for me there?


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113205/#review41570
-----------------------------------------------------------


On Oct. 11, 2013, 5:59 p.m., Mark Gaiser wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113205/
> -----------------------------------------------------------
> 
> (Updated Oct. 11, 2013, 5:59 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> 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 
> 
> Diff: http://git.reviewboard.kde.org/r/113205/diff/
> 
> 
> Testing
> -------
> 
> Works just fine.
> 
> 
> Thanks,
> 
> Mark Gaiser
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20131011/70b8aecb/attachment.htm>
-------------- next part --------------
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel at kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel