D6625: Fix crash on view split action invoked from tabbar context menu
Friedrich W. H. Kossebau
noreply at phabricator.kde.org
Tue Jul 11 11:43:13 UTC 2017
kossebau added inline comments.
INLINE COMMENTS
> kfunk wrote in container.cpp:625
> `QScopedPointer` indeed doesn't really make sense. This has basically the same semantics as if `QMenu` would have been created on the stack.
>
> Idea: Let's use `KDevelop::ScopedDialog` from https://phabricator.kde.org/R33:7cda7c95d5bfa93f34c5a52df17480c248a8367c?
>
> Let's backport that patch and use it(?)
No, that would be overkill IMHO. No need for QPointer stuff, as using QMenu::exec() already points out we expect the menu object to survive until after this call (as the method otherwise crashes).
If this would be my code (e.g. Okteta), I would just go back to stack-based QMenu :)
But other KDevelop developers might have more experience, so I concentrated just on the windowhandle setting in this patch for now.
> kfunk wrote in container.cpp:630
> Could you add the code which we can use starting with > Qt 5.9? In #ifdefs obviously...
>
> Makes it easier to port code once we start depending on this Qt version.
I am not aware of any. "<= 5.9" was just for adding a note about at what time/state the comment was added, so some future code reader would know whether it makes sense to investigate for improved Qt support.
Guess that text needs rewording then :) Any proposal?
REPOSITORY
R33 KDevPlatform
REVISION DETAIL
https://phabricator.kde.org/D6625
To: kossebau, #kdevelop, kfunk
Cc: kfunk, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170711/5fb7a231/attachment.html>
More information about the KDevelop-devel
mailing list