Today someone approach me and his introduction statement was that he’s interested in XWT and was told that Eclipse 4.1 is built upon XWT. I’ll restate the same I’ve stated in all of my talks: XWT is a technology developed in the e4-Incubator side by side with the Eclipse 4 Application Platform.
The important thing here is SIDE BY SIDE which means XWT nor the Eclipse 4 Application Platform have a dependency on each other! The Eclipse 4 Application platform makes no assumption on the technology you use to write/describe your UI – the system is extremely open which I highlighted in another blog where I used Swing to render the UI.
So once more the important message: Eclipse 4.1 does not depend on XWT nor does XWT depend on Eclipse 4.1
Could you go a bit further into architectural relationship between 4.x and XWT?
I originally thought that XWT is one possible language to define 4.x UI with. That is XWT sits on top of 4.x UI model.
Now I am starting to suspect that XWT sits in the same spot as SWT and Swing (as rendering technology). I have to admit that I find this bit confusing. Why would there be an advantage in having another intermediary layer between 4.x UI model and SWT. Is XWT a competing API for writing renderers?
XWT can sit on top of Eclipse 4.x like any other technology can.
Please note that I’m not an expert on XWT my important message is: Useing Eclipse 4 Application Platform doesn’t require you to use XWT nor you get any dependency on it.
So is XWT the default serialization format when you author 4.x UI definitions using the model editor as is shown in all the 4.x demos or is there another file format that is “core” to 4.x?
You mention that neither XWT nor Eclipse 4.x have dependency on each other. How does that work? Where does the bridging code live?
No XWT has nothing todo with the workbench! When authoring Eclipse 4 Applications using the model editor you are authoring our application model defined as an .ecore and the default serialization format used by e4 is XMI because EMF provides us support for it by default. The application model is not only storing UI but the complete application state including e.g. handlers, commands, keybindings, … XWT is not involved at all.
The application model also is only defining abstract UI-Concepts like PartStack, Window, … but does not talk about the concrete widget used on screen when shown to the user. In contrast to that in XWT you clearly say: That you want a CTabFolder, Shell, … so the only thing you can use XWT for is to author the content inside your Part (in 3.x terms ViewPart/Editor and what you do there in createPartControl) and then you need write the bridging code your own. All the framework does is to pass along a parent Composite to your Pojo when it is wired using DI. So when using XWT your Pojo might look like this:
The framework itself does NOT care what you are doing after the wireing happened inside your code. This is totally up to you.
That helps. I now understand that there are two XML formats for defining UI under e4/4.x umbrella (with somewhat different capabilities). Further, it doesn’t appear that XWT has any particular connection to 4.x. It sounds like it can just as easily be used to create 3.x UI.
I think at this point you should have a pretty good appreciation for why this topic is so confusing to those outside the 4.x core team. It probably doesn’t help that some of those involved with XWT have been presenting it as _the_ definition language for writing 4.x UI.
Perhaps it would be worth it to consider moving XWT effort out of the e4 incubator to remove the confusion with the 4.x effort.
At the very least, this topic needs more prominent focus in the 4.x outreach efforts. This blog post is a good start at that. Thanks for educating me and others in similar position.