Re: [platform-swt-dev] Providing SWT themeable scrollbars (on Windows)

[Fabio Zadrozny <fabiofz@xxxxxxxxx>]

Well, personally, I must say that I know that the current implementation I have in LiClipse for StyledText doesn't have exactly the same behavior (which is something I'm already working on to improve), but apart from that, I must say I only got positive feedback when compared to the native one on dark themes.

Also, I may be wrong, but I believe users find theming MUCH more important than being 100% compatible with what the system offers, and is one of the main reasons people which use dark themes flock elsewhere in my view -- they end up choosing different IDEs and UI libraries because SWT doesn't do something which is a common-case for any modern UI library.

And in this situation, if users want, they can always fall back and use the native version if the themed version has some quirk... meaning: initially, I'm much more concerned in having an approach which will be accepted by SWT and having something working which will give users an improved experience on dark themes -- after that is agreed upon, it should be a matter of iterating and refining the implementation to improve on issues which are raised (and the native implementation should keep on working anyways, so, in the worse situation, users can keep on using it if they want).

So, in short, I know that emulating the behavior is hard, but it's something which I'm up to do, provided that SWT devs are Ok with the approach (one thing I don't want is doing all the work and not having it integrated because the implementation should be different from the start or because ideologically it won't be integrated anyways, which is why I'm bringing up the discussion).

Best Regards,

Fabio

p.s.: The current implementation StyledText scrollbar in LiClipse has been available for a full year without any critical issue -- although as I said, I know a few differences in behavior which I intend to improve to make it closer to what the system offers, even though users of the LiClipse dark theme seem satisfied with it.

On Mon, Feb 22, 2016 at 11:49 AM, Mike Wilson <Mike_Wilson@xxxxxxxxxx> wrote:

The biggest issue for me is getting all of the behaviors correct:

• does it react the same way as the system scrollbars to mouse and keyboard events?
• does it have exactly the same focus behavior as the system scrollbars?
• is it fully accessible?
• does it mirror properly for RTL languages?
• does it react properly to system events?
• does it impact performance?
• etc.

One of the realizations that caused us to build SWT using native widgets in the first place was that *emulating* the native behavior of widgets is really quite hard. Users can tell when you get it wrong, and it irks them.

I'm all for exploring the ideas you bring up, but it would be a lot of work and require extensive testing to get to a reasonable level of confidence.

McQ.

Fabio Zadrozny ---2016/02/21 07:19:39---I've been investigating ways on how to provide themeable scrollbars on Windows and would like some f

From: Fabio Zadrozny <fabiofz@xxxxxxxxx>
To: platform-swt-dev@xxxxxxxxxxx
Date: 2016/02/21 07:19
Subject: [platform-swt-dev] Providing SWT themeable scrollbars (on Windows)
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx

---

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_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev