In my last few presentations I’ve introduced what I named “SonF” which is short for SWT on FX.
What is it?
SWT on FX is an SWT implementation which instead of using the native widget it use JavaFX controls under the covers (similar to what SWT on Swing did some years ago).
What is the target?
The target is to get as compliant with SWT as possible, there are some parts of SWT that are hard get working right, e.g. spinning an event-loop is something you really only hack into the system, other parts like ownerdraw in tables/trees is maybe doable but is not yet explored. At the moment our target is to get on par with what RWT can do today.
What is the audience? Where is it positioned?
We think there are 3 potential users/usecases:
- You want move away from SWT in future but have a big legacy code base which uses SWT
- You want to publish your application through RAP
- You don’t yet want to fully buy into JavaFX but SWT does not do the job for you anymore because of its limitations
We’d like to position it as a transformation/migration path for people who want move away slowly from SWT, it is not meant be an additional implementation so that people stick to it forever. SWT is quite done and does not introduce new concepts as it looks like.
What is the license? Is it EPL?
Sorry no it is not EPL? We have not yet defined the business model we’ll use for it. Parts of the code are under EPL because they are directly copied from upstream SWT (e.g. all the listener definitions, …) but most of the implementation have been implemented from scratch.
Where can I get it?
At the moment it is hosted in a private bitbucket-repository and we are not yet publishing binary builds. If you want to have a binary you could drop a mail to swtfx@bestsolution.at
Where do we go from here?
Like said above we don’t know where to go. In our opinion people will have to move away from SWT in future but they want to take their legacy code with them. On the other hand we also doubt that companies will pay us license fees for our SWT-FX-Port. A though problem, right! We could start a kick-starter project but would enough people support it? We highly doubt that as well. In case your company thinks this makes sense and wants to contribute substantial get in touch with us through swtfx@bestsolution.at.
Samples
Below you see screen shots UIs defined in SWT and rendered through SonF
SWT-Button
One of the most basic controls
SWT-Canvas
Having access to SWT-Canvas is important for many make controls like CTabFolder work
Combo
One of the a bit more complex controls but still fairly easy. It also shows that we have e.g. support for color chooser.
Table
One of the more complex controls, currently without support for owner draw
Tree
Another more complex one is a tree. We don’t yet support TreeColumns but this is not hard to add in the days to come
e4 on FX with SWT-Content
The outerpart is rendered through e4 on JavaFX from e(fx)clipse whereas the real UI is copied 1:1 from the SWT-e4-Addressbook example.
Tomsondev Blog 
Yes looks really very cool, but my problem with java FX is that it does not look native on Windows Operating system. Our users really like that our Rich Client App does not look or behave like a typical Java programm.
I can see your point about I think the time for native looking apps in slowly fading out? Does your RCP look like MS Office? Like Firefox or Chrome?
For many applications developed today native L&F is not a requirement (anymore) – it is more the opposite they have their cross-platform, company streamlined L&F they want to have on all platforms. Your users get accustomed to different looking apps while using their mobile devices and HTML5 apps.
There are project like JMetro styleing and AquaFX who try to proide a platform like L&F. I’m not sold on things like this. Swing showed how you can fail with trying to mimic a native platform where almost everything look but it’s the small things that matter!
One final word on Eclipse RCP and native L&F: Not all controls you see are native. Take for example the TabFolders in your app, they are clearly not native. Let me finish with: I can still see your point and SWT isn’t going anywhere in the years to come, it will be maintained but its use is going to decline.
Cool Tom, you are truely a master developer. Is your SWT bundle a drop-in replacement of the existing one? Can you run the Eclipse IDE on top of your implementation?
If you use package imports it is. It is not a fragment to the org.eclipse.swt bundle because this would make development harder. Running the IDE is far away still because StyledText & Owner Draw are missing and e.g. SWT.Activate logic
Still it’s promising. I totally agree with you, that the time for native looking applications is amost over and I don’t shed a tear about it. Time has changed and so we should adapt. On the contrary I think that an application, that was “styled with love” will aplease the users more than any native and most of the time dull looking application ever can.
While you say, that it is still a long until Eclipse would be ready to make use of your implementation, I’m looking forward to it.
As Lars said: Your are a true master dev!
Great news, Tom! That looks really impressing. Do you think virtual tables can be supported easily or is that going to be a lot of work? Does FX also support advanced table features such as variable line heights, grouped column headers, merged cells, etc (as in the Nebula table widgets)?
JavaFX Tables/Trees are virtual themselves by nature so for tables it is already implemented (trees are not yet done completely but adding it there is not really a problem), variable line heights are supported by table and tree, header groups as well, cell merging was deferred to post FX8 (it was in temporarily available in FX8 but removed because it was not ready for primetime) but there’s SpreadsheetView available as part of ControlsFX see http://fxexperience.com/2013/12/announcing-controlsfx-8-0-3/
This is really good. I have a question for all – is it a good idea to compare this with SWT? SWT was made with the objective to get native LnF. If a developer wants consistent LnF across platforms, he should obviously not choose SWT. It is the greatest mistake if he does that.
Tom, How fair are the chances for you to release this under open source license (at least the binary). I understand that you have invested a lot of effort but still. My salute to you for the great work done.
really cool. Since I went through a SWT on something implementation myself, I am really wondering whether its legally possible to separate EPL and non-EPL code. For SWT/Qt we had a discussion with Janet Campell and there were doubts that we could deliver the package as a mixture of EPL and non-EPL. But you have to find that out for yourself.
I think your problem was that you mixed EPL and LGPL code which is not possible – to my understanding the SWT-API is a interface description only and we learned from Oracle vs Google that you can’t copyright the API