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

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

----- Original Message -----
> From: "Fabio Zadrozny" <fabiofz@xxxxxxxxx>
> To: "Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>
> Sent: Tuesday, 23 February, 2016 8:36:41 PM
> Subject: Re: [platform-swt-dev] Providing SWT themeable scrollbars	(onWindows)
> 
> 
> 
> 
> > I must say that while I think that a qt-based or javafx-based backend may
> > be
> > a good alternative, I don't think I personally have enough diplomatic
> > skills
> > to make that work (i.e.: I can't envision the default Eclipse being based
> > on
> > SWT from one of those backends -- and not because of technical issues -- it
> > seems many which would be more suitable than me have tried and failed in
> > the
> > past, so, I'm not thrilled in trying to pursue that path).
> 
> I would dare to say it's purely technical issues. A new port need someone
> dedicated to make it work fully compatible with current SWT API once it does
> and it proves to be more stable, better performance, better looking -
> changing the default wouldn't be an issue. The issue is that while making a
> port that would be >90% or even >95% compatible that's where things start to
> get ugly and one starts finding out that the two things just don't play well
> for design issues (scrollbar color anyone?) and it's not fine to change the
> default in this case as there is always code in the wild that will break.
> 
> ​Well, I must say I still see that as a diplomatic issue (because the 100%
> coverage in probably impossible to reach, so, the issue is mostly diplomatic
> to manage expectations properly). I think the target in this case would be
> porting so that javafx could be used with a backward compatibility layer in
> SWT, so, even if it doesn't reach 100% coverage it could still be deemed
> good enough to go (for instance, GTK 3.0 was out with several issues, but it
> still got out -- same thing with the first versions of Eclipse 4.0, so,
> things have gotten out even without all that was needed -- I'm not saying
> that this is ideal: probably in both those cases the releases should be
> delayed so that more work could be put out before the final release, but in
> reality, as that's a diplomatic issue and not a technical one, that's how
> things work).

GTK 3 backend work started during Juno (2012), Eclipse was startable in Kepler (2013), GTK 3 was default for narrow subset of GTK 3 versions (not all GTK 3 versions just the versions where it was less broken) in Luna (2014), GTK3 was made default in Mars (2015) when most modern distros stopped shipping working webkitgtk for GTK2 (security reasons) by default and we started getting reports for GTK2 blackouts (never cared to investigate them) so GTK3 was clearly the better option we had at that time as the other option was to ship with disfunctional Browser widget (unacceptable nowadays) and potentially breaking totally for minority of users. This costed huge amount of time to the whole team and we always shipped best option at the current time, yes it was not perfect and it had a number of issues but there wasn't better out-of-the-box working option for the biggest part of users.
There is huge amount of constraints to be considered when we speak about port being default - will it work out of the box? Aka is JavaFX available on user systems so they can just download eclipse and use it - few issues here - OpenJDK doesn't include it by default on linuxes so additional prereq step would be required by the users, IBM JDK didn't support JavaFX (does it now?) [1] claims no and etc. IMHO QT port is way more viable option than JavaFX (even if only for the sake of availability) if one spends the time needed. These are all things that one has to pay big attention to when trying to keep the huge user community functional. 
I would really welcome and support everyone spending the time needed to get port working including the releng/build work which is big hurdle too, Eclipse usable on top of this port as an option, become comparable and eventually better at which point I'll be the first one to ask for changing the default. But the path should always be that something has to prove to be better (in the most constraints) to become default.

> Related to javafx, if that's what devs think it should go, that's Ok too...
> as long as Eclipse decides to go to a path which will provide an IDE which
> can give a decent UI to users with a dark theme, I'm Ok with it (but what it
> can't do in my opinion is say that the current status quo is good because it
> definitely isn't).

I agree that the status quo is not good but going wild and changing things for the sake of bright future, without a proof that this future is ever going to come and causing big disruption in the ecosystem at the same time. Best option could probably be to reuse the existing GTK port (which we have now), figure compiling window natives against gtk3 on linux (should be compile issues mostly with almost no code changes as porting to Wayland took care of making Eclipse pure GTK app) and enjoy the better dark theme [2] (which btw. would be better on windows when using gtk 3 default theme (adwaita) compared to Linux distributions that come up with their own themes without dark variant). Anyone considered this option? IMHO (initial mention of the possibility on behalf of McQ) it would be easiest/fastest way to achieve good dark theme on other OSes with least amount of effort.

[1] http://www-01.ibm.com/support/docview.wss?uid=swg21696670
[2] https://twitter.com/knacht/status/646965353462034432

Regards,
Alex

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