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

Friedrich W. H. Kossebau noreply at phabricator.kde.org
Sun Nov 18 22:04:08 GMT 2018


kossebau added a comment.


  In D16882#361733 <https://phabricator.kde.org/D16882#361733>, @rjvbb wrote:
  
  > >   `KTextEditor::View::contextMenu()` talks about "the xmlgui menu" or custom set "context menu object", but no hint/promise whether there is any instance sharing done, e.g. between views for the same document or even across all views in the same process(?).
  >
  > No, but from the code it's clear that there's only a single instance that is shared among all views. With KXMLGUI that's even unavoidable (and incidentally a source of problems on Mac but that's a different can of worms).
  
  
  What I meant is: in a perfect world from KDevelop side when writing code against KTextEditor API we would only need to look as far as the API and its documentation. Anything which is not specified in the API dox is implementation details, and the KTextEditor developers would be free to change things as they need, unless they break a promise given in the API dox.
  
  Thus it would be nice to have this detail specified in the API dox of KTextEditor, about what to expect about the lifetime of the QMenu instance and if it is shared and if so, between what.
  That would help both sides, the developers of KTextEditor to know what they are bound to, as well as users of the API to know what to prepare for/deal with.
  
  E.g. I would have expected before looking at things that each view has their own separate context menu instance, possibly even created on the fly per display :)
  
  So, "from the code it's clear" ideally would be only interesting when trying to find bugs. When writing code, the API should be what we look at, and not further. Anything else is a bug/missing feature in the API.
  
  This is orthogonal to your actually proposed bug fix, which might be the final fix. But right now it would be relying on internal implementation, not what is documented in the API (by what I quickly read).
  (sorry, myself not enough time left now, more the next week if still needed)

REPOSITORY
  R32 KDevelop

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

To: rjvbb, #kdevelop, kossebau
Cc: egospodinova, kossebau, kde-frameworks-devel, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181118/3cd8f344/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list