User Tools

Site Tools


Sidebar

Dave Orme muses about data-first development.

My current work emphasizes data engineering and analysis using Kubernetes, Clojure, Scala, Eclipse, and Google Cloud Platform or AWS.


Blog

The Cloud

Scala, Clojure, and FP

Data-First Development

Agile

Older work

Coconut Palm Software home


Donate Bitcoin:

1Ecnr9vtkC8b9FvmQjQaJ9ZsHB127UzVD6

Keywords:

Kubernetes, Docker, Streaming Data, Spark, Scala, Clojure, OSGi, Karaf, GCP, AWS, SQL

Disclaimer:

Everything I say here is my own opinion and not necessarily that of my employer.

blog:the_way_forward_for_xswt

The way forward for XSWT

Given all the discussion around modeled UI in the Eclipse E4 (Eclipse 4.0) space and my recent talk about XScalaWT, I received an email wondering aloud what will happen to XSWT (hosted here). Here's more or less what I wrote in response:

XSWT will graduate

XSWT is going to morph into something else as its ideas are adopted into E4. The result is that what we know today as XSWT is splitting into two development streams:

1) Its immediate successor will be whatever the E4 XML declarative UI language is. There are several proposals, all with excellent ideas.

The main intent with E4's XML UI language is to learn from previous projects (including XSWT) and to marry these former ideas to ideas that are new in the UI space, but proven elsewhere. Particularly, we're interested in bringing in ideas from Microsoft's XUL as well as the idea of a full formal model of the UI using EMF. The former provides better extensibility than XSWT had and the latter means that you won't have to implement fifteen (or so) extension points just to get an app running. It will be one model, the whole of which can be modeled directly in XML.

2) Its second immediate successor is XScalaWT, or declarative UI ideas married to an internal DSL written in Scala. As I have blogged recently, XScalaWT provides a safe, proven route for Java programmers to adopt Scala in a limited way in their Java RCP projects. Performance is better in XScalaWT, since XScalaWT isn't interpreted but compiles to regular Java class files. In addition, XScalaWT itself is more readable than XSWT or Java, has much simpler code to maintain (than the XML-based version), IDE tooling for free, and Scala-based scripting for free.

When eventually coupled with the Modeled UI ideas from E4, this ought to be even more powerful and expressive.

I've personally been working on #2. Hallvard, Yyves, Tom Schindl, and others are working on #1, and in my estimation, it's in very capable hands.

The migration path

If you have a graphic design team working with XSWT and you're using it to rigorously separate presentation from behavior and content, then you'll want to migrate to Eclipse's XML-based UI language. If you are using XSWT as a productivity tool for programmers, then I'd encourage you to look at XScalaWT, which is more expressive and more powerful. I've blogged about how to create mixed Scala/Java RCP projects.

So to directly answer your question, once Eclipse E4 chooses an XML description language, I will end-of-life XSWT and encourage everyone to migrate to Eclipse's XML UI implementation or to XScalaWT.

~~LINKBACK~~ ~~DISCUSSION~~

blog/the_way_forward_for_xswt.txt · Last modified: 2014/10/17 22:08 (external edit)