Skip to content
 

SWT/Qt … its “just” styling

Back in November when I was at the Eclipse Summit 2009 in Ludwigsburg, I talked to a number of people about the potential of SWT/Qt and showed a first implementation. One guy (well known in the Eclipse space) asked me “Why are you doing this ? Is it just because of the styling ?”.

In the light of the current discussion about the killer app in e4, I was reminded about this again. While some people mentioned CSS styling as the killer feature in e4. Other people stressed the point that CSS styling is pointless to them and they see other interesting hotspots like DI, faster startup times, no singletons etc.

From my background I know real power users who only care for speed. They don’t like field-based validation, error marking of fields and drag and drop and any kind of eye candy is superfluous.

For others a slick, stylish top notch UI is a selling point by itself. Riena is often chosen by people who like its Theming and Look & Feel capabilities. CSS Styling is only the logical next step for them.

So there is a userbase for whom we are “just” doing this new SWT platform that is based on Qt.

Qt from Trolltech/Nokia has been around for quite a while now on all major platforms. Its CSS styling support is very flexible, mature and well established. So we had the idea to create a new SWT implementation that leverages Qt for Eclipse based applications. Our main target is currently the windows platform. Development is internal but we plan to make it available to others later this year.

Its however a major effort to create a new SWT platform. But you learn a lot about SWT…

So here is a little teaser screenshot. Based on the current RCP Mail application, a number of committers create RCP Mail 2.0 which is targeted to be hosted in the examples project, details can be found in bug 253105.
What we did is we ran RCP Mail 2.0 on top of the current version of SWT/Qt and applied a CSS stylesheet on top of it.

And now tell me you don’t like it :-) . Looking forward to your comments.

p.s. There is a talk on this on EclipseCon with many more details and demos (link).

23 Comments

  1. Great stuff! I’d be interested in hearing about your experiences with SWT/Qt, and especially how it compares to SWT/GTK. There have been a lot of issues with the GTK support over the years. I’m hoping SWT/Qt, while looking better under KDE, will also be faster, stronger, … Can’t wait for your talk at EclipseCon :) .

    BTW, you should consider contributing it as soon as possible. There is already an eSWT/Qt port which could also be expanded to full SWT. We need to bring these two efforts together.

  2. ekke says:

    Christian,
    this looks really great – and if its available we’ll see how redview will work using SWT/Qt.
    hopefully it will work not only on Windows, the real power of SWT is the use on Windows, OSX, Ubuntu,….
    …of course I’ll come to your EclipseCon Session
    ekke

  3. How is the work to get Qt working on other platforms (like Windows, Linux, etc…)

    From my standpoint, I see Nokia and some others pushing hard to make Qt a platform. It may be wise to try to work together on this vision. Anyways, it’s good to see someone experimenting out there on this.

  4. Christian Campo says:

    Thanks for the positive feedback so far.

    As said in the post, we are currently not working on Mac or Linux. Small company, limited ressources, MS Windows is the platform of our customers.

    I have talked to Nokia and Gorkem in the past (Email) and they have a different focus. On the discussion thread for the eclipsecon Gorkem posted “…Nokia team offers to collaborate on completing the implementation to full SWT but would like to set the expectations at the right level. Nokia’s interest is mainly on eSWT so that will be the priority for the team. Also If I recall correctly Christian wants to support SWT/Qt for windows. My team is interested on KDE Linux, Symbian and Maemo only…”

    The way eSWT for Qt is implemented and how SWT/Qt works, makes it something between hard and impossible to join forces.

    eSWT is based on a hand written C layer that dispatches between java and c++ (Qt). SWT/Qt uses QtJambi which is mostly generated code that does the trick. QtJambi was abandoned by Nokia/Trolltech last year and is currently supported by a small open source community (currently building up).

    There is still way to go for us to have a complete implementation.

    We see SWT/Qt as Eclipse related technology but there is currently no plan to host it at eclipse.org. But we will make it available to others (as I wrote in the post).

  5. [...] just read this interesting post about a project for an SWT version based on Qt.  The project argues it is for styling purposes.  [...]

  6. Gorkem Ercan says:

    Jambi is mostly generated Java binding for the Qt libraries. I guess Jambi dependency makes your work hard to be accepted by the Eclipse platform. Also I see that you have no plans for it to exist on eclipse.org. This makes me wonder, wouldn’t it be easier to just port Riena to Jambi? Anyway the functionality added by Jambi is specific to your work and not to the general SWT implementation.

  7. Christian Campo says:

    Porting Riena to Jambi sounds interesting but is not the solution for our problem. We like to style existing SWT based applications. And our customers want more than SWT/Win32 has to offer.
    While we prefer a generated binding layer, its my understanding that eSWT uses a handwritten one. That difference is more a difference in programming style or comfortability writing C binding layers. People in embedded space are very good at that while we rather use a Java API.
    I hope that Jambi is not a problem for acceptance by the community in general but we have to see that. There is a similar kind of acceptance problem by some that SWT is based on anything that is not a native OS widget.

  8. Gorkem Ercan says:

    Jambi adds several MBs of additional class files to load at start-up to run SWT applications. Not sure about the runtime overhead but since there is code it probably has an impact. I think the overhead is an acceptance issue.

    As for generated code.. eSWT team is also willing to use the SWT generator to generate the trivial native code. See the details on this report https://bugs.eclipse.org/290987 .. We seem to have a solution for it.

  9. Emanuele says:

    Absolutely cool. Do we have any chances to see an SWT-QT bridge suitable for Eclipse?

  10. christian campo says:

    If by “Eclipse” you mean the IDE, you should come to the EclipseCon 22th Mar, 2010 in Santa Clara 16:20. http://www.eclipsecon.org/2010/sessions/?page=sessions&id=1142

    Hopefully we have something for you there. :-)

    BTW: Its not a bridge. Its a fully SWT implementation based on Qt, comparable to other SWT implementations that are based on other toolkits/APIs.

  11. Marc says:

    Very nice.

    I’ve been waiting for a SWT/QT for quite a while, especially since I started to use Linux as my development environment and SWT/GTK is kinda slow…so pleeeease make it available on Linux too :-D

    The slowness of SWT/GTK is a very big point I think, so your work is not just for styling purpose, like you mention in your first paragraph, and it would help a lot.

  12. Sven says:

    Is there any timeplan for a kind of release? And how and when it will be available for developers?

  13. Christian Campo says:

    We have recently been in contact with the SWT team to make SWT/Qt part of the SWT project on eclipse.org. I have sent them yesterday some screencasts and PDFs and I am waiting for their feedback and a conf call on this topic.

    So we plan to make this available under EPL and hope that we can host it as SWT Platform on eclipse.org. That can take some time. I like to wait and see how the talks go. Preferably I dont like to have a intermediate download but rather go directly to eclipse.org.

    Just be aware that while SWT/Qt works quit good its not production quality yet. So from time to time the JVM crashes and stuff like that.

  14. Kathir says:

    Looks very impressive. Can you explain in detail how to swap the plain swt with swt/qt. I would like to give a try with swt/qt on my application.

  15. Christian Campo says:

    As I posted in the Riena newsgroup (where you also asked), SWT/Qt and Riena are unrelated projects. So you can style ANY SWT application using SWT/Qt not just Riena. (Although our own motivation is Riena)

    SWT/Qt is currently not available but we are working on that and can you tell you more in a couple of weeks. Making it run will be then just as easy as selecting a SWT platform in your targetplatform. Your application code remains unchanged.

    Styling is set using the setData API of the Display or the Widget like

    display.setData(“stylesheet”, “……your Qt stylesheet goes here……”);
    or
    widget.setData(“stylesheet”,”……your Qt stylesheet ……”);

    christian

  16. Jan Ehrhardt says:

    It looks nice.

    But does SWT/Qt integrate the Qt Webkit component as an SWT browser? This would be great, since it would make a good browser component available on all platforms.

  17. Christian Campo says:

    Good point Jan. Currently the development is not finished. So we havnt got any SWT Browser widget. However our intention is to use the Qt functionality for everything that SWT has, so that SWT/Qt for Win32 would be the same as SWT/Qt for Mac. (code wise) That means to use Webkit (that is part of the Qt distribution) for the SWT browser widget and it also means for other stuff like starting a process to use Qt’s functionality.
    SWT is already moving to Webkit for one of its platforms and IE certainly does not cut the meat for some people and XULRunner has (as I heard) API stability issues.

    So yes that is our intention.

  18. Jan Ehrhardt says:

    Great to here, you will use Webkit.

    Will the project be open source? Is there some code, one could experiment with?

  19. christian campo says:

    In the meantime we where discussion the future of SWT/Qt in this bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=318484

    As a result, code base, docu and else moved to EclipseLabs to this location http://code.google.com/a/eclipselabs.org/p/swtqt/

  20. Marc says:

    One more question, since I am still following this project with a lot of interest.

    As mentioned in an earlier comment, swt/gtk is very slow (compared to win) and I am wondering if this could also happen to the qt-bridge. Let me explain why I think so: I know that the swt/win port directly calls the win-api natively. I am “guessing” that the gtk-version uses some kind of binding in between since I there are a lot of them already available and I think this might be the reason why gtk is much slower than win (please correct me if I am wrong). Your qt-port now also uses this bridge-approach (rather than calling qt-api in a native way). I hope that I am wrong and the binding between swt and qt doesnt take much performance. Can you say anything about that at this stage of development?

    Thanks

  21. christian campo says:

    1. You can really find out for yourself by download the SWT/Qt from http://code.google.com/a/eclipselabs.org/p/swtqt/ . Its all there and available for your platform.

    2. As far as I know all SWT implementation are “native” which means they use a direct binding to an C-API. Two exceptions. One is SWT/Cocoa which has a Java to Objective C calling thing, but also native and SWT/Qt which uses QtJambi. I am pretty sure that SWT/Gtk also calls some sort of C-layer in GTK (never checked myself)

    3. If you talk about speed there are many aspect that can be fast and slow. Is opening the menu fast or slow ? Its definitly as fast as you can get it from Qt (even with native binding). Same for most of the regular form based widgets. CSS styling is cool and I dont think it add much to your mileage. Applying a style initially takes a moment.

    Editing code is a tricky thing. There is a generic StyledTextWidget which “would” work on all SWT platforms. Buts its fairly slow. Thats the thing we have now also enabled in SWT/Qt. The Windows implementation (and the same is true for other platforms) dont use that generic widget but they have reimplemented it from scratch for their platform. So the windows StyledTextWidget will only work on Windows because its full of windows API dependencies. On the UP side its pretty fast.
    You can do the same for Qt using QtJambi and I believe you could also write something that is pretty fast. Hasnt been done until now.

    christian

  22. Marc says:

    OK…this is great :-)

    I just gave it a try and I am quite amazed. It didnt run on 3.6 so I had to download 3.5.2 but it was worth it. It doesnt look as good as windows at this stage, but it is already much faster than my gtk-version (of course this is a very subjective impression).

    Keep on the good work

Leave a Reply