Community
Participate
Working Groups
Coming from bug 42263 just an idea: provide a tooltip for the table cells, so that the long descriptions can pop-up similar to the java editor hover? I've quickly hacked around a proof of concept, I think this is doable. To the patch which follows: this one is based on ColumnViewerToolTipSupport, but unfortunately this one uses very unflexible ToolTip backend, so I didn't managed how I can "enter and expand" the hover like we have it in the Java editor. So the patch will fix the problem of "too long text description" not visible but that's all. No copy/paste, no links to symbols, no scrolling etc. 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.
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.
