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

[Fabio Zadrozny <fabiofz@xxxxxxxxx>]

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

​Hi Alexander,

Well, actually, although I'm thinking about implementing for windows only at this time, I'm already considering other platforms here: when you go to a themed implementation, the rendering is expected to be the same on all the platforms, so, regardless of whether the API is from a call 'setThemedStyle' or through a number of methods, when support is added to a platform, all should come at once​ as the same rendering (non-native) kernel should be used regardless of the platform.

Still, I must say I don't have a preferred alternative here... SWT itself doesn't have any other thing related to CSS (I find it a bit odd that styling in the platform was all done outside of SWT), but if others feel this would be a better API, I'm definitely ok with that.

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

​Yes, I think I got the message (and if I start to do the work, I know I have to be prepared for that)...

 

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

I'm still on the research phase right now, so, thanks for the tip, will take a look at that...

 

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