Summary: | Problems view should provide rich problems hover | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Andrey Loskutov <loskutov> | ||||||
Component: | IDE | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||||
Status: | NEW --- | QA Contact: | |||||||
Severity: | enhancement | ||||||||
Priority: | P3 | CC: | daniel_megert, francois.armand, gautier.desaintmartinlacaze, mistria, tom.schindl | ||||||
Version: | 3.8.2 | Keywords: | bugday, helpwanted | ||||||
Target Milestone: | --- | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=42263 https://bugs.eclipse.org/bugs/show_bug.cgi?id=516949 https://git.eclipse.org/r/97570 https://bugs.eclipse.org/bugs/show_bug.cgi?id=218482 |
||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Andrey Loskutov
2017-05-19 09:33:37 EDT
Created attachment 268474 [details]
quick hack of the tooltip in problems view via embedded browser
Created attachment 268475 [details]
mock of the extended hover for problems view
New Gerrit change created: https://git.eclipse.org/r/97570 (In reply to Andrey Loskutov from comment #0) > Better solution would be to re-use BrowserInformationControl > (AbstractInformationControl) infrastructure and so even embed the quickfix > actions into the hover, so that we not only could see the problem with the > hover but fix it by hover + click. I had a look at the screenshot and the code and it seems nice and not too risky. What are the potential risks associated with that change? Moreover, as all this code is internal, and as the current state is already promising, couldn't we target it for 4.7.1 ? Oh thanks you so much! That would be a major enhancement for my development workflow. An other major win would be to be able to keep line break and other spaces in the message in the pop-up. Scalac (but elm or rust compiler) are producing error message like these ones: http://elm-lang.org/blog/compiler-errors-for-humans (but all in all, I much prefer the simplest possible hover pop-up and getting it in next neon or 3.7.1 than a more complexe solution in 3.8 :) Thank you again for the reactivity. (In reply to Mickael Istria from comment #4) > (In reply to Andrey Loskutov from comment #0) > > Better solution would be to re-use BrowserInformationControl > > (AbstractInformationControl) infrastructure and so even embed the quickfix > > actions into the hover, so that we not only could see the problem with the > > hover but fix it by hover + click. > > I had a look at the screenshot and the code and it seems nice and not too > risky. Stop, the "quick hack" screenshot shows what the patch is doing, the "mock" screenshot is just a mock, which should be doable via BrowserInformationControl & Co, but not implemented yet. > What are the potential risks associated with that change? None. The final solution should probably provide a way for 3rd party users of Problems view (and Tasks / other related views) to suppress or to exchange the tooltip provider, but beside this it should be safe. The problem is, that even if most of the code is internal in ExtendedMarkersView, it is a base class of a MarkerSupportView, which *is* a public API. > Moreover, as all this code is internal, and as the current state is already > promising, couldn't we target it for 4.7.1 ? We could, but as said, the current patch only shows the simplest possible hack, which (if I understood the code of ColumnViewerToolTipSupport right) can't be extended. Ideally someone would use BrowserInformationControl (and related API's) and provide a way to use that in the context of a Problems view, including the possibility to have hover expand, quick-fix, copy/paste, linking etc. I've just spent an hour to play with that, and it was definitely not enough.
> We could, but as said, the current patch only shows the simplest possible
> hack, which (if I understood the code of ColumnViewerToolTipSupport right)
That's not correct you can subclass ColumnViewerToolTipSupport and you did that in your gerrit review but I maybe got that wrong
(In reply to Thomas Schindl from comment #7) > > We could, but as said, the current patch only shows the simplest possible > > hack, which (if I understood the code of ColumnViewerToolTipSupport right) > > That's not correct you can subclass ColumnViewerToolTipSupport and you did > that in your gerrit review but I maybe got that wrong This is limited because one has not much control over created shell and to get more flexibility one would need to touch ToolTip API which is public, so I think this is not going far enough. I'm -1 for this change. In general tool tips on views are discouraged. On some OSes the OS provides tool tips if the item label isn't fully visible. If you disagree, you can bring it to the PMC and see whether there's a different opinion. |