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