Something that's been bugging me for a while (pun intended): semantic issues reported in code (and their corresponding popup) take precedence over the normal code parser/completion context browser popups or however you call them. For example, I've seen this error when opening patchreview.cpp (from an imported KDevelop project that probably has not had a complete build, when ui_patchreview.h cannot be found): Cannot initialize return object of type 'QWidget *' with an rvalue of type 'PatchReviewToolView *' on line 324, `return new PatchReviewToolView( parent, m_plugin );` There is no way to check in this situation if the PatchReviewToolView is even defined (if it really isn't the error should say that), or if maybe I'm invoking its ctor with unsupported arguments, etc. Similarly, in the situation where logging category macros aren't resolved properly, one can obtain useful context information hovering the mouse to the left of the macro (= for the qCDebug macro) but not for any other part of the line. That's counterproductive as it renders the entire parsing information inaccessible and thus useless for helping to figure out what's wrong. There are other cases where the problem reporter shoots itself in the foot like this, I don't have any examples at hand but I think we've all seen them.
I've seen this myself, Kevin, Sven - any idea's on how to handle this?
I think we should just show both popups, like we do in the debugger (one below the other). The code for that already has to be somewhere ...
Created attachment 118283 [details] example screenshot Any progress on this? Attached is an example where this is really annoying. Code I just want to get to compile so the lack of a shortcut into the class definition that doesn't provide the expected message is really handicapping here.
My last plan regarding this was to use the inline annotation interface to display error messages (similar to how QtCreator does it, but less intrusive probably, just an exclamation mark you can mouseover). Sadly, I currently have about no time to work on anything related. :(
Could you think of a workaround that's quicker to implement? Like a context menu action, e.g. - that opens the problem reporter view at the corresponding line - or opens the popup that's now being preempted (from the context browser I think?) - or toggles a switch which controls which of the two is seen (which could be both when you have a big screen) In fact, I've often wondered why the problem popup is triggered everywhere on the line, while the other popup is more context sensitive. IMHO the most logical thing to do would be to let the context browser popup preempt the problem popup. Even if that means that the problem reporter has to check if no one else could try to show a popup; a priori that'd be a bit of code that can be marked as a temporary workaround. I know workarounds aren't always appreciated around here and don't disagree in principle ... but there are times where you have accept compromises for the sake of productivity (and this'd be one, IMHO).
There's a patch for this on Phab: https://phabricator.kde.org/D18229
In fact, that was merged: This should be fixed after https://commits.kde.org/kdevelop/2071db63b3fb4172f112356b6d531aae75de5da8
Funny, I was thinking of such a solution - then thought that problem reports can be long so the context popup should be on top to avoid losing it somewhere offscreen - then realised some context popups are long too Can this be merged (easily) into the 5.3, (pretty) please?