D16882: [KDevelop/Shell] prevent duplicate added contextmenu actions

René J.V. Bertin noreply at phabricator.kde.org
Sat Jul 13 10:51:50 BST 2019


rjvbb added a comment.


  I could try your solution, of course, but what annoys me is that it comes months after I worked on mine. I currently have too many other things going on in my life to dive in and figure out what on earth was going on again. I do think I outlined it well enough above in the initial description and/or exchange; I should find a moment this weekend to sit down and re-read it with a fresh mind.
  It would help if you had a specific critique on my solution other than "it doesn't use this or that signal" (or, what I kind of sense, "it comes from you"). No disrespect intended, but your description in D22424 <https://phabricator.kde.org/D22424> isn't that easy to read either (it felt like reading German, for some inexplicable reason ;) ).
  
  You claim that
  
  > For some yet to explore internal reason, if there is a plugin with a
  >  "ktexteditor_popup" menu to merge in, then the QMenu object instance is the
  >  same across all KTextEditor::View instances, otherwise each view has its
  >  own.
  
  but I have never seen any proof that the context QMenu instance is ever NOT the same. On the contrary, it makes perfect sense that it is always the same because there can only be a single context menu.
  
  I'm not saying we shouldn't rely on the aboutToHide signal if this signal can indeed be relied on. But it would be good to do things properly and get to the bottom of the shared-or-not context QMenu instance question. It looks like your new `QPointer<QMenu>` is an acknowledgement to the fact that it can at least be a unique instance; if it always is it could (and maybe should) be moved to a central, shared structure and accessed from there.
  Maybe the KTextEditor framework should simply provide a method to get a pointer to the current context menu?!

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D16882

To: rjvbb, #kdevelop, kossebau, mwolff
Cc: mwolff, egospodinova, kossebau, kde-frameworks-devel, kdevelop-devel, hmitonneau, christiant, glebaccon, domson, antismap, iodelay, alexeymin, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20190713/4d4603ca/attachment.html>


More information about the KDevelop-devel mailing list