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

[Michael Scharf <Michael-Scharf@xxxxxx>]

On 2016-02-24 16:10, Tom Schindl wrote:

> A 100% compatible SWT port who leverages JavaFX is not possible!

where is the problem/limitation?

Michael

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