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)

SWT is a direct mode drawing UI toolkit
JavaFX is a retained mode / scenegraph based UI toolkit

Eg in SWT you can simply attach a PaintListener to any control and start
painting as you want. This is not really possible with JavaFX and if you
do it you get into performance trouble.

A good example of this is eg the JFace-Decoration story who adds a
paint-listener on the parent shell, JavaFX does not expose the event
loop, ... .

SWTonFX has implemented this drawing stuff but if you use that on a
shell with many many decorators your UI is not not useable anymore.

There are other many many subtle difference you will most likely never
overcome, I can't remember all of them but anyone who wants to improve
the feature set of todays SWTonFX port is invited to check out the
codebase and provide gerrit-reviews, I'll happily merge them into the
codebase but as I said for BestSolution the current state is good enough
to render all UIs we've been required to render so don't expect us to
really work on this stuff unless we have a customers whose GUI we are
not able to render with the current state.

Tom

On 25.02.16 16:33, Michael Scharf wrote:
> 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
>>>
>>
>>
> 
> 
> _______________________________________________
> 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


Back to the top