| Re: [platform-swt-dev] CSS theming vs Chromium embed |
----- Original Message -----
> From: "Ned Twigg" <ned.twigg@xxxxxxxxxxxx>
> To: "Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>
> Sent: Thursday, 15 September, 2016 1:59:12 AM
> Subject: Re: [platform-swt-dev] CSS theming vs Chromium embed
>
> > From the IDE perspective, we have "almost" everything we need to do a
> > decently styling
>
> As an Eclipse IDE user and RCP developer, I disagree. I preferred the style
> of Eclipse 3.x for both use cases. In the situation that I need to build
> something that doesn't look like a native app, then I wouldn't use a native
> widget toolkit - I would use JavaFX or HTML5.
>
> The CSS theming adventure is now a 6+ year project, and it can "almost" do
> "decent" styling. The electron project was able to do great styling
> immediately, and as a result it was adopted very quickly! I recognize
> resources are limited.
> But if we declared bankruptcy on SWT theming, and used those resources for
> SWT-Chromium, how far could we get?
Hey Ned,
I have never been interested in SWT theming (no matter how it looks, but more on that later). Regarding SWT Chromium - there are constraints that downloading Eclipse SWT components should work out of the box without requireing installing additional software and Chromium is not available on any OS by default. This means that we have to provide working IE, Safari, WebkitGTK first so when someone downloads Eclipse the Javadoc view/hover and etc. render properly without sending him/her to download something else. And believe me the webkit maintenance costed my team way more time than theming work. I would love to have Chromium(Blink) support as an option but it's not something that we can prioritize over out of the box experience.
Btw, what exactly are you looking for in SWT Chromium? I don't see what can be achieved with Blink that can't be achieved with Webkit. Please elaborate on this there could be some low hanging fruit we are not providing in SWT which is possible or easily achievable without all the labor to support new engine.
>
> Building a CSS theming engine for native widgets was a great experiment. But
> somebody built electron in less than a year, and it turns out to be more
> useful than what we've been building for 6+ years. At what point do we say
> "Hey! That was a better idea!" and follow their lead?
>
> I recognize the theming engine has users, and mine is just one opinion of
> many. But here's my long and short: I built an Eclipse RCP application.
> Today, there are new entrants in my market that use Electron. They have
> access to capabilities that I don't.
Please let's discuss these capabilities. I want to grow SWT and input like this is something I'm missing for years - really most of the requests/bugs we had in the last few years are/were issues with newer system UI toolkits and misrendering bugs. Regarding the theming work - it's a byproduct of SWT aligning better with GTK and using proper APIs and etc. So the GTK CSS features exposed are not something we worked on specifically that costed us time, it's exactly the opposite - all these features were already used internally by SWT to make existing SWT APIs work reliably and it was a matter of few hours to expose that even to users for use. I call that win-win. :)
> I told my customers my app was stable
> and lightweight on resources, but the CSS engine is slowing it down and
> linux compatibility has been tough (GTK's fault more than SWT, but my
> customers don't care).
Well, I would not put it all the blame on GTK if nothing else SWT was trying to support way more than technically feasible giving suboptimal results. I'm pushing hard to improve that - there is time when someone should say that's enough. This included huge amount of underlying work in SWT - every one of the last 3 years we have been moving SWT to use newer GTK features/apis and moving away of the long deprecated and etc. - resulting in way easier to maintain and to discuss issues with GTK devs. I would dare to say we are at the point where this whole lot of "hidden" work starts to pay off - both in terms of stability and performance. So now is the right time to talk about growing in feature set.
> I'm no core Eclipse committer, but I do make some
> contributions ( RxJava and SWT , Gradle and Eclipse RCP ). I don't have the
> capacity or budget to write SWT-Chromium, and I see no will in the broader
> community to do so either. So I have to decide - do I abandon my investment
> and jump ship? Or stick it out and try to turn the boat?
Again, you mention SWT-Chromium as a must have but we can't give up on out-of-the-box engines. Let's keep discussion to features/APIs you want to see in SWT and see what comes out of it.
>
> Since I'm just a one man company, my survival in the market is more to do
> with "surfing" - riding a good wave, vs "mountain climbing" - climbing from
> the bottom. I'm still sticking it out, but the great thing about being home
> to "surfers" is that they bring contributions and bug reports. It kills me
> to see SWT become bloated with theming hooks while surfers flock to "libui"
> and electron. It seems that so much of Eclipse's resources go into this
> dead-end theming engine, I wonder what could be if we refocused.
> ᐧ
>
> Ned Twigg
> Lead Software Architect, DiffPlug LLC
> 540-336-8043
> 340 S Lemon Ave #3433, Walnut, CA 91789
>
> On Wed, Sep 14, 2016 at 2:46 PM, Lars Vogel < lars.vogel@xxxxxxxxxxx > wrote:
>
>
>
> Hi Ned,
>
> the Eclipse platform engine is part of the Platform UI project. SWT provides
> the API which we require and I certainly hope that SWT continues to add
> styling support. From the IDE perspective, we have "almost" everything we
> need to do a decently styling.
>
> Most notable is the missing background color support on Buttons and Table
> headers and more both we have already external contributions (still need to
> be reviewed and integrated).
>
> Alex is working on a deeper CSS integration for GTK which also looks very
> promising.
>
> I think a deeper SWT and HTML5 integration is very much desired but I'm not
> aware of anyone working on this.
>
> Best regards, Lars
>
> On Wed, Sep 14, 2016 at 10:47 PM, Ned Twigg < ned.twigg@xxxxxxxxxxxx > wrote:
>
>
>
> There is a huge gulf between native widgets and HTML5, in terms of both
> capability and resource usage. Because there's a tradeoff, there are good
> reasons to pick one or the other depending on your situation.
>
> In 2013, Electron had the novel idea "let's take the latest available
> Chromium and tie it to an in-process VM as deeply as we can". Electron now
> had much deeper browser integration than SWT could achieve, because SWT
> takes the "lowest-common-denominator" approach. I was skeptical when it came
> out, but boy was I wrong. People have used it to build a ton of really cool
> stuff: http://electron.atom.io/apps/
>
> But native widgets still have a place! The libui project is essentially an
> immature version of SWT written in C. And even though it's less than a year
> old, it has caught on like wildfire and become a popular widget kit in many
> languages already. People want SWT, but all their pull requests are going to
> libui because it's hard to embed SWT (through no fault of SWT's).
>
> Right now, users have to pick "do I want native widgets?" or "do I want
> latest and greatest HTML5?". I think it would be awesome if SWT allowed
> users to have the best of both worlds.
>
> With all the discussion of the CSS theming engine on ide-dev, I'm worried
> that resources are going to be spent on further theming efforts. I hope we
> give up on trying to make SWT into HTML5, and instead try to make SWT and
> HTML5 live together as best we can.
>
> Ned Twigg
> Lead Software Architect, DiffPlug LLC
> 540-336-8043
> 340 S Lemon Ave #3433, Walnut, CA 91789
> ᐧ
>
> _______________________________________________
> 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
>
>
>
> --
> Eclipse Platform UI and e4 project co-lead
> CEO vogella GmbH
>
> Haindaalwisch 17a, 22395 Hamburg
> Amtsgericht Hamburg: HRB 127058
> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> USt-IdNr.: DE284122352
> Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx , Web:
> http://www.vogella.com
>
> _______________________________________________
> 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
--
Alexander Kurtakov
Red Hat Eclipse team
_______________________________________________
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