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

Reply via email to