Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Providing SWT themeable scrollbars (onWindows)


On Mon, Feb 22, 2016 at 1:27 PM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
Backing up Mike's point: as someone who is not blind (although shortsighted ...) nothing frustrates me more when a perfectly ordinary OS widget is replaced with something that tries to be pretty and ends up being pretty useless. The Mylyn UIs are an excellent example of frustration because the drop down elements don't allow you to type in the name of the field or select with a spacebar in the same way that OSX widgets do. 

Similarly the scroll bar on OSX has to follow the preferences (eg reverse or normal direction) as well as arrows at top/bottom/both and finger gestures, which I'm guessing you wouldn't think about when trying to emulate your own.

The fact that the dark theme looks ugly is not what I care about. 

Well, what can I say, different users want different things... anyways, you will be able to keep the ugly dark theme for you if you feel the replacement doesn't do what you want ;)

My main point is that SWT *needs* to start working on a scrollbar replacement anyways if it wants to stay relevant among modern UI frameworks.

Also, I agree, maybe initially I wouldn't think about some corner cases, yes, that's possible (and likely), but that's what bug reports and feedback are for -- and I still think that the design I'm proposing can handle those, which is my main point right now.

Best Regards,

Fabio

 

Alex

Sent from my iPhat 6

On 22 Feb 2016, at 16:04, Mike Wilson <Mike_Wilson@xxxxxxxxxx> wrote:

> users find theming MUCH more important than being 100% compatible with what the system offers
>
Not if they're blind and can't use the scrollbar. Not if the scrollbar is in the wrong place for the language they use.

I'm sorry, but there are no shortcuts here. Making it work properly has to come first.

McQ.

<graycol.gif>Fabio Zadrozny ---2016/02/22 10:49:54---Well, personally, I must say that I know that the current implementation I have in LiClipse for Styl



From: Fabio Zadrozny <fabiofz@xxxxxxxxx>
To: "Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>
Date: 2016/02/22 10:49
Subject: Re: [platform-swt-dev] Providing SWT themeable scrollbars (on Windows)
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx





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.

    <graycol.gif>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
_______________________________________________
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

_______________________________________________
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


Back to the top