D18229: Contextbrowser: Ability to show combined problems and decl tooltip

[René J.V. Bertin]

rjvbb added a comment.


  > For me it is exactly the opposite. I hover the range that is underlined red
  
  For it's the entire line (across the full editor view width) that is rendered with a reddish background, no underlining here. I can't remember how I obtained that mode.
  So I hover somewhere on that line where there is no code -- if I don't simply glance at the error in the (docked) problem reporter toolview. Most of the time I don't use the majority of the problem report, esp. in situations like when you try to print something not supported by qDebug().
  
  > because one can always move the pointer away to have the tooltip disappear
  
  I find that it mostly gets in the way when I start correcting, which is a situation in which I don't want to have to move my hand back to the mouse or trackpad. And there is some form of hysteresis too, where the popup stays up when you move the cursor to a location where it wouldn't yet be triggered.
  
  > (since the red marking is somewhere else)
  
  See here:
  F6631635: example1.png <https://phabricator.kde.org/F6631635>
  
  I put the cursor somewhere on the problem line where I'd expect the popup not to cover code from the code below the problem line (please disregard the fact that it's a different function here).
  Error reports only come with a line number so you don't have any additional information to limit the spatial context where you can trigger the popup.
  
  Note how the red background is also apparent in the scrollbar/outline view, which I find extremely practical.
  
  Here's my version of the patch, adapted for the 5.3 branch:
  F6631638: patch-D18229.diff <https://phabricator.kde.org/F6631638>
  
  It still uses your combined view, but only if the height is not more than 1/3 of the current screen height. If higher, it inverses the logic and will display the declaration instead of the problem popup when both are available. I think this is a logical thing to do because the problem popup will be available for the entire line.
  Note that the window in that screenshot taken on my notebook is maximised vertically and takes up most of the horizontal screen estate too. Just about every combined popup that I have (not :)) seen gets rejected by my 1/3 rule. On my Mac with its 1080p screen the smaller ones get through but there too they are often too big because problem reports can be so verbose.
  
  I was under the impression that these popups were handled by 2 distinct plugins; had I known that they're created in this unique function I would have presented that inversed priority approach long ago.
  In combined popups I'd probably put the declaration widget on top because it is more likely to be the shortest of the two, and you probably lose less if the lower part of a problem report falls off the bottom of the screen.

REPOSITORY
  R32 KDevelop

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

To: thomassc, #kdevelop, mwolff
Cc: rjvbb, mwolff, kdevelop-devel, 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/20190223/b65930d6/attachment.html>