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

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

----- Original Message -----
> From: "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx>
> To: "Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>
> Sent: Wednesday, 24 February, 2016 5:05:51 PM
> Subject: Re: [platform-swt-dev] Providing SWT	themeable	scrollbars	(onWindows)
> 
> ----- Original Message -----
> > From: "Alex Blewitt" <alex.blewitt@xxxxxxxxx>
> > To: "Eclipse Platform SWT component developers list."
> > <platform-swt-dev@xxxxxxxxxxx>
> > Sent: Wednesday, 24 February, 2016 3:52:56 PM
> > Subject: Re: [platform-swt-dev] Providing SWT themeable	scrollbars
> > 	(onWindows)
> > 
> > If you’re seriously suggesting using GTK3 on all platforms, I think we
> > should
> > halt this discussion now, because it’s obvious that no thought has gone
> > into
> > this over and above styling issues using CSS on Linux.
> > 
> 
> I just want to clarify that due to other than GTK platforms (note not only
> Linux, but all Unix) not being investigated nor someone poped up willing to
> do the work I don't plan such work in the shortterm (at least not as
> official thing being part of SWT).
> In terms of using GTK3 on all platforms, I meant having it as additional
> non-default option for people deeply concerned with styling due to the way
> more flexible styling api and way less
> effort in terms of maintenance 

To clarify what I meant by "way less effort in maintenance" - we already maintain 3 different implementation of every widget (win32, cocoa, gtk), so instead of adding 4 one (custom drawn) to reuse the only cross-platform one we have (gtk) as it's also not having the issues for which 4th implementation is even considered.


Alexander Kurtakov
Red Hat Eclipse team

> this additional option until other backends
> get properly fixed/grow capabilities. But defaults stay the OS native
> toolkit.
> 
> Alexander Kurtakov
> Red Hat Eclipse team
> 
> > Alex
> > 
> > 
> > 
> > 
> > On 24 Feb 2016, at 13:48, Mikaël Barbero < mikael@xxxxxxxxxxx > 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 > a
> > écrit
> > :
> > 
> > ---- Original Message -----
> > 
> > 
> > From: "Alex Blewitt" < alex.blewitt@xxxxxxxxx >
> > To: "Eclipse Platform SWT component developers list." <
> > 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
> > 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
> > 
> > 
> > _______________________________________________
> > 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