Summary: | counterproductivity: semantic analysis issues preempt code context popups | ||
---|---|---|---|
Product: | [Applications] kdevelop | Reporter: | RJVB <rjvbertin> |
Component: | Problem reporter | Assignee: | kdevelop-bugs-null |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mail, mail |
Priority: | NOR | ||
Version: | git master | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | All | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | example screenshot |
Description
RJVB
2017-09-24 07:14:59 UTC
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? |