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

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

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.

I know that this is frustrating.

Tom

On 24.02.16 14:48, Mikaël Barbero wrote:
> Here is an attempt to sum up the different proposals (feel free to
> correct them if I misunderstood something):
> 
> - Port SWT to JavaFX => Expansive, not supported on IBM JDK and OpenJDK,
> and rumors about Oracle dropping support of JavaFX. 
> - Port SWT to Qt => seems to be an accepted solution (despite Christian
> mentioned that his port "didnt get much love in the SWT community for a
> number of reasons that [he] can understand actually"). It's also an
> expansive solution.
> - Use GTK 3 on all platforms, i.e. do not use Cocoa OS X or Win32 on
> Windows anymore. Any opinions on that? Should it be tried?
> - Emulate scrollbars for canvas-like widget (StyledText would be the
> first target) by painting over existing native scrollbar and provide API
> to style the emulated scrollbar (not applicable for Tree/Table as they
> are native widgets). The API can be one or many methods, the fact to
> draw a new scrollbar has to be decided first.
> - Add SWT API to call some supported styling native widget, e.g.
> Widget#setThemedStyle(String). It seems straightforward to implement on
> GTK3 (https://developer.gnome.org/gtk3/stable/GtkCssProvider.html), any
> idea about the effort for other platforms (may requires string parsing
> and multiple native function calls if not available)? Would fit nicely
> with the "use GTK 3 on all platforms" solution. 
> 
> Does it make sense to go one way or another? Do you think of any other
> possible solution to do it? 
> 
> Thanks,
> Mikael
> 
>> Le 23 févr. 2016 à 21:14, Aleksandar Kurtakov <akurtako@xxxxxxxxxx
>> <mailto:akurtako@xxxxxxxxxx>> a écrit :
>>
>> ---- Original Message -----
>>> From: "Alex Blewitt" <alex.blewitt@xxxxxxxxx
>>> <mailto:alex.blewitt@xxxxxxxxx>>
>>> To: "Eclipse Platform SWT component developers list."
>>> <platform-swt-dev@xxxxxxxxxxx <mailto:platform-swt-dev@xxxxxxxxxxx>>
>>> Sent: Tuesday, 23 February, 2016 9:54:47 PM
>>> Subject: Re: [platform-swt-dev] Providing SWT themeable
>>> scrollbars(onWindows)
>>>
>>>>> 1a. If you think it should be supported, do you think it's better
>>>>> to have
>>>>> "multiple methods" or a single method with a "CSS string"?
>>>>
>>>> Hard to say, but I think Alex plans the CSS support anyway for SWT, in
>>>> this case a CSS string should be reused.
>>>
>>> The SWT is a reusable standalone component which doesn’t have any
>>> external
>>> dependencies. The CSS support in Eclipse 4 brings in a lot of baggage:
>>>
>>> * org.eclipse.e4.ui.css.swt ->
>>> |- org.eclipse.e4.ui.css.core ->
>>> |- org.apache.batik.css ->
>>> \- org.apache.batik.util ->
>>> \- org.apache.batik.util.gui ->
>>> | - org.w3.dom.svg ->
>>> \- org.w3.dom.smil ->
>>>  \- org.w3.dom.events
>>> |- org.w3.css.sac
>>>
>>> Partly that’s because of the Batik parser (why does a parser depend on a
>>> GUI?) but in order to maintain SWT to be a single dependency you’d
>>> need to
>>> in-line whatever CSS parsing support was required in order to theme
>>> it. And
>>> that probably doesn’t fit in with the goal of making SWT lightweight and
>>> able to run on small devices, which has been a goal in the past.
>>
>> Not the place in this thread, but what I have in mind shares nothing
>> with the CSS support in platform.ui. My idea is to make use of the
>> styling capabilities of the underlying toolkit (GTK in my case) and
>> feed it with CSS (almost)directly. That would be way more flexible and
>> full css support actually
>> (see https://developer.gnome.org/gtk3/stable/GtkCssProvider.html for
>> details) and not requiring you to parse css and reinvent all the
>> machinery, should be fully in the spirit of SWT - a thin wrapped on
>> top of the OS provided support. And no additional deps for SWT for
>> sure :). Due to Win/Cocoa not having such capabilities(at least I'm
>> not aware of them - feel free to point me to it or best if you know
>> how to do it for them let's have a call and discuss details) it's not
>> feasible work for SWT for now, although worth trying to see what will
>> come out of it when I have time to play with it. In any case such
>> attempt is not for this thread so if there is someone interested in
>> continuing on it, please start a new one.
>>
>> Regards, 
>> Alex
>>
>>>
>>> Alex
>>> _______________________________________________
>>> platform-swt-dev mailing list
>>> platform-swt-dev@xxxxxxxxxxx <mailto: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 <mailto: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
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck