Community
Participate
Working Groups
Currently, Eclipse text editors always show the horizontal and vertical scroll bars. Depending on code style, a horizontal scroll bar may never actually be used (the text is already wrapped after a certain column). Since bug 27096 in SWT is fixed since 3.8, setAlwaysShowScrollBars(false) could be used to make StyledText only show the scroll bars if they are actually necessary. This would give the user a bit more precious vertical or horizontal space in some situations and reduces visual clutter.
Created attachment 238506 [details] patch for setAlwaysShowScrollBars(false) in AbstractTextEditor Attached patch is a proposal for changing this in AbstractTextEditor. (I would have pushed this to Gerrit, but eclipse.platform.text does not seem to be there yet.)
I think Dani enabled eclipse.platform.text for Gerrit. Can you convert you patch to a Gerrit review?
(In reply to Lars Vogel from comment #2) > I think Dani enabled eclipse.platform.text for Gerrit. Can you convert you > patch to a Gerrit review? It's not listed here: https://git.eclipse.org/r/#/admin/projects/?filter=platform
Sorry, Thanh must be in vacation. Bug 421971.
Comment on attachment 238506 [details] patch for setAlwaysShowScrollBars(false) in AbstractTextEditor This just hides the scroll bar(s) but with that the overview ruler annotations are off, the overview ruler summary indicator is at the wrong location (bottom instead of top) and the editor also looks a bit ugly. Also, such a change can't be made in the ATE since clients rely on the rulers always being there and can then be broken (see first paragraph).
Created attachment 238653 [details] Picture showing the issues
So the patch is just hiding the horizontal scrollbar, not getting rid of the space as well? I've seen mention of omitting SWT.H_SCROLL as a means to completely disabling the horizontal scrollbar (and hopefully reclaiming the space it takes up), but that's a bit extreme, only people like me would want that AND the overview ruler banished for good; that's the kind of "whitespace" I'd like to see removed ;-)
(In reply to Robin Stocker from comment #3) > (In reply to Lars Vogel from comment #2) > > I think Dani enabled eclipse.platform.text for Gerrit. Can you convert you > > patch to a Gerrit review? > > It's not listed here: > https://git.eclipse.org/r/#/admin/projects/?filter=platform Sorry, I've enabled Gerrit for eclipse.platform.text this morning via bug 421971. You should be able to see it now.
(In reply to Dani Megert from comment #6) > Created attachment 238653 [details] > Picture showing the issues Just applied the patch, looks great*, vertical space gained with auto-hide horizontal scrollbars, very nice, thanks Robin! * yes, the overview ruler misalignment is there, but that begs the question, how can one make the overview ruler vanish in the same way that has been done with horizontal scrollbars, but permanently? hideOverviewRuler() looks like the tool for the job, but am not sure where it is shown/set in the first place.
Sorry for the noise, just thrilled to be able to customize Eclipse practically to the pixel, great stuff. Combined with styledText.setAlwaysShowScrollBars(false); and hacking AbstractDecoratedTextEditor#createOverviewRuler() Both constant horizontal scrollbars and overview ruler are gone, woohoo, Eclipse a la VIM ;-)
*** Bug 34928 has been marked as a duplicate of this bug. ***
(In reply to Dani Megert from comment #5) > Comment on attachment 238506 [details] > patch for setAlwaysShowScrollBars(false) in AbstractTextEditor Thanks for pointing out the issues, I'll look into that when I find the time. > This just hides the scroll bar(s) but with that the overview ruler > annotations are off Is that the line you drew in the picture? I don't see what's wrong there, could you elaborate? > the overview ruler summary indicator is at the wrong > location (bottom instead of top) That red square is already at the bottom here before the patch. Please elaborate. > and the editor also looks a bit ugly. Is that the circle at the bottom right? I think I found the place where this needs to be fixed in RulerLayout, thanks to bug 401230. > Also, such a change can't be made in the ATE since clients rely on the > rulers always being there and can then be broken (see first paragraph). "rulers always being there": Do you mean the scroll bars? If not in ATE, where could such a change be made? Or are you against such a change in general? (You know, when it comes to platform, all I do is guess where to fix things due to missing knowledge. And it can be a bit daunting to try to contribute to platform..)
It's complicated. The mapping from line numbers to overview ruler position is not as straightforward as one would wish. The implementation comments in org.eclipse.jface.text.source.OverviewRuler#computeY(..) tell how it should work for different scenarios. As an additional complication, non-Windows platforms have a myriad of ways to show/hide scrollbars and scroll bar buttons with varying sizes, so org.eclipse.jface.text.source.SourceViewer.RulerLayout#layout(..) implements a few strategies to put the "header control" (the box that shows the editor's error/warning state) at a place where it least interferes with the main purpose of the overview ruler. In some cases, the correct position is on the bottom of the ruler (if the scroll bar doesn't have a button on top, e.g. current Mac OS X default). However, there are layouting bugs in the E4 UI that also result in a wrong position of the header control on Windows (probably too many layout events at times when SWT APIs still report wrong sizes for scrollbar widgetry). These bugs are less frequent in Classic mode, and resizing the editor usually solves the problem. A correct solution with setAlwaysShowScrollBars(false) would have to update the overview ruler whenever the scrollbars get toggled. And it needs a strategy to keep the header control at a stable position.
*** Bug 435185 has been marked as a duplicate of this bug. ***
I have worked out a proof-of-concept on how to address the scrollbar issue on Windows. I'm not familiar with the UI toolkits available on Linux but I believe it should be portable there as well. This is a video of a working prototype for the purpose of demonstrating the possibility of hidden scrollbars for the Eclipse IDE on Windows. In this case, the scrollbars are a custom owner-drawn implementation similar to what you might encounter on OSX; for the added benefit of providing additional screen real estate. https://youtube.com/watch?v=-pPzqeoOYQU
I realize that I need to clarify my previous post. My work-around is expand the size of the text editor child window so that the scrollbars are clipped outside of the visible area of its parent. The benefit of this is that it can provide a very easy drop-in solution which does not require all of the other coupled UI elements which demonstratively break when these scrollbars are disabled. It is possible to use additional OS-native scrollbars which map to the positions and behavior of the view's actual scrollbars. My proof-of-concept provides an example with an owner-drawn OSX-like scrollbar which does not take up any screen real estate and is visible only when necessary. I'm not familiar with the capabilities of SWT, but for Windows I suspect that this will require some additional Win32 calls and message monitoring, as my solution requires. Please contact me for specifics and I will gladly provide all of the implementation details. Be aware that any glitching and visibility "blinking" of native scrollbars in my video demonstration is a result of my proof-of-concept being an externally reactive solution; it is not a plugin and does not operate within the same memory space as the IDE. Implementing this properly will not produce artifacts or UI lag.
