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

[Fabio Zadrozny <fabiofz@xxxxxxxxx>]

On Wed, Feb 24, 2016 at 12:15 PM, Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote:

----- Original Message -----
> From: "Tom Schindl" <tom.schindl@xxxxxxxxxxxxxxx>
> To: platform-swt-dev@xxxxxxxxxxx
> Sent: Wednesday, 24 February, 2016 5:10:50 PM
> Subject: Re: [platform-swt-dev] Providing SWT themeable scrollbars    (onWindows)
>
> Hi Fabio,
>
> A 100% compatible SWT port who leverages JavaFX is not possible!
>
> You can get at a state RAP managed to get to but no further, the EPLed
> SWTonFX port provides you a good starting point, we stopped when we
> managed to render our input forms, so that we can move the gradually
> from SWT to JavaFX.
>
> The main driving force for all this stuff in the IDE space is the dark
> theme and I think people need to start to accept the fact that SWT is
> not designed to look as different to the main OS theme than you want it to.

Fully agreed with this one. Currently what we have is a library designed in the way to have it look and feel just like the host platform and provide common API for that. And on top of it there is the theming engine which tries to go against this design decision directly by trying to make the widgets not look like native ones. Not an easy point to solve.
 

Well, I must say that personally, I'd like to make the scrollbar theming a reality for the Eclipse IDE and from the discussions so far, I think that the theming layer is probably the best target for that (the same way that the tree arrows support was done for windows) -- agreeing with all the comments that this should not go into SWT as it's against the way it's built.

So, right now, the direction I fell I should take is investigating more related to trees/table and the scroll ​to come with a viable solution (following the tip from Christian Campo: "I would recommend to you to find an approach that does not require to change the SWT code base but rather can be added on top (like Nebula is added on top of SWT).").

If at some point Eclipse goes to JavaFX (with a backward-support layer in SWT) or to Qt or to GTK3, and it solves the theming issues in other ways, that's great, but as my target is getting it to a release in Eclipse with a timeframe which should be as short as possible for final users, I believe that the approach I outlined above is probably the best right now (unless eclipse core devs or some steering committee decides that the way forward should really be going to javafx/qt/gtk3/other and setting a target release which should include it and make it the default -- in that case, instead of fixing with what I have in hand right now, I may help in doing that move).

Best Regards,

Fabio