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

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

----- Original Message -----
> From: "Fabio Zadrozny" <fabiofz@xxxxxxxxx>
> To: platform-swt-dev@xxxxxxxxxxx
> Sent: Sunday, 21 February, 2016 2:19:09 PM
> Subject: [platform-swt-dev] Providing SWT themeable scrollbars (on Windows)
> 
> 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.

In general, I'm concerned about any API being added that's not considering at least 2 of the 3 WS we use. IMHO, this is a recipe for coming up with API that will not be portable/usable on the other WSs.
And with plan for adding so many new methods without even being checked for feasibility on the rest, it would be good if the new API is at least generalized in a way. Smth like StyledText.setThemedStyle("background:red;foreground:blue;width:15...") this will give up some flexibility and not make us come up with another set of methods for the other WSs by making the different implementations gain support for more attributes gradually and preventing the excessive documentation about which method is not working where, in which case and etc. - at least summarize all this info in the one place. Not to mention that such an approach would map better to the theming engine CSS approach and to any future approach to provide styling/theming in SWT in general
The above is just a food for thought feel free to call me nuts :).


> 
> 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".

Tree is the most fragile widget so this work is honestly scaring me. In addition to the issues mentioned in other mails I just want to add that this is really performance sensitive component too so making this additional approach being performant could be an adventure itself. 
Honestly, doing such thing to Tree widget will require someone being available for the next year or so to timely fix all the issues that will come up out of it on all the windowing systems with their weirdness.

> 
> 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.

Well, this is going against the design of SWT to be thin wrapper around the OS widgets and an approach like this may lead to smth like CTabFolder which is by far the worst part to support in SWT.
Custom drawing will open the door for many inconsistencies with regarding colors, shapes, backgrounds down to even scrollbar's shapes (anyone wants to see different scrollbars if widgets change one by one?). While it may work for StyledText - a canvas itself, thus having full control over what's drawn, for places where the actual system widget is used this would lead to terrible inconsistencies.
I would rather want to see an approach where instead of coming with custom drawing an approach in the other end of the spectrum is used - not best example and caused a lot of headaches but still - in GTK port we had to create SwtFixed widget (a GtkContainer which provides fixed sizing which GTK 3 no longer does) which extends the system component and overrides only the functions we had to modify thus keeping the inconsistencies to its lowest. Couldn't such approach be used for windows scrollbar? My lame google search gives some hope that it might be possible https://www-user.tu-chemnitz.de/~ygu/petzold/ch09e.htm.

Alexander Kurtakov
Red Hat Eclipse team

> 
> 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