Review Request 121218: Allow using new style connect syntax with KStandardAction::create()

[Gleb Popov]

> On April 5, 2015, 5:26 p.m., David Faure wrote:
> > Well, +1 for the idea. But I wonder what the apidox will look like, the macro+template probably don't make it work.
> > 
> > Also missing @since 5.10.
> > 
> > Ship it from me once the apidox issue is resolved.
> 
> Gleb Popov wrote:
>     What apidox issue is being talked about? If it is about `KSTANDARDACTION_WITH_NEW_STYLE_CONNECT`, then i was able to make it work with some simple Doxyfile options.
>     
>     See `save()` overload for example: http://arrowd.name/html/namespace_k_standard_action.html#abd0ad3c1f3ee5c9d2ff068a06c8a6ac1 and http://arrowd.name/html/namespace_k_standard_action.html#a92c0df356ef011d4a7ae9a844d4a0bc7
>     
>     If this is OK, i can document all new connects with `@since@` too. Can this be commited then?
> 
> David Faure wrote:
>     Well that's ugly docs :) You should use #ifdef DOXYGEN_SHOULD_SKIP_THIS around the enable_if and in the #else use the readable version (QAction *, IIUC) so that doxygen sees something cleaner and readable by the developer using this API.
>     
>     But actually I don't even understand the use of enable_if here. How can a pointer-to-function or a lambda be ambiguous with const char * ?
> 
> Alex Richardson wrote:
>     I don't remember why I needed it because it's been a long time since I wrote that code. But I think the compiler might try to substitute the template parameter Func with `const char*` in some cases. The other way to solve this might be to use like `const typename QtPrivate::FunctionPointer<Func>::Object *receiver` instead of `QObject*` to constrain the type of the Func argument.
> 
> David Faure wrote:
>     I applied the patch locally to try what happens without the enable_if.
>     Indeed openRecent() becomes ambiguous then.
>     This is because of the use of template<class Receiver, class Func>, the compiler will happily instanciate that with Receiver=QObject and Func=const char*, making it ambiguous with the old method. So your last suggestion wouldn't help, this isn't about Receiver, it's about Func.
>     
>     Indeed qtimer.h has similar stuff, pushed even further with
>         // singleShot to a functor or function pointer (without context)
>         template <typename Func1>
>         static inline typename QtPrivate::QEnableIf<!QtPrivate::FunctionPointer<Func1>::IsPointerToMemberFunction &&
>                                                     !QtPrivate::is_same<const char*, Func1>::value, void>::Type
>     
>     :-)
>     
>     Note however that, as I suspected, this is hidden from the unsuspecting developer, by showing a "readable" version for the API doc.
>     That's all I'm asking for ;)

Would you prefer `QEnableIf` or `std::enable_if`?


- Gleb


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121218/#review78527
-----------------------------------------------------------


On Dec. 24, 2014, 4:23 p.m., Alex Richardson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121218/
> -----------------------------------------------------------
> 
> (Updated Dec. 24, 2014, 4:23 p.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Nicolás Alvarez.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> -------
> 
> Not sure if MSVC has the necessary type_traits working, but can't test that now since it don't have a Windows machine available.
> 
> 
> Diffs
> -----
> 
>   autotests/kstandardactiontest.h 0008d281c0353e872feb7483c75762a0012a7b76 
>   autotests/kstandardactiontest.cpp 09ae35db05467d61b8baf50fac70c6228e324492 
>   src/kstandardaction.h d511778b7a24b1ec2e546949dab21f1ec2fea96f 
>   src/kstandardaction.cpp e5bea7965032355501b4c238e37abcc0f883c0b7 
> 
> Diff: https://git.reviewboard.kde.org/r/121218/diff/
> 
> 
> Testing
> -------
> 
> The newly added unit test passes
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160523/7cb45922/attachment.html>