SWT, Eclipse 4 and custom skinning
September 21st, 2008 | 4 Comments »Are SWT and Eclipse moving away from native widgets? If you follow the development mailing lists of the relevant Eclipse subprojects, this might be one of the more interesting questions for Java UI developers.
Much has been said over the past few years about the relative merits of Swing and SWT. SWT has always prided itself on using native widgets (wherever possible), sporting better platform fidelity and performance. In the meantime, the competitive pressure from SWT has, in the view of many observers, made Sun invest much-needed attention in Swing. It zigzagged a little in its priorities regarding native look-and-feels; much work has been done in Mustang for Windows and GTK LAFs, but the few glaring remaining bugs have been ignored ever since. However, Swing, AWT and Java2D teams at Sun have been at work bringing significant performance improvements (and not only for hardware-accelerated pipelines), using native font rasterizer on Windows, support for translucent and shaped windows and more.
The flexibility and extensibility of Swing painting pipeline allows creating applications that bear little semblance to the dated Ocean look, and it looks like SWT might be moving in this direction as well. Lotus Software has been purchased by IBM back in 1996 for 3.5 billion dollars, and IBM has put a lot of resources to continue the development of different Lotus components (such as Domino and Notes). Unbeknownst to many (which is a good sign for any software in general), Lotus is an SWT application. It certainly doesn’t look one – click the screenshot for the full size view:
Not much information is available on custom Lotus SWT components (or i haven’t looked hard enough), but this presentation (zipped PowerPoint) provides some insights – the UI guidelines are implemented with CSS:
A majority of our CSS support was intended to give the custom Lotus SWT widgets as much flexibility as possible. Styling standard SWT widgets is supported but very limited (fonts, colors, background image).
Another interesting development comes in the form of Eclipse Riena which is currently in the incubation stage. While you might want to skip the buzzword soup in the project description (enterprise service oriented blah blah), Riena aims to bring a fresh look to Eclipse RCP applications. The presentations at Eclipse Summit (PDF) and Eclipse Forum Europe (PDF) show these designs (click for full size view):
And while the UI of the sample applications shipped with milestone 4 of Riena 1.0 is quite far from the design mockups above, the trends are quite clear – Eclipse / SWT based applications are trying to break away from the native look-and-feel. So what are the plans for core SWT layer?
The answer to this question might be found in the mailing lists of e4 project. e4 is the codename for the next major release of Eclipse (hence the number 4). There are a lot of interesting ideas bouncing around the lists, including using EMF for driving the UI definitions (aiming, perhaps, at the same level of design/development separation as available in WPF, Apollo and JavaFX) and targetting different runtime environments such as Web browsers. It appears that one of the fundamental shifts is going to be the support for CSS skinning for the UI components.
Kevin McGuire is a platform UI contributor working for IBM on Eclipse UI, and his views on Eclipse-based RCP applications are quite refreshing:
As I survey the Eclipse based applications, RCP or not, they all look, well, like Eclipse based applications. Eclipse provides much power through reuse of existing components and extension of frameworks. But my goal as an application developer is to build software that is as appropriate for my audience as possible. That audience could be anybody. However, many choices we made early on in Eclipse were with an IDE user in mind and just don’t work well for other user types.
Why should my choice of technology so blatantly drive the UI experience? I’d like all that reuse and power, thank you, but the end result shouldn’t betray the technology used to build it, provided I am willing to invest in specializing it.[...] I’d like to see as rich a set of graphical front ends for Eclipse. Certainly CSS helps by providing good separation of behaviour and UI, but the components must be designed to make use of this separation.
[...] Eclipse based applications should be capable of the same degree of visual and interaction sophistication as web based applications. This is essential for reaching a wider audience.
This point of view is also shared by Christian Campo from the Riena project:
- RCP UI looks like the IDE
- is not that easy on endusers
- while there is an option to allow “freestyle” there is certain of look that seems well established i.e. Outlook and others (including Riena)
- there is already some common sense how user interfaces for endusers are designed like MS Office, Lotus etc.
- wouldn’t it be cool that we have more support for that in Eclipse rather than each application has to build that from scratch.
- endusers no longer expect their tools to have a native platform look
Are we going to see a UI customization layer in SWT that is similar to Swing’s look-and-feels?
Related posts:
- Substance skinning primer As Substance look-and-feel nears the official release 4.1 (scheduled for November 12th), i’m working on...
Thanks for stopping by. My name is Kirill Grouchnikov and I am a user interface engineer. I have been doing client side development professionally over the last decade or so, in a variety of UI toolkits and libraries that spanned Motif, MFC, VB, Ada, Delphi, Swing and SWT. Recently I joined the
Hm. So if there will be a skinning function, then native widget cannot really be used anymore? SWT was all about the common denominator between platforms AFAIK. Skinning will put more strain on the “common” part, so more and more widgets will most likely be custom drawn in order to allow for skinning? Basically SWT will become more swingalike.
With the performance enhancements in swing in mind, the open-sourcing of Java, is it time to roll in the SWTSwing library in Eclipse? If Eclipse were to pick up SWTSwing and hopefully hop through to use Swing and SwingX… Hm. That much development power using and enhancing Swing… Swingclipse? SwingE? ;-)
Ok, this is wheird!
For yesrs we have this discussion SWT fans vs Swing fans:
SWT – Our widgets looks like native and swing dont!
Swing – Well swing can be custumized with skins that can create applications with very diferent and great looks
SWT – But users wants that their app ntegrates with system and look as it was a native app!
Swing – Oh yeah? So why all new app’s from Microsoft doesnt use the native Skin? MSN, WMP, Office, etc..
SWT – Well… But SWT is faster than Swing!
Swing – Yes, but swing is available in more platforms!
And the discussion goes….
Well, now Swing is becoming more integrated with system, with the new layout managers and the new natives skins, an java application looks native, at my point of view, and its not as slow as in past, but still it is skin able and you have excellent look and feel like Nimbus that is allot customizable, and substance that have great looks!
Now SWT will be skin able? What about the “Look like native” approach? Will they have two SWT’s? One for native ad other skin able? Will they use the Swing model and create a skin that looks like native?
Old SWT fans will have to eat what they said previously….
Long life to Swing :)
This has actually been in the brewing for a very long time. Contrary to popular belief, SWT does have pretty advanced graphics capabilities. These make it fairly easy to invent custom renderings and the like.
Incidentally, there’s nothing stopping SWT from having a wrapper (probably built into JFace) around each component, by default delegating to the native widget, but optionally delegating to a custom renderer of some sort based on Canvas. I looked into doing this a few years ago but never got around to it. I’m assuming that if SWT in e4 is more skinnable, this is the route they will take.
Although styling via CSS and platform L&F are related, they are separate issues.
CSS is definitely on the table for E4, but all it allows one to do is to set via markup those things one could already do via API. As one changes more colors and fonts from platform defaults, one does diverge in increments from the platform look. This is even more true as you use more custom images and custom draw in existing SWT widgets. Furthest afield might be GEF, which has little platform L&F because its mostly drawn with interactions via mouse listeners. Thus one can achieve a fairly different look while still using native widgets.
There is no plan for SWT to abandon its approach to using native widgets. However, SWT Browser Edition could potentially see a new set of more sophisticated widgets on platforms which can support them such as WPF. In this case though the notion is to extend the widget set, not replace existing ones with custom draw.
I believe a visually richer Eclipse experience is in our future, but one which doesn’t require a complete departure from native widgets.