I've been investigating ways on how to provide themeable scrollbars on Windows and would like some feedback from SWT commiters before proceeding on the approaches (and ideally, if someone volunteers to revise the code when it's ready for review/inclusion on SWT, it'd be pretty nice).
So, first the problems on Windows:
=============================
1. Windows provides NO customization of scrollbars in its API. Scrollbars always follow the windows theme, which is usually a bright theme, so, users of Eclipse dark themes on Windows have a pretty bad experience as the scrollbars are created with a light theme in mind (not to mention that they're big, especially for something which occupies so much real state screen as Eclipse).
2. SWT itself was done in a way which expects the system to draw most things (although there are exceptions: controls such as the StyledText does most of the drawing itself -- because the capabilities on Windows are not enough for its requirements, although it still falls back to drawing the scrollbar using the system native capabilities to keep consistency).
3. As SWT itself is very tied to the system drawing capabilities, doing a themed scrollbar may require a different implementation for each control (and each one has different issues). For instance, the StyledText does most of its drawing manually and controls the client area already, while the Tree deals very closely with the system, which doesn't even allow hiding a scrollbar after the widget is created (either it has the scrollbars or not at creation time). Also, the tree does a lot of internal work to keep things synchronized with the scroll.
Implementation:
==============================
Ok, now that the issues related to showing the scrollbars are laid out, here are the approaches I'm thinking about:
1. **StyledText**: The StyledText is actually a canvas, where everything is manually drawn. In LiClipse (http://www.liclipse.com), I already created a custom scrollbar for the StyledText, which hides the system scrollbars and paints the scrollbar inside its canvas area. The proposal here would be porting this code to the SWT StyledText control (it does need some cleanup and adaptation to work there and some changes to some behaviors, but the risk here should be low as this is something I've done once already -- anyone can get LiClipse and use the LiClipse dark theme to see it in action).
To make it more explicit, when themed, we'd simply hide the system scrollbars and draw them manually inside the canvas area (and would keep track of events, inside the control to keep things updated).
It's API would change to have:
• styledText.setThemedScrollbar(true); // enables the themed scrollbar with a default background/foreground based on the styled text background/foreground.
• styledText.setThemedScrollbarBackground(black); // null to reset to default background
• styledText.setThemedScrollbarForeground(white); // null to reset to default foreground
• styledText.setThemedScrollbarWidth(10);
• styledText.setThemedScrollbarHoverWidth(15);
... other things related to the themed scrollbar customization as needed.
This implementation has the benefit of not having to change any client code (at least in theory), and it'd be possible to just turn it on through those APIs (i.e.: the CSS theming on Windows would be changed to do that).
2. **Tree/Table/List**: The current implementation for those controls makes it very difficult to actually create themed scrollbars, so, my suggestion here would be creating a custom ScrolledComposite for each of the needed classes which would be used to wrap those controls while providing a themed scrollbar. Its API would then be similar to the new API added to StyledText (for which an interface would be created), so, those controls would be created without any scroll and would be added to such a custom ScrolledComposite.
It should also be possible to add the API to set the scrollbar theming such as was done in the StyledText to those controls, by making them an instance which always embeds the custom ScrolledComposite (so, we'd never use the actual system scroll in this case, always our custom one), which implies that the change should be completely transparent for clients, although it may need to break the 'package-protected' API -- which no one should use anyways, as the scroll of the tree should no longer deal with the system scroll, only with the intermediary implementation of the ScrolledComposite.
E.g.: The Tree would actually embed a TreeScrolledComposite which would be its parent and would work with it internally to update the scroll and respond to it as needed. Internally, the system tree would always be created with "NO_SCROLL".
Note that things should be added gradually, as each component is actually unique when it comes to how it works with the scrollbar... Also, so far I've only done preliminary tests for those controls, so, I think that the approach is sound and should work, but I haven't gotten up near to a full implementation so far.
So, I'd like a feedback on whether SWT devs think this is feasible and pull requests implementing those concepts would be accepted for SWT on windows (note that on other platforms, those methods would initially be no-ops until someone takes the time to implement it -- I may do it in the future, but I feel Windows has by far the worst user experience, so, it's more important there)... Otherwise, if those don't seem good, I'd like feedback on which approach could be accepted for SWT.
Best Regards,
Fabio
