<table><tr><td style="">rjvbb added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D16882">View Revision</a></tr></table><br /><div><div><p>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.<br />
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 <a href="https://phabricator.kde.org/D22424" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D22424</a> isn't that easy to read either (it felt like reading German, for some inexplicable reason ;) ).</p>

<p>You claim that</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>For some yet to explore internal reason, if there is a plugin with a<br />
 "ktexteditor_popup" menu to merge in, then the QMenu object instance is the<br />
 same across all KTextEditor::View instances, otherwise each view has its<br />
 own.</p></blockquote>

<p>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.</p>

<p>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 <tt style="background: #ebebeb; font-size: 13px;">QPointer<QMenu></tt> 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.<br />
Maybe the KTextEditor framework should simply provide a method to get a pointer to the current context menu?!</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D16882">https://phabricator.kde.org/D16882</a></div></div><br /><div><strong>To: </strong>rjvbb, KDevelop, kossebau, mwolff<br /><strong>Cc: </strong>mwolff, egospodinova, kossebau, kde-frameworks-devel, kdevelop-devel, hmitonneau, christiant, glebaccon, domson, antismap, iodelay, alexeymin, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd<br /></div>