Tuesday, September 22, 2015

FXDiagram - Diagram Repair

FXDiagram allows the user to choose which elements appear in a diagram and to arrange them individually. As this usually involves quite a bit of work diagrams can be saved. An obvious challenge is how to deal with model changes that happen after a diagram has been created. So here's a demo of FXDiagram's new feature for diagram repair:

Because in Xtext the EMF model gets partly replaced on model change, element identities usually get lost on change and traditional EMF transaction frameworks are not applicable. This is why there is a reconcile button, allowing the user to choose when it is worth to reconcile the diagram with the model.

In Xtext, elements are usually identified by their name property, while EMF uses URIs. Both schemes have their pros and cons: Names are independent of the element position in the model, but some elements don't have a name, e.g. the transactions in the statemachine example. URIs on the other hand usually refer to a fixed position in a model, which is in many cases to strict – imagine the order of Java class's methods would matter. Therefore FXDiagram uses a mix of both ideas.

To make the diagram repair action undoable, it is essential that the diagram stores all required information for display, independent of whether the source element still exists or not. For this purpose, I added LabelMappings to the mapping API. So if you want to leverage diagram repair for your own diagrams, you have to enhance your XDiagramConfigs. Have a look at the examples to get the idea,

The API changes that were necessary to implement this feature have effect the persistence format. Maybe old diagrams can no longer be loaded. If you have problems migrating old diagrams, let me know.

Monday, June 1, 2015

FXDiagram goes IDEA

You may have heard already that the Xtext team is currently porting Xtext and Xtend to IntelliJ IDEA. To get acquainted with the new APIs I decided to spend a few hours of my spare time to port FXDiagram as well. Here is a screencast of the first shot with a class diagram for Java code:

As the core of FXDiagram is independent of Eclipse, this was easier than expected. IDEA is a Swing (!) application, and the JFXPanel allows to embed JavaFX controls within Swing. The hardest part was actually to use Java as Xtend is not yet available on IDEA ;-)  FXDiagram's configurable model access made it easy to integrate with IDEA's PSI model and its transactions.

I must admit that the overall experience is a bit snappier in IDEA than in Eclipse. I assume this is because the Oracle team has spent more effort on the JFXPanel than on the FXCanvas. Unfortunately, multi-touch gestures don't work yet, but I had to port them to the the FXCanvas myself as well.

Friday, March 6, 2015

Xtext, Robots and Quirk Busters in San Francisco

Spring is around the corner and it is time for another EclipseCon NA.

This year I will be pretty busy: As some of my colleagues unfortunately cannot make it, I took over their sessions, resulting in one talk or tutorial per conference day. And as we decided to bring our XRobots game to our booth, that will likely keep me occupied for the rest of the conference. But I am really looking forward to it!

On Monday morning, Holger and me are giving a tutorial on Xtext for Beginners. Remember to bring your Laptop, as you are going to get your hands dirty implementing your first domain-specific language to create a Web-Application. Harbour A - Monday, 09:00 to 12:00.

On Tuesday, I am going to tell you why it is hard to integrate diagram editors with Xtext or an existing text-based IDE, and show how you can improve the user experience of a combined textual and graphical IDE. I will use FXDiagram, a framework that focuses on UX and keeping the developer in charge. It has made made great progress recently, so it is ready for adoption. Diagrams, Xtext and UX, Grand Peninsula EFG - Tuesday, 14:15 to 14:50

Wednesday is Xtext Day, an entire track exclusively on Xtext. I am going to substitute Moritz in the talk on Scoping, Linking and Indexing. From my experience, this is one of the first hurdles a language implementer has to take when using Xtext. Bayside AB - Wednesday, 15:00 to 15:35

XRobots is a robot sumo fight game. Players can challenge each other in writing the best script to push the opponent off the ring or tip him over. We are providing the game almost during the entire conference at our booth. All you need to participate is a web browser and some ambition to win :-) It has already been a huge success at EclipseCon Europe and Devoxx Belgium, so we hope the North Americans are as geek as the Europeans. If you want to know how we implemented it, you have to attend my session The Making of XRobots, Grand Peninsula EFG - Thursday, 14:30 to 15:05.

Tuesday, November 4, 2014

XRobots at EclipseCon Europe 2014

EclipseCon Europe 2014 was special to me: Miro, Holger and me had been preparing a robot game for our booth, and I was very curious whether it would work as expected and more than that whether people would like it. It turned out to be a blast: Some attendees even spent the after hours to work on their programs offline, and returned to our booth the next day to prove it. And even for those who didn't choose to compete, it was still a great show to watch.

The game works as follows: You write a script to control a robot in a wrestling fight. You win the game when your robot turns the opponent over or pushes it outside of the ring. Within the script, you can define how your robot should react on specific conditions, e.g. when it is close to the opponent. The robots can move, rotate, drive curves and lift up their scoop. You can read the own and the opponent’s position, view direction and speed.

The DSL is of course implemented with Xtext. You only need a web browser to join the game. We have enhanced Holger’s Xtext in the Web code to provide a web-editor with the usual Xtext goodies such as live validation, content assist, syntax highlighting, hovers etc. It worked really well and we plan to spend more time on Xtext in the web soon. As we have embedded the expression library Xbase, you can use all kind of expression and control structures.

To run your script you have enter a token which is shown on the game display at our booth. As soon as both robots are assigned, the scripts are executed by an interpreter on our game server, which makes two Lego Mindstorms robots engage in a fight.

The involved tools include Lejos, Xtend, Xtext with Xbase, Eclipse, Orion, Jetty, JavaFX and more. To locate the robots precisely enough we had to go for a video solution based on OpenCV. The Making-Of has been rather exciting, so we decided to file a talk on this for EclipseCon NA 2015. If you plan to attend and want to hear the story, vote for it!

The robots’ next gig will be at Devoxx in Antwerp next week. Of course we’ll bring them to  EclipseCon 2015 in San Francisco, too.

Apart from the robots, EclipseCon Europe 2014 was again gorgeous. The three sessions I gave went fine, I met a lot of really nice people and for the first time I had the time to watch the amazing Circus Eclipse. Thanks to the organizers and to the community to make EclipseCon such a great event.

PS: Our talk The Making of XRobots has been selected as one of three early birds for EclipseCon NA 2015! See you there!

Monday, October 13, 2014

Xtext, Xtend, JavaFX and Robots

EclipseCon Europe 2014“ style=It is autumn again and EclipseCon Europe 2014 is just around the corner. To me as an Eclipse committer from Germany ECE always feels a bit like meeting the family. In fact, I have been attending for seven years in a row now. I even remember the times when it was called Eclipse Summit Europe. Oh man, I am getting old…

As every year, my colleagues and me are contributing the program: I have counted 14 sessions by itemis and I am going to give three myself. Of course there is a lot about Xtext and Xtend, but also on other topics like Java performance or home automation. And itemis is sponsoring again.

For me it starts Tuesday morning: Sven and me are going to give a tutorial on Functional Programming With Xtend. Xtend — the JVM language developed at Eclipse — offers a great set of features to exploit the benefits of functional programming without the verbosity of Java. This session not only gives an introduction on functional programming in general but it is also a good opportunity to look beyond Duke’s nose. Bring your laptop, you are going to get your hands dirty!

No EclipseCon without me on graphical editing: In Diagrams, Xtext and UX I am going demonstrate how you can add diagrams to your textual Xtext languages without adding usability pains. I am going to use the JavaFX based framework FXDiagram which offers superior UI metaphors for the end users in combination with more freedom for the developer. Watch it in action on Tuesday afternoon.

On Wednesday, Holger and me are going to show you what’s New & Noteworthy in Xtext. We have recently finalized the Xbase API for DSLs with expressions, concurrency in the IDE has been reworked, we have parallelized the builder and much more. We plan to give a sneak preview of the IntelliJ support as well.

But the ultimate reason why you must attend EclipseCon Europe 2014 is going to be at our booth. Miro, Holger and me have created a new game for you using all the technologies above (and more). So be prepared to encounter these two guys.

Tuesday, August 26, 2014

Graphical Views for Xtext ctd.

(Read my previous post for a rationale on graphical views)

No matter with what graphics technology you choose to implement a diagram for your Xtext-based language, there are a few things you should know in order to connect the diagram view/editor to the rest of the infrastructure.

Let us first have a look how to implement a context menu action for the Xtext editor to show the element at the current cursor position in the diagram. In Eclipse, you have to implement a handler for such an action. Xtext offers a bunch of classes making your life easier. EditorUtils detects the Xtext editor for the handler’s action and EObjectAtOffsetHelper finds the semantic model element at a given text offset.

As the document – and thereby the model parsed from it – is subject to editing, you have to make sure nobody is changing it while you traverse it to derive your diagram. You can execute code in a read transaction on the XtextDocument by wrapping it in an IUnitOfWork that you pass to the XtextDocument#readOnly method.

The following snipped shows an example handler written in Xtend.

Note that the @Inject annotation in the example requires you to use your language's executable extension factory when you register the handler class it in the plugin.xml of your language's UI plug-in. See the Xtext documentation for details.

To navigate from a diagram element back to it’s element definition in the text, you need to store some back reference. The model element itself is not suitable, as its lifecycle is bound to the one of the editor, and the parser is even free to expunge model elements whenever the document is re-parsed. As Xtext is based on EMF, each model element has a unique URI. You should always use these URIs to store references to model elements beyond the boundaries of a read/write transaction. An element’s URI is provided by EMF's EcoreUtil#getURI method.

Having the URI, the navigation to the respective model element’s definition is easiest to implement using Xtext’s IURIEditorOpener. If your diagram view supports selection listeners, the respective Xtend code could look like this:

Friday, August 22, 2014

Graphical Views for Xtext

Xtext provides you with a powerful IDE and a rich featured text editor for your domain-specific language with little effort. But sometimes, a picture says more than a thousand words: You want to have some additional graphical representation of your models, a set of diagrams.

Diagrams are superior to code when it comes to high-level views. But while programmers can easily cope with files that contain several hundred lines of code, the same amount of information usually blows a diagram and destroys all its suggestiveness. Diagrams with just a few nodes and edges showing on a certain aspect of the models only are best fit for human readers. Such aspects are often spread across various model files. So in order to add the best value for the language users on top of an Xtext infrastructure, we need to allow them to create multiple diagrams, each highlighting just a subset of model information, picked from multiple model files. In other words, diagrams that have a completely different structure than their associated textual models.

Traditional graphical editing frameworks focus on editing the underling model through the diagram.
But synchronizing the model changes from textual and diagram editors is very hard if their content's structures differ. In most cases, the integration will lead to major usability quirks like unexpected editor behavior, forced save operations, blocked editors or even data loss.

So rather than working around the hard challenges of integrating graphical and textual model editing, we can leave model modification to Xtext. For the graphical stuff we can concentrate on diagram editing and leave the underlying model read-only. This way we can spend our energy on the things that really matter to the user, like easy and useful ways to populate diagrams or best visual appearance.

In Eclipse, one could build such graphical views using Zest or GEF. If model and diagram do not differ too much in structure, a small code generator targeting GraphViz is a very simple solution with high quality output.

The general integration with Xtext is covered in a follow up post.

The following screencast shows another solution for an Xtext-based domain model language. The graphical editor is using FXDiagram, a diagram framework based on JavaFX. FXDiagram offers a very smooth user experience, excellent rendering, support for touch-pad gestures, animated undo/redo, diagram persistence, export to scalable vector graphics and much more. If you are interested in learning more, feel free to contact me.