Review Request: Use invokeMethod to call job slots instead of emitting a signal

[Laszlo Papp]

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


I think you can close this request according to the discussion happened this morning on IRC among us. Just for book keeping and for public, this does not address or/and solve the issue of hiding the private slots from the public. The "fe4b827" solved that issue in master.

- Laszlo


On July 8, 2011, 6:30 a.m., Shantanu Tushar Jha wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101879/
> -----------------------------------------------------------
> 
> (Updated July 8, 2011, 6:30 a.m.)
> 
> 
> Review request for Gluon.
> 
> 
> Summary
> -------
> 
> When I saw Arjen's comment on the start*ing signals Laszlo devised to call the Job slots when the provider was ready, I suddenly realised that its better to use QMetaObject::invokeMethod to call the slots, instead of emitting a signal whose sole purpose was to call the slot immediately. invokeMethod does all that in one line :)
> (Also fixed few slot name hiccups, no idea when that happened)
> 
> 
> Diffs
> -----
> 
>   player/lib/gamedetaillistjob.cpp 8b7d52c 
>   player/lib/models/gameitemsmodel.cpp 49f77ee 
>   player/lib/serviceprovider.h 1bf179d 
>   player/lib/serviceprovider.cpp 97889b3 
> 
> Diff: http://git.reviewboard.kde.org/r/101879/diff
> 
> 
> Testing
> -------
> 
> Tested for fetchGames, works.
> 
> 
> Thanks,
> 
> Shantanu Tushar
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/gluon/attachments/20110708/091e4747/attachment.htm