tag:blogger.com,1999:blog-14952233119883585282024-03-13T14:00:45.198+01:00Jan's BlogAnonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.comBlogger67125tag:blogger.com,1999:blog-1495223311988358528.post-22002822140466959032016-02-10T11:37:00.004+01:002016-02-10T11:37:58.497+01:00Founding TypeFox<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-P-AnbYwdCuc/Vrm0auL_A_I/AAAAAAAABU8/uVs2odE09Qc/s1600/1.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="142" src="https://2.bp.blogspot.com/-P-AnbYwdCuc/Vrm0auL_A_I/AAAAAAAABU8/uVs2odE09Qc/s200/1.jpg" width="200" /></a></div>
After 8 exciting years as an employee at itemis, I eventually decided to become my own boss. Together with <a href="http://blog.efftinge.de/">Sven</a> I founded a new enterprise named <a href="http://www.typefox.io/"><i>TypeFox</i></a>. From the team constellation you might already have guessed it: TypeFox is going to be all about <a href="http://xtext.org/">Xtext</a>, <a href="http://xtend-lang.org/">Xtend</a>, languages and tools.<br />
<br />
Of course, we will continue the development of Xtext, Xtend, <a href="http://jankoehnlein.github.io/FXDiagram/">FXDiagram</a> etc. at <i>TypeFox</i>, and provide professional services and support around these topics on demand.<br />
<br />
Check out our shiny new website at <a href="http://www.typefox.io/">http://www.typefox.io</a>. It also hosts a <a href="http://www.typefox.io/blogs">new blog</a> on which we are going to post interesting articles about Xtext & Co on a regular basis, starting with contributions by <a href="http://www.lorenzobettini.it/">Lorenzo Bettini</a>, Sven and yours sincerely. Let us know what you think!<br />
<br />
Happy Xtext-ing!
Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com1tag:blogger.com,1999:blog-1495223311988358528.post-89418348638769122462015-09-22T23:59:00.001+02:002015-09-22T23:59:36.717+02:00FXDiagram - Diagram Repair<a href="http://jankoehnlein.github.io/FXDiagram/">FXDiagram</a> 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 <i>diagram repair</i>:<br />
<br />
<iframe src="https://player.vimeo.com/video/140114471" width="580" height="353" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
<br />
<br />
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.<br />
<br />
In <a href="http://www.xtext.org/">Xtext</a>, elements are usually identified by their name property, while <a href="https://eclipse.org/modeling/emf/">EMF</a> 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. <br />
<br />
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 <i>LabelMappings</i> to the mapping API. So if you want to leverage diagram repair for your own diagrams, you have to enhance your <i>XDiagramConfigs</i>. Have a look at the examples to get the idea,<br />
<br />
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. <br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com0tag:blogger.com,1999:blog-1495223311988358528.post-85254736874387381772015-06-01T08:00:00.000+02:002015-06-01T11:28:34.696+02:00FXDiagram goes IDEAYou may have heard already that the <a href="http://xtext.org/">Xtext</a> team is currently porting Xtext and <a href="http://xtend-lang.org/">Xtend</a> to <a href="https://www.jetbrains.com/idea/">IntelliJ IDEA</a>. To get acquainted with the new APIs I decided to spend a few hours of my spare time to port <a href="http://jankoehnlein.github.io/FXDiagram/">FXDiagram</a> as well. Here is a screencast of the first shot with a class diagram for Java code:<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="353" src="https://www.youtube.com/embed/cyJv5BzEe5Q" width="580"></iframe><br />
<br />
As the core of FXDiagram is independent of Eclipse, this was easier than expected. IDEA is a Swing (!) application, and the <a href="https://docs.oracle.com/javase/8/javafx/api/javafx/embed/swing/JFXPanel.html">JFXPanel</a> 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 <a href="https://confluence.jetbrains.com/display/IDEADEV/IntelliJ+IDEA+Architectural+Overview#IntelliJIDEAArchitecturalOverview-PsiElements">PSI model</a> and its transactions.<br />
<br />
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 <a href="https://github.com/JanKoehnlein/JavaFX-SWT-Gesture-Bridge">port them to the the FXCanvas</a> myself as well.<br />
<br />Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com0tag:blogger.com,1999:blog-1495223311988358528.post-19097126133232829072015-03-06T10:13:00.002+01:002015-03-06T10:13:37.717+01:00Xtext, Robots and Quirk Busters in San FranciscoSpring is around the corner and it is time for another <a href="https://www.eclipsecon.org/na2015">EclipseCon NA</a>.<br />
<br />
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!<br />
<br />
On Monday morning, <a href="http://holgerschill.blogspot.de/">Holger</a> and me are giving a tutorial on <a href="https://www.eclipsecon.org/na2015/session/xtext-beginners">Xtext for Beginners</a>. 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.<br />
<br />
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 <a href="http://jankoehnlein.github.io/FXDiagram/">FXDiagram</a>, 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. <a href="https://www.eclipsecon.org/na2015/session/diagrams-xtext-and-ux">Diagrams, Xtext and UX</a>, Grand Peninsula EFG - Tuesday, 14:15 to 14:50 <br />
<br />
<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/C2BBew78uhM" width="560"></iframe>
<br />
<br />
Wednesday is <a href="http://xtextday.org/">Xtext Day</a>, an entire track exclusively on <a href="http://www.xtext.org/">Xtext</a>. I am going to substitute Moritz in the talk on <span class="qtip-link scoping-linking-and-indexing qtip-title-field"><a class="session-title" href="https://www.eclipsecon.org/na2015/session/scoping-linking-and-indexing">Scoping, Linking and Indexing</a>. From my experience, this is one of the first hurdles a language implementer has to take when using Xtext. </span>Bayside AB - Wednesday, 15:00 to 15:35 <br />
<span class="qtip-link scoping-linking-and-indexing qtip-title-field"><br /></span>
<span class="qtip-link scoping-linking-and-indexing qtip-title-field"><a href="https://storify.com/itemis/xrobots">XRobots</a> 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 </span><span class="qtip-link the-making-of-xrobots qtip-title-field"><a class="session-title" href="https://www.eclipsecon.org/na2015/session/making-xrobots">The Making of XRobots</a>, </span><span class="qtip-link the-making-of-xrobots qtip-title-field">Grand Peninsula EFG - Thursday, 14:30 to 15:05.</span><br />
<br />
<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/ffAmf8-36I0" width="560"></iframe>
Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com0tag:blogger.com,1999:blog-1495223311988358528.post-61608206360788086272014-11-04T10:11:00.000+01:002014-11-04T19:57:42.842+01:00XRobots at EclipseCon Europe 2014<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-PKRwZ0ZaRHs/VFiOMp4qUkI/AAAAAAAAAa4/t9pTi39C7Yo/s1600/IMG_0929.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-OLMnlwlXTkM/VFiOCJMpqLI/AAAAAAAAAaw/x4o5n6H6eKs/s1600/IMG_0927.jpg" height="271" width="400" /></a></div>
<br />
<a href="https://www.eclipsecon.org/europe2014/">EclipseCon Europe 2014</a> 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.<br />
<br />
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.<br />
<br />
The DSL is of course implemented with <a href="http://www.eclipse.org/Xtext/">Xtext</a>. You only need a web browser to join the game. We have enhanced Holger’s <a href="http://holgerschill.blogspot.de/2012/11/xtext-in-web.html">Xtext in the Web</a> 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 <a href="http://www.eclipse.org/Xtext/documentation.html#sevenlang_introduction">Xbase</a>, you can use all kind of expression and control structures.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-PKRwZ0ZaRHs/VFiOMp4qUkI/AAAAAAAAAa8/ceMSjWgueKg/s1600/IMG_0929.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-PKRwZ0ZaRHs/VFiOMp4qUkI/AAAAAAAAAa8/ceMSjWgueKg/s1600/IMG_0929.jpg" height="236" width="400" /></a></div>
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. <br />
<br />
The involved tools include <a href="http://www.lejos.org/">Lejos</a>, <a href="http://xtend-lang.org/">Xtend</a>, <a href="http://xtext.org/">Xtext with Xbase</a>, <a href="http://www.eclipse.org/">Eclipse</a>, <a href="http://www.eclipse.org/orion/">Orion</a>, <a href="http://www.eclipse.org/jetty/">Jetty</a>, <a href="http://docs.oracle.com/javase/8/javafx/get-started-tutorial/jfx-overview.htm#JFXST784">JavaFX</a> and more. To locate the robots precisely enough we had to go for a video solution based on <a href="http://opencv.org/">OpenCV</a>. The Making-Of has been rather exciting, so we decided to file a talk on this for <a href="https://www.eclipsecon.org/na2015/">EclipseCon NA 2015</a>. If you plan to attend and want to hear the story, <a href="https://www.eclipsecon.org/na2015/session/making-xrobots">vote for it</a>!<br />
<br />
The robots’ next gig will be at <a href="http://www.devoxx.be/">Devoxx in Antwerp</a> next week. Of course we’ll bring them to <a href="https://www.eclipsecon.org/na2015/">EclipseCon 2015</a> in San Francisco, too.<br />
<br />
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.<br />
<br />
PS: Our talk <a href="https://www.eclipsecon.org/na2015/session/making-xrobots">The Making of XRobots</a> has been selected as one of three early birds for EclipseCon NA 2015! See you there!Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com0tag:blogger.com,1999:blog-1495223311988358528.post-10202258142062544802014-10-13T20:18:00.000+02:002014-10-13T20:24:59.314+02:00Xtext, Xtend, JavaFX and Robots<a href="http://www.eclipsecon.org/europe2014" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img 1em="" alt="EclipseCon Europe 2014“ style=" clear:="" float:="" height="100" margin-bottom:="" right="" src="https://www.eclipsecon.org/europe2014/sites/default/files/ECE%20Friends%20100x100%20I%27m%20speaking%20at.png" width="100" /></a>It is autumn again and <a href="http://www.eclipsecon.org/europe2014">EclipseCon Europe 2014</a> 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…<br />
<br />
As every year, my colleagues and me are contributing the program: I have counted <a href="https://www.eclipsecon.org/europe2014/program/sessions/accepted?keys=itemis&field_experience_value=All">14 sessions</a> by <a href="http://www.itemis.de/">itemis</a> and I am going to give three myself. Of course there is a lot about <a href="http://www.xtext.org/">Xtext</a> and <a href="http://www.xtend.org/">Xtend</a>, but also on other topics like Java performance or home automation. And itemis is sponsoring again.<br />
<br />
For me it starts Tuesday morning: Sven and me are going to give a tutorial on <a href="https://www.eclipsecon.org/europe2014/session/functional-programming-xtend">Functional Programming With Xtend</a>.
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!<br />
<br />
No EclipseCon without me on graphical editing: In <a href="https://www.eclipsecon.org/europe2014/session/diagrams-xtext-and-ux">Diagrams, Xtext and UX</a> 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 <span id="goog_2127161175"></span><a href="https://www.blogger.com/">FXDiagram<span id="goog_2127161176"></span></a> which offers superior UI metaphors for the end users in combination with more freedom for the developer. Watch it in action on Tuesday afternoon.<br />
<br />
On Wednesday, Holger and me are going to show you what’s <a href="https://www.eclipsecon.org/europe2014/session/new-noteworthy-xtext">New & Noteworthy in Xtext</a>. 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.<br />
<br />
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.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="281" mozallowfullscreen="" src="//player.vimeo.com/video/108802845" webkitallowfullscreen="" width="500"></iframe>Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com0tag:blogger.com,1999:blog-1495223311988358528.post-90771693562657170092014-08-26T10:50:00.001+02:002014-08-26T11:14:45.296+02:00Graphical Views for Xtext ctd.(Read my <a href="http://koehnlein.blogspot.de/2014/08/graphical-views-for-xtext.html">previous post</a> for a rationale on graphical views)<br />
<br />
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. <br />
<br />
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 <i>handler</i> for such an action. Xtext offers a bunch of classes making your life easier. <i>EditorUtils</i> detects the Xtext editor for the handler’s action and <i>EObjectAtOffsetHelper</i> finds the semantic model element at a given text offset.<br />
<br />
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 <i>XtextDocument</i> by wrapping it in an <i>IUnitOfWork</i> that you pass to the <i>XtextDocument#readOnly</i> method.<br />
<br />
The following snipped shows an example handler written in <a href="http://www.xtend-lang.org/">Xtend</a>.<br />
<br />
<script src="https://gist.github.com/JanKoehnlein/c260544ef13e89096e10.js"></script>
Note that the <i>@Inject</i> annotation in the example requires you to use your language's executable extension factory when you register the handler class it in the <i>plugin.xml</i> of your language's UI plug-in. See the <a href="http://www.eclipse.org/Xtext/documentation.html#equinoxSetup">Xtext documentation</a> for details. <br />
<br />
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 <a href="http://www.eclipse.org/modeling/emf/">EMF</a>, 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 <i>EcoreUtil#getURI</i> method.<br />
<br />
Having the URI, the navigation to the respective model element’s definition is easiest to implement using Xtext’s <i>IURIEditorOpener</i>. If your diagram view supports selection listeners, the respective Xtend code could look like this:<br />
<br />
<script src="https://gist.github.com/JanKoehnlein/7b35aecde807eb317fcc.js"></script>Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com6tag:blogger.com,1999:blog-1495223311988358528.post-13596911475679043812014-08-22T19:22:00.000+02:002014-08-26T11:14:23.218+02:00Graphical Views for Xtext<a href="http://www.eclipse.org/Xtext/">Xtext</a> 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.<br /><br />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.<br /><br />Traditional graphical editing frameworks focus on editing the underling model through the diagram. <br />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.<br />
<br />So rather than working around the hard challenges of integrating graphical and textual <i>model</i> editing, we can leave model modification to Xtext. For the graphical stuff we can concentrate on <i>diagram</i> 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. <br />
<br />
In Eclipse, one could build such graphical views using <a href="http://www.eclipse.org/gef/zest/">Zest</a> or <a href="http://www.eclipse.org/gef">GEF</a>. If model and diagram do not differ too much in structure, a small code generator targeting <a href="http://www.graphviz.org/">GraphViz</a> is a very simple solution with high quality output. <br />
<br />
The general integration with Xtext is covered in a <a href="http://koehnlein.blogspot.de/2014/08/graphical-views-for-xtext-ctd.html">follow up post</a>.<br />
<br />
The following screencast shows another solution for an Xtext-based domain model language. The graphical editor is using FXDiagram, a diagram framework based on <a href="http://docs.oracle.com/javafx/">JavaFX</a>. 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.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="326" mozallowfullscreen="" src="//player.vimeo.com/video/104115680" webkitallowfullscreen="" width="580"></iframe> <br />
<br />Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com2tag:blogger.com,1999:blog-1495223311988358528.post-35248736056376031352013-11-01T13:13:00.000+01:002013-11-02T20:18:21.880+01:00Where no diagram editor has ever gone before...I should have been more suspicious about the Ferengi salesman I bought my LCARS system from. Ferengi have always been skeptical towards JavaFX. I should have known that this device had been tampered with in order to bring my system down in the middle of my demo at <a href="http://www.eclipsecon.org/europe2013/">EclipseCon Europe</a>. Ferengi petaq!<br />
<br />
Nevertheless, I could organize a new working LCARS terminal now and here is my demo. It demonstrates JavaFX's flexibility to create a diagram editor that does neither look like nor behave like a dull lines and boxes editor.
<br />
<br />
I extracted the data from the StarTrek fansite <a href="http://en.memory-alpha.org/wiki/Portal:Main">Memory Alpha</a> and stored it in a local <a href="http://www.mongodb.org/">mongoDB</a>. The font is from <a href="http://www.gtjlcars.de/">GTJLCARS</a>. SVG export extends some code from the <a href="http://jfxtras.org/">JFXtras project</a> initially written by <a href="http://harmoniccode.blogspot.de/2012/11/shapes-shapes-shapes.html">Gerrit Grunwald</a>. Thanks to all of you, guys.<br />
<br />
EclipseCon Europe was once again big fun: I attended a number of cool presentations, met a lot of old friends and got acquainted with a bunch of new people. Thanks for the organizers to provide such a fine event. But without any further delay, here's the demo:
<br />
<br />
<iframe src="//player.vimeo.com/video/78335676" width="500" height="375" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com6tag:blogger.com,1999:blog-1495223311988358528.post-40178651981418337902013-10-22T21:45:00.000+02:002013-10-23T08:36:15.746+02:00Eclipse Diagram Editors From A User's PerspectiveI believe that the Eclipse's diagram editing frameworks have a lot to catch up when it comes to usability. For illustration I've created a screencast on how a typical Eclipse graphical editor appears to a user. I have used the Ecore Tools editor as an example, but most issues presented are caused by defaults of GMF or GEF which are pretty hard to change. So don't be surprised if you re-encounter these or similar issues in Graphiti, Sirius etc. The screencast doesn't even cover the rendering errors described in my <a href="http://koehnlein.blogspot.de/2013/09/obi-wan-at-edge.html">previous blog post</a>.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="281" mozallowfullscreen="" src="//player.vimeo.com/video/77529958" webkitallowfullscreen="" width="500"></iframe><br />
<br />
So what has gone wrong?<br />
<br />
In my opinion, diagram editor behavior and editing metaphors haven't really changed since the first commits on the GEF project in 2002. Advances in UI design and usability have had almost no priority on Eclipse's graphical frameworks since then. They were built from a pure developer's perspective. So a lot of effort has been spent on:<br />
<ul>
<li>Facilitating the development of new editors. This usually causes a restriction to very specific use cases. </li>
<li>Establishing weird processes to implement new diagram editors. </li>
<li>Repeatedly putting new abstraction layers on top of the existing ones. Hide the seemingly ugly or incomprehensible concepts of a base framework. The problem is to find better abstractions that don't leak. In the end you often have to learn both (or more) frameworks in order to use them. </li>
<li>Building on top of existing frameworks with serious limitations, like integer coordinates, missing alpha channel, no hardware acceleration etc. </li>
<li>Supporting very large diagrams. Yes, there are very big models. But diagrams with hundreds of nodes and connections only make good wallpapers.</li>
<li>Creating new compatibility APIs, e.g. to replace the rendering engine. These will limit the available functionality to the common minimum set of features of all backends. </li>
<li>Changing a model graphically. Note the difference between editing a diagram – e.g. to make it look nicer – and changing the underlying model. Did you ever wonder why <a href="http://www.eclipse.org/gef/zest/">GEF Zest</a> is the only Eclipse diagram framework with its own diagram layout algorithms and basic support for multi-touch gestures? </li>
</ul>
Computers don't need diagrams. Diagrams are for humans. Their strength is to explain a part of a model in a very suggestive way. Taking the human user into focus changes the requirements for a graphical framework drastically. Issues like the following must have top priority: <br />
<ul>
<li>Appealing visual design, </li>
<li>Intuitive editing metaphors, </li>
<li>Snappy behavior, </li>
<li>Support for modern input devices, and </li>
<li>The possibility for individual customization. </li>
</ul>
How do we get there? Attend my talk <a href="http://www.eclipsecon.org/europe2013/eclipse-diagram-editors-endangered-species">Eclipse Diagram Editors - An Endangered Species</a> at <a href="http://eclipsecon.org/europe2013/">EclipseCon Europe</a> for some propositions and an extensive demo.<br />
<br />
<a href="http://www.eclipsecon.org/europe2013"><img alt="EclipseCon Europe 2013" border="0" height="60" src="http://www.eclipsecon.org/europe2013/sites/eclipsecon.org.europe2013/files/eclipsecon%20logo%20480px%20x%2060px.jpg?1367366051" width="480" /></a>
Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com8tag:blogger.com,1999:blog-1495223311988358528.post-84582818711374677532013-10-11T16:01:00.003+02:002013-10-11T16:01:40.989+02:00Multi-touch Gestures For JavaFX Apps Running in SWT<a href="http://www.eclipsecon.org/europe2013"><img align="right" alt="EclipseCon Europe 2013" border="0" height="80" src="http://www.eclipsecon.org/europe2013/sites/eclipsecon.org.europe2013/files/eclipsecon%20logo%20100%20x%2080px%20round%20corners%202.jpg?1367363894" width="100" /></a>
I am currently preparing a demo for <a href="http://www.eclipsecon.org/europe2013/eclipse-diagram-editors-endangered-species">my talk at EclipseCon Europe 2013</a>. Embedding my <a href="http://docs.oracle.com/javafx/">JavaFX</a> based graphical editor into <a href="http://www.eclipse.org/">Eclipse</a> went smoothly thanks to the <a href="http://docs.oracle.com/javafx/2/api/javafx/embed/swt/FXCanvas.html">FXCanvas</a> that bridges SWT and JavaFX. But I realized that multi-touch gestures did no longer work.<br />
<br />
I filed a <a href="https://javafx-jira.kenai.com/browse/RT-33454">bug</a> for that, but I could not resist trying to find out what's wrong myself. You may not know that the sources of JavaFX are open now. So after cloning their <a href="https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-GettingtheSources">mercurial repo</a> and browsing a couple of classes I found out that SWT's <a href="http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fevents%2FGestureEvent.html">GestureEvents</a> are neither converted to JavaFX <a href="http://docs.oracle.com/javafx/2/api/javafx/scene/input/GestureEvent.html">GestureEvents</a> nor transferred to an embedded JavaFX canvas. The implementation was simply missing.<br />
<br />
So with some help by Tom Schindl and Steve Northover (thanks a lot, guys!) I hacked a solution that works fine for me, as you can see in the screencast below. If you're interested you can <a href="https://github.com/JanKoehnlein/JavaFX-SWT-Gesture-Bridge">download my the code from github</a>. <br />
<br />
<iframe src="//player.vimeo.com/video/76691561" width="500" height="281" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com0tag:blogger.com,1999:blog-1495223311988358528.post-77642870974949302742013-09-07T12:10:00.000+02:002013-09-07T12:12:03.938+02:00Obi-Wan at the Edge<blockquote class="tr_bq">
<i>There are two hard problems in computer science: cache validation, variable substitution, and off-by-one errors.</i> <i>(unknown source)</i></blockquote>
The uncounted latter is often referred to as OBOE or, with a geek sense of humor, "Obi-Wan error".<br />
<br />
<h3>
Obi-Wan In Eclipse Diagram Editors</h3>
<a href="http://koehnlein.blogspot.de/2012/01/impressions-on-gef.html">In an older post</a>, I already mentioned one major weakness of <a href="http://www.eclipse.org/gef/">GEF</a> (3.x): All coordinates are integers. One problem with that is that it can easily result in off-by-one rendering bugs. That unfortunately holds for many frameworks built on top of GEF. Have a close look at the gradient fill, anchor points (where connections are touching the nodes), clipping bounds and the arrow head in the following screenshots from the standard examples:<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-hpj7jxY4dME/Uiml_kv_WyI/AAAAAAAAAPM/zUw9yhvVlx8/s1600/Bildschirmfoto+2013-09-05+um+08.25.21.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="153" src="http://4.bp.blogspot.com/-hpj7jxY4dME/Uiml_kv_WyI/AAAAAAAAAPM/zUw9yhvVlx8/s320/Bildschirmfoto+2013-09-05+um+08.25.21.png" width="320" /></a></div>
Integer vs. double coordinates is comparable to raster vs. vector
images. While in integer coordinates a point usually means a pixel, in
double
coordinates a point has no area and a line can be infinitesimally thin. In a world of double precision it is obvious that we need some <i>rendering</i>. We are forced to think about things like line width, stroke type,
line caps, line joins,
miters, etc. There are excellent
explanatory pictures on these in the <a href="http://docs.oracle.com/javafx/2/api/javafx/scene/shape/Shape.html">JavaDocs of JavaFX's Shape class</a>.<br />
<br />
<h3>
"Smooth" Curves</h3>
You have to take round-off errors into account when approximating smooth curves (splines) with integer polylines. Otherwise your allegedly smooth curve will go zigzag. This might be the reason why GEF does not have any curves. GMF does: <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-tycVyZw5O1c/UimoS_pmVBI/AAAAAAAAAPo/btxvGXEkdrI/s1600/Bildschirmfoto+2013-09-06+um+12.02.36.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="http://4.bp.blogspot.com/-tycVyZw5O1c/UimoS_pmVBI/AAAAAAAAAPo/btxvGXEkdrI/s320/Bildschirmfoto+2013-09-06+um+12.02.36.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<h3>
</h3>
<h3>
Arrow Heads</h3>
I'd expect an edges arrow head them to be aligned with the tangent of the edge at the anchor point. For polylines this is the line connecting the anchor with the last bendpoint. Same for Bézier curves, but apparently not for splines like these:<br />
<br />
<div style="text-align: center;">
<a href="http://3.bp.blogspot.com/-Si2Jl0DzsF8/UiroFBLRvyI/AAAAAAAAAP4/0p6ezGsasiQ/s1600/Bildschirmfoto+2013-09-07+um+10.43.54.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-Si2Jl0DzsF8/UiroFBLRvyI/AAAAAAAAAP4/0p6ezGsasiQ/s1600/Bildschirmfoto+2013-09-07+um+10.43.54.png" /></a> </div>
It is also a good idea to prohibit bendpoints too close to the anchor: The inclination of the curve may become too steep:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-LIHpQSnYRD0/UirqacOSO9I/AAAAAAAAAQE/LDADjWjK5AU/s1600/Bildschirmfoto+2013-09-07+um+10.53.51.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-LIHpQSnYRD0/UirqacOSO9I/AAAAAAAAAQE/LDADjWjK5AU/s1600/Bildschirmfoto+2013-09-07+um+10.53.51.png" /></a></div>
<br />
The last screenshot also shows that the line cap style plays a role at the tip of the arrow head. <br />
<h3>
</h3>
<h3>
Use the Force</h3>
<a href="http://wiki.eclipse.org/GEF/GEF4">GEF 4</a> will have double coordinates and Bézier curves. But at the
time of writing this blogpost, there hasn't been an official release
yet. It is not clear either whether and when it will be adopted by downstream projects. <br />
<br />
I came across all this when trying to calculate edges and arrow heads for
my sparetime <a href="http://www.oracle.com/technetwork/java/javafx/overview/index.html">JavaFX</a> diagram editor project. Luckily, JavaFX uses double
coordinates only. JavaFX also includes quadratic and cubic Bézier curves. These curves are really smooth and drawn fast, though I must admit I'd have expected B-Splines at least.<br />
<br />
I am going to demonstrate this at <a href="http://www.eclipsecon.org/europe2013/eclipse-diagram-editors-endangered-species">EclipseCon Europe 2013</a>. Stay tuned for more.<br />
<br />Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com0tag:blogger.com,1999:blog-1495223311988358528.post-69926782154026012912013-06-12T20:34:00.001+02:002013-06-12T20:52:31.439+02:00Using Xcore in XtextWith <a href="http://xtext.org/">Xtext</a> you can easily create your own textual language. The structure of the language is defined in an <a href="http://www.eclipse.org/modeling/emf/">Ecore</a> model. This model can be automatically derived from the grammar, which allows quick turnarounds in the beginning. But in the long run, this model becomes an increasingly important API to the language. You want to fix it and make it a first class artifact: You are switching from an <a href="http://www.eclipse.org/Xtext/documentation.html#metamodelInference">inferred Ecore model to an imported one</a> in the grammar.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://wiki.eclipse.org/images/2/27/XcoreLogo.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://wiki.eclipse.org/images/2/27/XcoreLogo.png" height="200" width="200" /></a></div>
Traditionally, you use EMF's tree editors to edit Ecore models. That can be cumbersome as the tooling is not the nicest to use. Furthermore, the Ecore model only describes the declarative part. Behavior, such as the body of <i>EOperations</i> or the code for derived <i>EStructuralFeatures</i> has to be woven in either from additional models or directly in the generated code. These and more issues are addressed by <a href="http://wiki.eclipse.org/Xcore">Xcore</a>. Xcore allows to specify Ecore models textually, including the behavioral parts and the code generation parameters. Having a single source of information facilitates the maintanance of such a model drastically. Xcore is shipped with EMF.<br />
<br />
In the upcoming <a href="http://www.eclipse.org/downloads/index-developer.php">Eclipse release 4.3 (Kepler)</a> Xcore and Xtext can be used together. Here is a step-by-step example how to do this with Xtext's "Greetings" language:<br />
<ol>
<li>Create an Xtext project <i>File > New > Project > Xtext Project</i>. The defaults are fine. This will create the usual four projects for your Xtext language in your workspace.</li>
<li>By default, Xcore generates its code to the folder <i>src-gen</i>. The same folder is used by Xtext and will be wiped each time you regenerate the language from the grammar. To avoid loosing data, choose a separate output folder for Xcore: <i>Eclipse/Window > Preferences > Xcore > Compiler > Output Folder > Directory > ./</i><i>emf-gen<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-HMns9Y51vU0/Ubibt9iQVKI/AAAAAAAAAOo/HpKH9WuZOJk/s1600/preferences.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-HMns9Y51vU0/Ubibt9iQVKI/AAAAAAAAAOo/HpKH9WuZOJk/s1600/preferences.png" height="191" width="320" /></a></div>
</i> <div class="separator" style="clear: both; text-align: center;">
<br /></div>
</li>
<li>Create a new folder <i>model</i> in the root of <i>org.xtext.example.mydsl</i> and file <i>Greetings.xcore</i> inside that folder. Our Ecore model consists of an <i>EPackage</i> <i>org.xtext.example.mydsl</i>, two <i>EClasses</i> <i>Model</i> and <i>Greetings</i>, a containment <i>EReference</i> <i>greetings</i> and an <i>EAttribute</i> <i>name</i>. In Xcore, this looks like :<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-eYtvm97peAw/UbiaRtNbd4I/AAAAAAAAAOM/hibmjoB_gyo/s1600/Xcore.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-eYtvm97peAw/UbiaRtNbd4I/AAAAAAAAAOM/hibmjoB_gyo/s1600/Xcore.png" height="222" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
</li>
<li>Open the grammar <i>MyDsl.xtext</i>. By default, the Ecore model <i>myDsl</i> is generated from the grammar rules. We want to replace this with the Ecore model specified in the Xcore file:<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-fYVt-OjBP3s/UbiajmJcSbI/AAAAAAAAAOU/8bnr_uW2Djk/s1600/xtextgrammar.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-fYVt-OjBP3s/UbiajmJcSbI/AAAAAAAAAOU/8bnr_uW2Djk/s1600/xtextgrammar.png" height="222" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
</li>
<li>We have to load the Xcore model in the workflow <i>GenerateMyDsl.mwe2</i> of the language generator. Add an appropriate <i>loadedResource</i> entry to the language section: <br />
<pre>module org.xtext.example.mydsl.GenerateMyDsl
...
Workflow {
...
component = Generator {
...
language = auto-inject {
loadedResource =</pre>
<pre>"platform:/resource/${projectName}/model/Greetings.xcore"
uri = ...
</pre>
</li>
<li>You have to add a dependency to <i>org.eclipse.emf.xcore</i> in the <i>MANIFEST.MF</i> of the project.</li>
<li>Now generate the language<i> infrastructure Run As > MWE2 Workflow. </i>There should not be any error.</li>
<li>Make sure that all folders will be correctly deployed. Your <i>build.properties</i> file should look like this :<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-wk8Q5ibfSxk/Ubia6JGrz5I/AAAAAAAAAOc/1DiqhLvv340/s1600/buildproperties.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-wk8Q5ibfSxk/Ubia6JGrz5I/AAAAAAAAAOc/1DiqhLvv340/s1600/buildproperties.png" height="222" width="320" /></a></div>
<screenshot></screenshot></li>
<li>Launch a new Eclipse workbench <i>Run > Run Configurations > Eclipse Application > Launch Runtime Eclipse</i> and enjoy your language in action<screenshot>.</screenshot></li>
</ol>
For the geeky fun of it: As Xcore is itself implemented in Xtext with an imported Ecore model, this lays the foundation to replace <i>Xcore.ecore</i> with <i>Xcore.xcore</i> and thereby bootstraping it. <br />
Sorry, I couldn't resist ;-)Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com15tag:blogger.com,1999:blog-1495223311988358528.post-23903399049015385832013-05-20T22:58:00.000+02:002013-05-20T23:03:41.945+02:00Another Xtend and JavaFX StoryFor my spare time <a href="http://www.oracle.com/technetwork/java/javafx/overview/index.html">JavaFX</a> project, I was looking for a way to export a scene to <a href="http://www.w3.org/Graphics/SVG/">SVG</a>. Googling a bit I stumbled over a <a href="http://harmoniccode.blogspot.de/2012/11/shapes-shapes-shapes.html">blog entry by Gerrit Grunwald</a> who implemented an <a href="https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/util/ShapeConverter.java">JavaFX shape to SVG path converter class</a> for the <a href="https://github.com/JFXtras">JFXtras</a> project. It looked good so I decided to give it a try.
<br />
<h3>
</h3>
<h3>
Java to Xtend</h3>
The class is of course written in Java. Even though there is no technical reason - Java and <a href="http://www.xtend-lang.org/">Xtend</a> classes can coexist in the same project without any problems - I wanted to convert it to <a href="http://www.xtend-lang.org/">Xtend</a> as well. I am a lazy guy. Luckily <a href="https://groups.google.com/forum/?fromgroups#!topic/xtend-lang/6BRrZRVkq6s">Krzysztof Rzymkowski had recently posted</a> on the <a href="https://groups.google.com/forum/?fromgroups#!forum/xtend-lang">Xtend group</a> that he had started to implement a <a href="https://github.com/rzymek/java2xtend">Java to Xtend converter</a>. It even has a <a href="http://www.j2x.cloudbees.net/">web interface</a>, and except for one slight issue with a <code>for</code>-loop it worked like a charm. Great work, Krzysztof!<br />
<br />
Of course the resulting code is pretty Java-like, so I wanted to improve on it using more of the cool Xtend features. I found quite a few spots to do so, reducing the amount of code significantly and enhancing readability a lot. The remainder of this post is about this ongoing love of JavaFX and Xtend. The complete source code will likely be made open-source soon.<br />
<h3>
</h3>
<h3>
Dispatch Methods</h3>
The class starts with a method that only contains an <code class="prettyprint lang-java">instanceof</code>-cascade to delegate to the conversion method for the specific subclass of <code>Shape</code> the parameter has:<br />
<pre class="prettyprint lang-java">public static String shapeToSvgString(final Shape SHAPE) {
final StringBuilder fxPath = new StringBuilder();
if (Line.class.equals(SHAPE.getClass())) {
fxPath.append(convertLine((Line) SHAPE));
} else if (Arc.class.equals(SHAPE.getClass())) {
fxPath.append(convertArc((Arc) SHAPE));
} else if (QuadCurve.class.equals(SHAPE.getClass())) {
fxPath.append(convertQuadCurve((QuadCurve) SHAPE));
} ... </pre>
In Xtend I can use <a href="http://www.eclipse.org/xtend/documentation.html#polymorphicDispatch">dispatch methods</a> to realize this: They must have the same method and number of parameters, but different parameter types. The Xtend compiler then generates the dispatcher method with the <code class="prettyprint lang-java">instanceof</code>-cascade automatically. So renaming the delegate methods and marking them as <code class="prettyprint lang-xtend">dispatch</code> made the dispatcher method obsolete. <br />
<pre class="prettyprint lang-xtend">def dispatch String toSvgString(Line line) ...
def dispatch String toSvgString(Arc arc) ...
def dispatch String toSvgString(QuadCurve quadCurve) ...
</pre>
Tip: If you want to delegate from one dispatch case to another, the
original methods are available with an underscore preceeding their name.<br />
<br />
<h3>
Templates</h3>
An SVG path is kind of a cryptic string. In the Java code it is assembled using a <code>StringBuilder</code>, e.g.<br />
<pre class="prettyprint lang-java">final StringBuilder fxPath = new StringBuilder();
fxPath.append("M ").append(CENTER_X).append(" ")
.append(CENTER_Y - RADIUS).append(" ");
fxPath.append("C ")
.append(CENTER_X + CONTROL_DISTANCE)
.append(" ").append(CENTER_Y - RADIUS).append(" ")
.append(CENTER_X + RADIUS).append(" ")
.append(CENTER_Y - CONTROL_DISTANCE)
.append(" ")
.append(CENTER_X + RADIUS).append(" ")
.append(CENTER_Y).append(" ");
...
</pre>
That's the best you can do with Java. In Xtend we have <a href="http://www.eclipse.org/xtend/documentation.html#templates">template expressions</a> - multiline strings which can be interrupted with values from expressions. Even <code class="prettyprint lang-xtend">IF</code>-conditions and <code class="prettyprint lang-xtend">FOR</code>-loops are supported. With carefully chosen regular expressions for find/replace and some manual fine-tuning the above becomes nicely readable<br />
<pre class="prettyprint lang-xtend">'''M «centerX» «centerY - radius»
C «centerX + controlDistance» «centerY - radius»
«centerX + radius» «centerY - controlDistance»
«centerX + radius» «centerY»
...
</pre>
<h3>
Switch Expression</h3>
I found another finer-grained <code class="prettyprint lang-java">instanceof</code>-cascade in the <code>convertPath</code> method:<br />
<pre class="prettyprint lang-java">final StringBuilder fxPath = new StringBuilder();
for (PathElement element : PATH.getElements()) {
if (MoveTo.class.equals(element.getClass())) {
fxPath.append("M ")
.append(((MoveTo) element).getX()).append(" ")
.append(((MoveTo) element).getY()).append(" ");
} else if (LineTo.class.equals(element.getClass())) {
fxPath.append("L ")
.append(((LineTo) element).getX()).append(" ")
.append(((LineTo) element).getY()).append(" ");
} else if (CubicCurveTo.class.equals(element.getClass())) {
fxPath.append("C ")
...
</pre>
As the bodies of the <code class="prettyprint lang-java">if</code>-statements are so simple, I decided to use Xtend's <a href="http://www.eclipse.org/xtend/documentation.html#switchExpression">switch</a> instead. It allows to use type guards for the cases and automatically cast the switch variable to that type inside the case's body:
<br />
<pre class="prettyprint lang-xtend">val it = new StringBuilder
for (element : path.elements) {
switch element {
MoveTo: append('''M «element.x» «element.y» ''')
LineTo: append('''L «element.x» «element.y» ''')
CubicCurveTo: append('''C «element.controlX1»...
</pre>
I could further use the operator <code class="prettyprint lang-xtend">=></code> instead of the Builder class and the operator <code class="prettyprint lang-xtend"><=></code> replacing <code class="prettyprint lang-java">Double.compare</code>.<br />
<br />
<h3>
Extension Import (Client Side)</h3>
From a client side, the <code>shapeToSvgString</code> method is a utility method for <code>Shapes</code>. In Xtend, you can import such methods using a <a href="http://www.eclipse.org/xtend/documentation.html#extensionImports">static extension import</a>. That makes them callable in extension syntax, as if the method was defined in the class of the first parameter. To further improve readability, I renamed the methods to <code>toSvgString</code> such that I can now write<br />
<pre class="prettyprint lang-xtend">import static extension ...ShapeConverter.*
...
new Rectangle.toSvgString</pre>
Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com1tag:blogger.com,1999:blog-1495223311988358528.post-74448952259971746582013-04-03T15:25:00.001+02:002013-04-03T17:25:09.810+02:00'X' Is For AbstractionWe at itemis have created a bunch of projects with an ‘X‘ during the last years: Xtext, Xtend and Xbase. In this blog post I am trying to elaborate the different use cases for each of them.<br />
<span style="font-size: small;"><span style="font-size: small;"> </span> </span><br />
<h3>
<span style="font-size: large;">It all starts with Java...</span></h3>
...which is a nice language understood by many programmers worldwide. A giant ecosystem and a vivid community as well as great IDEs are keys to its success. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<a href="http://1.bp.blogspot.com/-EQtL9jlbxlg/UVwqKPWwGzI/AAAAAAAAAM4/xvd4g9kTp1M/s1600/boxed_man.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://1.bp.blogspot.com/-EQtL9jlbxlg/UVwqKPWwGzI/AAAAAAAAAM4/xvd4g9kTp1M/s1600/boxed_man.jpg" /></a>But Java has a couple of crucial problems: Its syntax is inflexible and very verbose, making fluent APIs the closest you can get to domain-specific languages. Design patterns and structural conventions as JavaBeans have to be manually implemented over and over again with lot of error-prone boiler plate code. Frameworks require a big deal of XML pointing to Java classes, often ignored by the static analysis at compile time. IDEs can help us here, but they are usually limited to scaffolding or a single way of using a framework. The diagnosis is: Java is lacking the right means of abstraction.<br />
<br />
All technologies presented in the following enable you to define your own set of abstractions on top of Java. The solutions differ in syntactic flexibility, turnaround times, required user skills and multi-platform coverage.<br />
<br />
<h3>
<span style="font-size: large;">External DSLs (Xtext) </span></h3>
<a href="http://xtext.org/">Xtext</a> is a framework for external, textual, domain-specific languages. Xtext makes it easy to build an entire IDE for a completely new language, including your own code generators or interpreters to execute it. The Xtext homepage lists a lot of <a href="http://www.eclipse.org/Xtext/community.html">example projects</a>.<br />
<br />
When should you use Xtext? First of all, when you need a maximum of syntactical freedom. As Xtext DSLs are external they are defined by their own <a href="http://www.eclipse.org/Xtext/documentation.html#grammarLanguage">grammar,</a> thus not constrained by the syntax of a host language.<br />
<br />
Second, use plain Xtext if your language has no correspondence to Java or if you want to avoid dependencies on JDT at all cost. Languages that target different platforms at the same time are most likely based on a plain Xtext-based language, too. The technical skills needed to work with a Xtext-based language IDE is relatively low. I personally do not believe in "programming business men". But Xtext has been successfully used for non-technical, purely domain-oriented languages. <br />
As the generated IDE is already very powerful by default and can be customized easily, some people even use Xtext to build the IDE front end for an existing language with an existing compiler.<br />
<br />
If you change the grammar, you have to regenerate the language infrastructure and redeploy the language's plug-ins to the user's machines. The latter can be a challenge in some scenarios.<br />
<br />
Mostly structural languages with simple expressions only will go smoothly. A few complicated expressions can pragmatically be integrated using the common integration techniques (generation gap pattern, black-box literals, protected regions, etc.). But all of these raise the complexity, break the abstraction, and are hard to maintain. If expressions are the rule and not the exception, consider<br />
<br />
<h3>
<span style="font-size: large;">Java DSLs (Xtext with Xbase)</span></h3>
Under the codename <a href="http://www.eclipse.org/Xtext/documentation.html#Xbase">Xbase</a>, we have developed a <a href="http://www.eclipse.org/Xtext/documentation.html#xbaseExpressions">rich expression language</a>, that you can embed in your Xtext-based DSLs. It reuses Java's typesystem, can express everything that Java expressions can do and adds even more features like type inference, operator overloading, lambda expressions etc. <br />
<br />
The default way of using Xbase is to <a href="http://www.eclipse.org/Xtext/documentation.html#xbaseInferredType">define a transformation</a> from your language to a structural Java model and embed the expressions in the appropriate Java contexts. A generic code generator builds Java code from this model, so no need to build your own. As we generate plain Java code, these Xbase languages integrate seamlessly with hand-written Java code and work for platforms that are sensitive to bytecode manipulation, like Android.<br />
<br />
Java DSLs are the way to go for languages that compile to Java and need rich behavior or expressions. These are probably much more than you'd probably expect. Have a look at our <a href="http://www.eclipse.org/Xtext/7languages.html">seven languages</a> for some examples. There is also an interpreter for Xbase allowing to skip the compilation step on the language user's side. <br />
<br />
We have only implemented an execution environment for Java, so it's up to you if you need another. Restricting the available expressions is easy and could help here significantly. You can also add new expressions to the expression language, but the syntactic space is already quite crowded.<br />
<br />
Non-technical users are usually ruled out here. You don't want to teach them managers about closures, do you? You still have complete syntactical freedom for your language. But you still have to regenerate the plug-ins and redeploy them on grammar changes as before.<br />
<br />
<h3>
<span style="font-size: large;">Internal DSLs (Xtend)</span></h3>
Just because Java doesn't offer the means of abstraction you need doesn't mean you have to define a new language yourself. We have created <a href="http://xtend-lang.org/">Xtend</a>, a general purpose language (GPL) based on Java but adding a lot of fancy stuff like type inference, operator overloading, lambda expressions, etc. You guessed it: Xtend is based on the Xbase expression library, but also defines the structural parts (types, fields, methods, annotations etc.), adds extension methods, multi-dispatch methods, template expressions, and offers an even better IDE.<br />
<br />
This is already a mighty toolset and can bring you pretty close to internal DSLs in other languages. Look at our <a href="http://blog.efftinge.de/2012/04/xtend-examples-used-at-eclipsecon-2012.html">examples from EclipseCon 2012</a> (especially the SWT, Distances and HTML Builder examples).<br />
<br />
One additional leap ahead are <a href="http://www.eclipse.org/xtend/documentation.html#activeAnnotations">Active Annotations</a> (new in 2.4, beta). These annotations allow you to participate in the Xtend to Java compilation. They are particularly useful for implementing patterns, but can be surprisingly powerful in other scenarios, too. Have a look at a few cool examples: <a href="http://www.eclipse.org/community/eclipse_newsletter/2013/march/article1.php">Observer pattern</a>, <a href="http://zarnekow.blogspot.de/2013/03/pimp-my-visitors.html">Vistors</a>, <a href="http://blog.efftinge.de/2013/03/working-with-json-data-from-java.html">JSON classes</a>, <a href="http://blog.efftinge.de/2013/03/fun-with-active-annotations-my-little.html">a simple REST API</a>, <a href="http://mnmlst-dvlpr.blogspot.de/2013/03/fun-with-active-annotations-micro.html">micro benchmarking</a>...<br />
<br />
Having everything you need in the language itself gives you short turnarounds as no more regeneration and redeployment is needed. The toolstack stays nicely low. But you're restricted to generating Java and use the syntactical elements of the Xtend language. I would never recommend Xtend to non-programmers, but to everyone fighting with Java.<br />
<br />Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com0tag:blogger.com,1999:blog-1495223311988358528.post-74558914770985102712013-01-06T23:41:00.002+01:002013-01-07T08:54:52.251+01:00Accumulating JavaFX Transforms With XtendI was a bit vague in my last post on <a href="http://docs.oracle.com/javafx/">JavaFX's</a> transformation API, so I decided to write a separate post on this topic.<br />
<br />
In <a href="http://docs.oracle.com/javafx/">JavaFX</a>, each node in the scenegraph can be translated, rotated, scaled or sheared relative to its parent. In mathematical terms, each node maintains a transformation describing its own local coordinate system. This transformation can be defined with a matrix represented as a <a href="http://docs.oracle.com/javafx/2/api/javafx/scene/transform/Transform.html">Transform</a> object in <a href="http://docs.oracle.com/javafx/">JavaFX</a>.<br />
<br />
The <a href="http://docs.oracle.com/javafx/">JavaFX</a> API offers some convenience methods to manipulate this transformation. E.g., you can scale a node in x-direction and translate it by 42 units in y-direction by calling
<br />
<pre class="prettyprint lang-java"> node.setScaleX(2);
node.setTranslateY(42)
</pre>
Unfortunately, these convenience methods do not accumulate as one would expect. Instead of multiplying the matrices for subsequent transformations, the only set specific entries in the matrix. As a result, translating an object before rotating yields the same result as applying these transformations in reverse order. This is mathematically wrong and does also not match the users expectations.<br />
<br />
In my diagram editor application, I want to scroll (translate), zoom (scale) and rotate the canvas using mouse gestures. From the user's point of view it's imperative that each transformation builds on the previous state. The convenience methods don't match this usecase.<br />
<br />
The correct solution to this problem is to multiply the transformation matrices. Unfortunately, JavaFX lacks any kind of calculation API for <a href="http://docs.oracle.com/javafx/2/api/javafx/scene/transform/Transform.html">Transform</a> and its subclasses.<br />
<br />
Once again, this is where <a href="http://www.xtend-lang.org/">Xtend</a> comes to our aid. An <a href="http://www.eclipse.org/xtend/documentation.html#extensionMethods">extension method</a> in Xtend can be used to define functions for existing (closed) types, which syntactically look like being methods of the type on the caller's side. <a href="http://docs.oracle.com/javafx/2/api/javafx/scene/transform/Affine.html">Affine</a> is a subtype of <a href="http://docs.oracle.com/javafx/2/api/javafx/scene/transform/Transform.html">Transform</a> that allows its matrix entries to change. So I wrote extension methods to translate, rotate, scale and shear an existing <a href="http://docs.oracle.com/javafx/2/api/javafx/scene/transform/Affine.html">Affine</a> by multiplying the respective transformation matrix, e.g.
<br />
<pre class="prettyprint lang-xtend">class TransformExtensions {
def static scale(Affine it, double x, double y) {
// left multiply a scale matrix to it
// highly optimized as there are many zeros in the scale matrix
mxx = x * mxx
xy = x * mxy
mxz = x * mxz
tx = x * tx // take existing translation into account
myx = y * myx
myy = y * myy
myz = y * myz
ty = y * ty </pre>
<pre class="prettyprint lang-xtend"> }
}
</pre>
Importing these as extensions
<br />
<pre class="prettyprint lang-xtend">import static extension ...TransformExtensions.*
</pre>
now allows to accumulate the transformations, e.g.
<br />
<pre class="prettyprint lang-xtend">val diagram = scene.root
val diagramTransform = new Affine
diagram.transforms.clear
diagram.transforms += diagramTransform
val EventHandler<scrollevent> scrollHandler = [
diagramTransform.translate(deltaX, deltaY)</scrollevent></pre>
<div style="text-align: left;">
<pre class="prettyprint lang-xtend"><scrollevent>]
scene.onScrollStarted = scrollHandler
scene.onScroll = scrollHandler
scene.onScrollFinished = scrollHandler
val EventHandler<rotateevent> rotateHandler = [
diagramTransform.rotate(angle, sceneX, sceneY)
]
scene.onRotationStarted = rotateHandler
scene.onRotate = rotateHandler
scene.onRotationFinished = rotateHandler
...
</rotateevent></scrollevent></pre>
</div>
<div class="separator" style="clear: both; text-align: left;">
The resulting behavior looks like the following screenshot. Note that the mouse position is the pivot for rotations and zoom. </div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dz88r8w1Q7NqdrZ2myzdosMQmKZS346wYdM8m3x_LARjAs9nis3yx-Y1j24y4ww9zbFK9m6h5ZY-FNR04yQXw' class='b-hbp-video b-uploaded' frameborder='0'></iframe> </div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The same mechanism can be used to properly place labels along connections:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-SGyP4YIbTpM/UOn8jk94nOI/AAAAAAAAALw/ErGmJp87jW4/s1600/Bildschirmfoto+2013-01-06+um+23.36.36.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="277" src="http://1.bp.blogspot.com/-SGyP4YIbTpM/UOn8jk94nOI/AAAAAAAAALw/ErGmJp87jW4/s320/Bildschirmfoto+2013-01-06+um+23.36.36.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
PS: I went for mutable transformation matrices, but the same mechnism will hold for immutable matrices. The extension methods then return a new Affine instead of modifying the receiver. <br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com2tag:blogger.com,1999:blog-1495223311988358528.post-6481119429698131592013-01-01T23:51:00.001+01:002013-01-02T14:09:31.535+01:00JavaFX Loves XtendInspired by a talk by <a href="http://harmoniccode.blogspot.de/">Gerrit Grunwald</a> and the work of <a href="http://tomsondev.bestsolution.at/">Tom Schindl</a> I started to dig a bit deeper into <a href="http://docs.oracle.com/javafx/index.html">JavaFX</a>. Being one of the committers of the <a href="http://www.xtend-lang.org/">Xtend language</a>, it was a matter of honour to use Xtend in my experiments. The result: JavaFX and Xtend seem to be made for each other.<br />
<br />
If you know me a bit, you won't be surprised that I tried implementing a simple graph editor first. I will blog on that particular application in a separate post. Even though JavaFX is not primarily a graphical editing framework, it offers a lot of the required features, e.g.
<br />
<ul>
<li>State of the art rendering and CSS styling</li>
<li>A life scene-graph with affine transformations in all nodes</li>
<li>An easy way to do data-binding and event propagation</li>
<li>Easy to use APIs for effects and animations</li>
<li>Built-in support for tablets and touch-aware devices </li>
</ul>
The developers of JavaFX did a pretty good job in creating a clear Java API, but sometimes Java's rigid syntax was a bit in their way. This is where Xtend comes into play. The resulting code is astonishingly short and easy to read.
<br />
<h2>
Lambda Expressions For Event Listeners</h2>
Each JavaFX <a href="http://docs.oracle.com/javafx/2/api/javafx/scene/Node.html">Node</a> has a couple of convenience methods to react on on UI events, such as mouse clicks, key strokes or multi-touch gestures. A mouse click can for example be handled as
<br />
<pre class="prettyprint lang-java">Node node = new Rectangle();
node.setOnMouseClicked(new EventHandler<MouseEvent>() {
@Override
public void handle(MouseEvent event) {
System.out.println(event.getButton() + " button clicked");
}
});
</pre>
Xtend's lambda expressions (aka closures) are automatically <a href="http://www.eclipse.org/xtend/documentation.html#lambdas">coerced to interfaces</a> with a single method. Using the <a href="http://www.eclipse.org/xtend/documentation.html#featureCalls">implicit parameter it</a> and the <a href="http://www.eclipse.org/xtend/documentation.html#featureCalls">shortcut syntax for property</a> access the above becomes
<br />
<pre class="prettyprint lang-xtend">val node = new Rectangle
node.onMouseClicked = [
println(button + " button clicked")
]
</pre>
<h2>
The With Operator => Obsoletes Builders</h2>
JavaFX has a couple of objects that need quite a few parameters to be customized. Instead of implementing a new constructor with a huge number of parameters for each use case, the JavaFX developers generated fluent builder APIs, e.g.
<br />
<pre class="prettyprint lang-java">Rectangle rectangle = RectangleBuilder.create()
.width(80)
.height(30)
.fill(Color.BLUE)
.stroke(Color.RED)
.strokeWidth(1.2)
.arcWidth(12)
.arcHeight(12)
.build();
</pre>
In Xtend, we have the with operator '=>' that binds the preceding argument to the parameter of a lambda expression and executes the latter. So we can achieve the same as above with an even shorter syntax and without the need for an accompanying builder class:
<br />
<pre class="prettyprint lang-xtend">val rectangle = new Rectangle => [
width = 80
height = 30
fill = Color::BLUE
stroke = Color::RED
strokeWidth = 1.2
arcWidth = 12
arcHeight = 12
]
</pre>
The with operator also facilitates the creation of object trees, e.g. subtrees of JavaFX's scenegraph.
<br />
<h2>
Extension Methods For High-Level Property Binding</h2>
In JavaFX, properties can be derived from other properties by means of another fluent API for the calculation. The result is the best you can achieve with pure Java, e.g. given two DoubleProperties a and b, you can bind a mean value property which will be automatically updated when a or be change:
<br />
<pre class="prettyprint lang-java">mean.bind(a.add(b).divide(2));
</pre>
If these calculations get more difficult and you do a lot of them it will get quite unreadable. This is the right moment to think about <a href="http://www.eclipse.org/xtend/documentation.html#operators">overloaded operator extensions</a> for DoubleProperties. With these, the last line can become as simple as
<br />
<pre class="prettyprint lang-xtend">mean << a + b / 2
</pre>
Extension methods and operator overloading can also be used to add the missing APIs for geometry calculation, e.g. to apply a <a href="http://docs.oracle.com/javafx/2/api/javafx/scene/transform/Transform.html">Transform</a> to a <a href="http://docs.oracle.com/javafx/2/api/javafx/geometry/Point3D.html">Point3D</a> or to accumulate Transforms.
Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com0tag:blogger.com,1999:blog-1495223311988358528.post-16038168772302628082012-11-19T11:06:00.001+01:002012-11-19T11:18:04.647+01:00Xtext tip: How do I get the Guice Injector of my language?This post is about one of the most frequent mistakes people are making when starting to use <a href="http://www.xtext.org/">Xtext</a> beyond the basic functionality. I stumble across this in our <a href="http://www.eclipse.org/forums/index.php?t=thread&frm_id=27">newsgroup</a> about three times a week.<br />
<br />
The problem usually starts by the necessity to load a file in your language in the UI, lets say in a custom action. You already know that in Xtext everything is wired up with dependency injection (DI), and that you need a DI configured <span style="font-family: "Trebuchet MS",sans-serif;">XtextResourceSet</span> to load a model. So you start looking for an <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span> to create your <span style="font-family: "Trebuchet MS",sans-serif;">XtextResourceSet</span> and find that one is returned by the generated <span style="font-family: "Trebuchet MS",sans-serif;"><dsl>[DSL]StandaloneSetup.createInjectorAndDoEMFRegistration()</dsl></span>. This seems to work fine first, but in the followoing you'll get a lot of strange errors. Things that worked before are suddenly broken.<br />
<br />
A variant of the error – more popular among former oAW users – is to run a generator <a href="http://www.eclipse.org/modeling/emft/?project=mwe">MWE2</a> workflow containing such a <span style="font-family: "Trebuchet MS",sans-serif;"><dsl>[DSL]StandaloneSetup</dsl></span> from the UI.<br />
<br />
<h3>
Never ever use the <span style="font-family: "Trebuchet MS",sans-serif;"><dsl>[DSL]StandaloneSetup </dsl></span>for your language within Eclipse!</h3>
<br />
Why not? Xtext relies on EMF and EMF uses on a bunch of global registries to work. E.g. the <span style="font-family: "Trebuchet MS",sans-serif;">EPackage.Registry</span> for the implementation classes for <span style="font-family: "Trebuchet MS",sans-serif;">EPackages</span> or the <span style="font-family: "Trebuchet MS",sans-serif;">Resource.Factory.Registry</span> for parsers for model files. These are global singletons, and they are usually populated by means of Eclipse extension points, e.g. <span style="font-family: "Trebuchet MS",sans-serif;">org.eclipse.emf.ecore.generated_package</span> or <span style="font-family: "Trebuchet MS",sans-serif;">org.eclipse.emf.ecore.extension_parser</span>. If you run a standalone Java application – the term <b>standalone</b> means <b>without equinox</b> here – there is no concept of extension points. That means you have to register the DSL to EMF's registries yourself. This is what the <span style="font-family: "Trebuchet MS",sans-serif;"><dsl>[DSL]StandaloneSetup <span style="font-family: inherit;">is meant for. If you're using it within Eclipse, you'll overwrite the contributions from the extension points with new instances from the standalone setup. This will crash your application. </span></dsl></span><br />
<br />
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-family: inherit;">It gets even worse: Xtext has a couple of singletons, too, but they are not global but scoped within the (singleton) <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span> of your language. If you just create a new <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span>, you'll end up with two instances for all of these singletons. </span></span>This will likely hit you badly.<br />
<br />
Finally, some Xtext components have different implementations for Eclipse and for standalone mode. E.g., Xtext's Java reflection layer (aka JVM model) uses JDT's Java model in Eclipse and Java Reflection in standalone mode. The <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span> from the standalone setup will register different implementation classes, thus also breaking functionality.<br />
<br />
<h3>
So how do I use dependency injection in Eclipse properly then?</h3>
<br />
The Equinox aware <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span> you're looking for can be obtained from the <span style="font-family: "Trebuchet MS",sans-serif;"><dsl>Activator</dsl></span> of your language (in the UI plug-in). But it would be bad advise to just tell you to go there. You should rather use DI properly. If you think about where to get the Injector you're most often already on the wrong track.<br />
<br />
A central aspect of DI is not to care about object creation at all, but just declare dependencies (via <span style="font-family: "Trebuchet MS",sans-serif;">@Inject</span> in Guice). Every dependency that is injected will also be created by the <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span> so its own dependencies will be created on-demand and injected recursively. As a result, in a well-designed application using DI, there is only one entry class that is explicitly created or populated by the <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span> and the rest is automatically DI aware as it is injected somewhere.<br />
<br />
IDE components in Eclipse are usually registered by contributing to an extension point with an <b>executable extension</b>, usually an attribute with name <span style="font-family: "Trebuchet MS",sans-serif;">class</span>, for example<br />
<br />
<span style="font-family: "Trebuchet MS",sans-serif;"> <extension point="org.eclipse.ui.editorActions"> </span><br />
<span style="font-family: "Trebuchet MS",sans-serif;"> <editorContribution targetID="..." id="..."> </span><br />
<span style="font-family: "Trebuchet MS",sans-serif;"> <action class="[some class extending IActionDelegate]" </span><br />
<span style="font-family: "Trebuchet MS",sans-serif;"> ... </span><br />
<br />
<span style="font-family: "Trebuchet MS",sans-serif;"></span>
<span style="font-family: inherit;">Xtext generates a so called <b>executable extension factory</b> for you that will instantiate the given class using the <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span>, so use</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: "Trebuchet MS",sans-serif;"> ... class="<dsl>[DSL]ExecutableExtensionFactory:<some class="class" name="name">[some class name]"</some></dsl></span><br />
<br />
<span style="font-family: inherit;">and the class will be generated with all its dependencies injected. This is also covered <a href="http://www.eclipse.org/Xtext/documentation.html#equinoxSetup">in the documentation</a>.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">If there is no such extension point, and your class is not yet instantiated using DI, you might have to access the <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span> via the <span style="font-family: "Trebuchet MS",sans-serif;">Activator</span> and use it to inject all dependencies, i.e.</span><br />
<br />
<span style="font-family: "Trebuchet MS",sans-serif;"><dsl> [DSL]Activator.getInstance().getInjector("<language name="name">").injectMembers(this);</language></dsl></span><br />
<br />
<span style="font-family: inherit;">Note that you should only have to do this for the entry class, from which all other components are injected. If you have to use the <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span>, make sure it is only once.</span><br />
<br />
<h3>
<span style="font-family: inherit;">How do I use DI in tests?</span></h3>
<br />
<span style="font-family: inherit;">There is a whole section on <a href="http://www.eclipse.org/Xtext/documentation.html#TutorialUnitTests">using DI in tests</a> in the documentation. I am not going to repeat this here. The base configuration requires using JUnit4 and is automatically generated for your language has been created with a recent version of Xtext. If not, make sure to add</span><br />
<br />
<span style="font-family: inherit;"><span style="font-family: "Trebuchet MS",sans-serif;"> pathTestProject = "[DSL]<dsl>.tests"</dsl></span> </span><br />
<br />
<span style="font-family: inherit;">in the section on paths in your MWE2 workflow and</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"><span style="font-family: "Trebuchet MS",sans-serif;"> // generates junit test support classes into Generator#pathTestProject<br /> fragment = junit.Junit4Fragment {}</span> </span><br />
<br />
<span style="font-family: inherit;">to the fragments and regenerate. This will create the preconfigured test plug-in. Use the <span style="font-family: "Trebuchet MS",sans-serif;"><dsl>InjectorProvider</dsl></span> for standalone tests and the <span style="font-family: "Trebuchet MS",sans-serif;"><dsl>UiInjectorProvider</dsl></span> for plug-in tests. Once again, your code should not show any references to an <span style="font-family: "Trebuchet MS",sans-serif;">Injector</span>.</span><br />
<br />
<h3>
<span style="font-family: inherit;">And the Injector of another language?</span></h3>
<br />
<span style="font-family: inherit;">Sometimes, you want to switch to a service implementation from another language, e.g. when your DSL allows cross references to another. Usually, you are in the DI context of one language and have an <span style="font-family: "Trebuchet MS",sans-serif;">URI</span> to a resource or element of the other language at hand. In this case use the <span style="font-family: "Trebuchet MS",sans-serif;">IResourceServiceProvider.Registry</span>:</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: "Trebuchet MS",sans-serif;"> @Inject IResourceServiceProvider.Registry reg;</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">and use that to get the component, e.g. to get the default <span style="font-family: "Trebuchet MS",sans-serif;">ILabelProvider</span></span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: "Trebuchet MS",sans-serif;"> ILabelProvider otherLangLabelProvider = </span><br />
<span style="font-family: "Trebuchet MS",sans-serif;"> reg.getResourceServiceProvider(otherLangURI)</span><br />
<span style="font-family: "Trebuchet MS",sans-serif;"> .get(ILabelProvider.class);</span><br />
<span style="font-family: inherit;"><br /></span>
Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com7tag:blogger.com,1999:blog-1495223311988358528.post-50868062259036442082012-07-12T10:17:00.001+02:002012-07-17T10:34:26.108+02:00Seven Languages By Seven GeeksOne of the most powerful new features of <a href="http://www.xtext.org/">Xtext</a> is the capability to <a href="http://www.eclipse.org/Xtext/documentation.html#Xbase">build languages for the JVM</a>. In my opinion, these languages are a real breakthrough in domain-specific language design:<br />
<ul>
<li>These DSLs directly interoperate with Java. They compile to Java code and allow to refer to Java artifacts.</li>
<li>They not only cover structural aspects but also behavior. DSLs become really powerful with a rich expression language offering today what Java has been missing for years, like type inference, lambda expressions, extension methods etc.</li>
<li>Complicated integration patterns like Generation Gap or Protected Regions become obsolete. Everything can be expressed on the same level of abstraction</li>
<li>They offer top-notch Eclipse-based tooling and integrate into the Java IDE. Switch between the DSL and the Java code during debugging, refactor across multiple languages, navigate to source etc.</li>
</ul>
Yet we have the impression that the concept and the benefits of JVM DSLs have not been well understood and adopted. This is why we decided it was time for another example and documentation offensive. The result is the <a href="http://www.eclipse.org/Xtext/7languages.html">7 Languages</a> project: Seven example JVM languages highlighting the benefits of this approach in various use cases of Java development:<br />
<ol>
<li>A scripting language. Write code without any boilerplate.</li>
<li>A build language similar to Gradle but statically typed.</li>
<li>JavaBeans facades for mongoDB objects.</li>
<li>A DSL to define Guice modules.</li>
<li>A language to route HTTP requests with conditions, variables and dependency injection.</li>
<li>A template language</li>
<li>A LOGO-like turtle drawing environment.</li>
</ol>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-v_6IhSpVZ_w/T_6Herq-6aI/AAAAAAAAAKM/2PLxIReiNp8/s1600/Pythagoras.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="268" src="http://4.bp.blogspot.com/-v_6IhSpVZ_w/T_6Herq-6aI/AAAAAAAAAKM/2PLxIReiNp8/s320/Pythagoras.png" width="320" /></a></div>
Clone or fork the code from <a href="https://github.com/xtext-dev/seven-languages-xtext.git">github</a> and enjoy the <a href="http://www.eclipse.org/Xtext/7languagesDoc.html">documentation</a> on theXtext website.<br />
<br />Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com1tag:blogger.com,1999:blog-1495223311988358528.post-44230672785090230552012-03-28T02:42:00.000+02:002012-03-28T02:42:15.709+02:00EclipseCon 2012 - I have had my shareI am at EclipseCon 2012, this year at Reston (VA). I have just finished my parts and can now relax and take it easy for the remainder of the conference.<br />
<br />
Yesterday I gave a a tutorial on "DSLs for Xtext Developers" together with Sebastian. Around 50 participants learnded how to wirte their own DSLs that run on the JVM and integrate tightly with Java. Looking at the feedback so far, this was a real success, even thought it was a whole lot of stuff. Have a look at the slides:<br />
<br />
<br />
<div id="__ss_12183944" style="width: 425px;">
<strong style="display: block; margin: 12px 0 4px;"><a href="http://www.slideshare.net/schwurbel/dsls-for-java-developers" title="DSLs for Java Developers">DSLs for Java Developers</a></strong><object height="355" id="__sse12183944" width="425"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=eclipsecon2012-tutorial-120327194005-phpapp01&stripped_title=dsls-for-java-developers&userName=schwurbel" />
<param name="allowFullScreen" value="true"/>
<param name="allowScriptAccess" value="always"/>
<param name="wmode" value="transparent"/>
<embed name="__sse12183944" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=eclipsecon2012-tutorial-120327194005-phpapp01&stripped_title=dsls-for-java-developers&userName=schwurbel" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" wmode="transparent" width="425" height="355"></embed></object><div style="padding: 5px 0 12px;">
View more <a href="http://www.slideshare.net/">presentations</a> from <a href="http://www.slideshare.net/schwurbel">Jan Koehnlein</a>.</div>
</div>
<br /><br />
<br />
Today I talked about "A Fresh Look at graphical Editing". In comparison to the talk at EclipseCon Europe, I changed the focus a bit and spent more time to make clear, why most graphical model editors really suck. This time I seem to have made my point, at least noone has asked me so far to convert the Generic Graph View framework into a model editor. The new features, like multitouch gestures and discovery diagrams went fine, too. Here are the slides<br />
<br />
<br />
<div id="__ss_12183802" style="width: 425px;">
<strong style="display: block; margin: 12px 0 4px;"><a href="http://www.slideshare.net/schwurbel/a-fresh-look-at-graphical-editing-12183802" title="A fresh look at graphical editing">A fresh look at graphical editing</a></strong><object height="355" id="__sse12183802" width="425"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=afreshlookatgraphicalediting-120327192705-phpapp02&stripped_title=a-fresh-look-at-graphical-editing-12183802&userName=schwurbel" />
<param name="allowFullScreen" value="true"/>
<param name="allowScriptAccess" value="always"/>
<param name="wmode" value="transparent"/>
<embed name="__sse12183802" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=afreshlookatgraphicalediting-120327192705-phpapp02&stripped_title=a-fresh-look-at-graphical-editing-12183802&userName=schwurbel" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" wmode="transparent" width="425" height="355"></embed></object><div style="padding: 5px 0 12px;">
View more <a href="http://www.slideshare.net/">presentations</a> from <a href="http://www.slideshare.net/schwurbel">Jan Koehnlein</a>.</div>
</div>
<br />Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com3tag:blogger.com,1999:blog-1495223311988358528.post-29774662779123428812012-01-18T19:30:00.005+01:002012-01-29T16:46:02.259+01:00Impressions on GEFFor the <a href="https://github.com/JanKoehnlein/Generic-Graph-View">Generic Graphical View</a> project I've been digging deep into the <a href="http://www.eclipse.org/gef/">Graphical Editing Framework</a> (GEF) lately. GEF is the base technology below almost any graphical framework in the Eclipse environment. I wanted to keep the tool stack as low as possible and have the maximum control on everything so I decided to use GEF directly. Here are my impressions.<br /><br />I really like GEF's base architecture: The separation between Draw2D and GEF, the concepts of <span style="font-family:arial;">Tools</span>, <span style="font-family:arial;">Requests</span>, <span style="font-family:arial;">EditParts</span> and <span style="font-family:arial;">EditPolicies</span>. It helps you to find the component to change in order to implement a new feature quickly. The pictures in the GEF online help really help<br />understanding this.<span style="font-weight: bold;"><br /></span><h4><br /></h4><h4>Pecularities<br /></h4> In some areas GEF appears to be kind of rusty. A whole bunch of relevant commercial products has been relying on it for years. Long term backward API compatibility has taken its toll. Some things definitely need a serious overhaul and often a better naming. I am very happy to hear that a 3.0 version is planned. Here is my wishlist for improvements:<br /><ul><li>Make coordinates <span style="font-family:arial;">double</span> by default. Integer coordinates often result in rendering glitches due to rounding errors and are not well suited for scaling. </li><li>Add alpha channel (transparency) support.</li><li>Revise scaling of fonts: Sometimes a label's bounds don't match its text's extend.<br /></li><li>Rename methods of the update mechanism. I am often confused about the semantics <span style="font-family:arial;">validate()</span>, <span style="font-family:arial;">invalidate()</span>, <span style="font-family:arial;">invalidateTree()</span> or <span style="font-family:arial;">revalidate()</span>.</li><li>Rectangular bounds are not well suited for round things like ellipses. Similar to that, clipping child figures only makes sense for <span style="font-family:arial;">Viewports</span> but nothing else. The need of an invisible container figure for side affixed children is really an ugly workaround.<br /></li><li>Diagram layout does not take connection labels into account.</li><li>Add support for curve connections.</li><li>The feedback figures - the surrogates when a figure is moved or resized - seem to come from a time where hardware graphics acceleration was pure luxury. If you have nested edit parts you might have to reimplement the nested figure construction twice for nicer feedback.<br /></li><li>Using a bit less inheritance and more composition would be fine.<br /></li></ul><h4><br /></h4><h4>Mutable Geometric Primitives</h4>As many other graphics frameworks, GEF code tries to create as little new objects as possible. Geometrical primitives such as points, dimensions and rectangles are therefore mutable and reused often. There are even things as a static <span style="font-family:arial;">Rectangle.SINGLETON</span> for temporary calculation. This pretty much reminds me of good old C++. I am not sure whether such optimization is still necessary. It results in pretty unreadable code:<br /><pre>Point p = figure.getLocation(); <br />// p is the location in local coordinates<br />p.getParent().transformToParent(p);<br />// now p is in parent coordinates<br />Point q = p.add(p).scale(2):<br />// this will also modify p<br /></pre>You see: As the semantics of the variable changes, it is no surprise you cannot find a more expressive name than <span style="font-family:arial;">p</span>. In addition, you have to be very careful if you are dealing with a reference or a copy. Modifying a <span style="font-family:arial;">Translatable</span> (once again bad name, as <span style="font-family:arial;">Dimension</span> also implements this interface) directly can also circumvent an event mechanism. This is really error prone. I'd strongly advise to introduce immutable primitives.<br /><h4><br /></h4><h4>Coordinate Transformations<br /></h4>The way transformation between local, global and parent coordinates are handled is somehow unsuggestive. I've used various 2D and 3D scenegraph-based frameworks but I never got as confused with coordinates as in GEF. For example, if you have a <span style="font-family:arial;">ScalableLayeredPane</span> showing some scaled content, its <span style="font-family:arial;">translateToAbsolute(Point)</span> method will not take the scaling into account while <span style="font-family:arial;">translateToParent(Point)</span> will.<br /><h4><br /></h4><h4>Some Hints<br /></h4> Starting with GEF from zero is hard. You will likely spend a serious amount of time debugging why your diagram doesn't show anything at all. Better copy some basic setup from one of the GEF examples. Here are my favorite pitfalls:<br /><ul><li>missing minimum size on figure - figure does not show up at all in some layouts</li><li>wrong coordinate system - figures don't appear where they should, somtimes in nirvana<br /></li><li>wrong layout manager, e.g. a plain <span style="font-family:arial;">XYLayout</span> on a <span style="font-family:arial;">FreeformFigure</span> - results in endless layout loop</li><li>reusing a geometry element instead of making a copy - completely unpredictable editor behavior<br /></li><li>the default <span style="font-family:arial;">ChangeBoundsRequest</span> does not take local coordinate systems into account</li></ul>For better diagram layout algorithms the <a href="http://trac.rtsys.informatik.uni-kiel.de/trac/kieler/wiki/WikiStart">KIELER project</a> offers a good choice.Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com11tag:blogger.com,1999:blog-1495223311988358528.post-75894943707233005612012-01-18T17:19:00.005+01:002012-01-20T07:28:04.139+01:00Multitouch Gestures in the Generic Graph ViewIn my <a href="http://koehnlein.blogspot.com/2012/01/discovery-diagrams-for-generic.html">previous post</a>, I've already described the discovery mechanisms of the <a href="https://github.com/JanKoehnlein/Generic-Graph-View">Generic Graphical View</a> project: Starting from one node you can step by step reveal other connected nodes in the same model. The model itself is fixed - it is still a view! - but the user can decide herself which subset of elements should appear in the diagram. That behavor allows to create diagram views focussed on a specific semantic aspect of the model.<br /><br />The challenge is to find a decent UI for nodes wich have several hidden connections. How should a user select any subset of these?<br /><br />Since the Helios release SWT supports four multitouch gestures: <span style="font-style: italic;">PAN</span>, <span style="font-style: italic;">ZOOM</span>, <span style="font-style: italic;">SWIPE</span> and <span style="font-style: italic;">ROTATE</span>. On my Mac's touchpad these gestures are actually easier to perform than a conventional drag operation because there is no extra mouse button. So I decided to give it a try and have a look how gestures could be used in the graph view. Here is a screencast showing the results:<br /><br /><iframe src="http://player.vimeo.com/video/35263430?title=0&byline=0&portrait=0" webkitallowfullscreen="" mozallowfullscreen="" allowfullscreen="" frameborder="0" height="270" width="480"></iframe><br /><br />SWT's multitouch API is fairly simple (<a href="http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet353.java?view=co">example snippet</a>). The first step was to add multitouch events to GEF, such that the can be handled in the same way as mouse or keyboard events. I had to extend a couple of GEF classes. If you're interested in the details, have a look at the classes in the package <a href="https://github.com/JanKoehnlein/Generic-Graph-View/tree/master/org.eclipse.xtext.graphview/src/org/eclipse/xtext/graphview/behavior/gestures"><span style="font-family:arial;">org.eclipse.xtext.graphview.behavior.gestures</span></a> and the <a href="https://github.com/JanKoehnlein/Generic-Graph-View/blob/master/org.eclipse.xtext.graphview/src/org/eclipse/xtext/graphview/editpart/GraphViewRootEditPart.java"><span style="font-family:arial;">GraphViewRootEditPart</span></a>.<br /><br />These changes allow to use a <span style="font-style: italic;">ZOOM</span> gesture on a <span style="font-family:arial;">ScalableFreeformRootEditPart</span>.<br />Note that the <span style="font-style: italic;">PAN</span> gesture is already supported by GEF because the <span style="font-family:arial;">FigureCanvas</span> uses hardware scrolling. Unfortunately, these event is always consumed, such that it will not make it through to other GEF elements.<br /><br />The <span style="font-style: italic;">ZOOM</span> gesture can also be used to drill down into elements. If the mapping defines an open reference to another diagram, you can drill down by selecting it and performing the <span style="font-style: italic;">ZOOM</span> in gesture. If you‘re inside a drill down diagram, you can <span style="font-style: italic;">ZOOM</span> out into the container diagram.<br /><br />Any <span style="font-family:arial;">Tool</span> can now handle multitouch gestures by implementing the <span style="font-family:arial;">IViewerGestureHandler</span> interface. For a <span style="font-family:arial;">DragTracker</span> this makes no sense, as it is exited as soon as the mouse key is released and you cannot start a drag and a multitouch gesture simultaneously.<br /><br />The <span style="font-family:arial;">RevealGestureTool</span> works as follows: Click on the + button to reveal the hidden connected elements, Then use <span style="font-style: italic;">ROTATE</span> or <span style="font-style: italic;">SWIPE</span> to rotate elements, <span style="font-style: italic;">ZOOM</span> to change the distance and right-click to select and pin individual elements. Another click will commit the input.Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com2tag:blogger.com,1999:blog-1495223311988358528.post-70690155990890914372012-01-18T15:16:00.005+01:002012-01-18T15:44:36.792+01:00Discovery Diagrams for the Generic Graphical ViewIf you've read my <a href="http://koehnlein.blogspot.com/2011/06/using-xbase-to-define-generic-graphical.html">previous posts</a> or seen my <a href="http://www.slideshare.net/schwurbel/a-fresh-look-at-graphical-editing-10068461">presentation</a> at EclipseCon Europe 2011, you'll already know the <a href="https://github.com/JanKoehnlein/Generic-Graph-View">Generic Graphical View</a> framework: Using two Xtext-based DSLs - one for mapping semantic to graphical elements and the other for styling the figures - you can easily create nice looking diagrams for any Java based model.<br /><br /> In its first version the contents of the diagram was entirely defined in the mapping DSL. It was only possible to restrict the visible elements to a subset of the model by adding filtering expressions in the mapping. For bigger models it was hard to focus on a subset that is not structural defined but based on semantics, e.g. all classes that deal with addresses in a CRM application.<br /><br />Many graphical frameworks handle the selection of the visible elements in a diagram by means of dialogs. The user is then forced to switch between keyboard and mouse which is annoying, and these dialogs are often complicated and unintuitive. The goal for the Generic Graph View project was to build a UI for choosing the diagram contents that uses the mouse or trackpad only and avoid dialogs at all cost. The following screencast demonstrates the basic functionality.<br /><br /><iframe src="http://player.vimeo.com/video/35256324?title=0&byline=0&portrait=0" webkitallowfullscreen="" mozallowfullscreen="" allowfullscreen="" frameborder="0" height="270" width="480"></iframe><br /><br />As a first step, actions were introduced that allow to hide existing graphical elements - nodes, labels or connections. If you hover over an element, you'll get an popup button allowing to remove it from the view. So you can start with a big diagram and strip it down to what you want to see. Once an element inside a node has been removed, you can restore the node completely using another popup button. You can define elements as initially hidden using a <span style="font-family: courier new;">hidden</span> flag in the mapping definition.<br /><br />In addition to the subtractive approach, you can step by step extend the diagram contents from an initial node. If you're hovering over a node that has hidden connection, several <span style="font-family: courier new;">+</span> buttons will popup. When one of these buttons is triggered, the hidden elements and connections will appear in transparent arranged in a circle around the source element. In the same drag operation you can change the distance and the angle of that circle. This behavior will get really cool with multitouch gestures, which I will cover in a separate post.Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com5tag:blogger.com,1999:blog-1495223311988358528.post-48184415280680913692011-11-07T09:54:00.006+01:002011-11-08T10:20:19.058+01:00Eclipse Con Europe 2011The slides of my talk <span style="font-style: italic;">A Fresh Look at Graphical Editing</span> at <a href="http://eclipsecon.org/">Eclipse Con Europe 2011</a> are <a href="http://www.slideshare.net/schwurbel/a-fresh-look-at-graphical-editing-10068461">online</a> now. If you're interested in the code it's on <a href="https://github.com/JanKoehnlein/Generic-Graph-View">github</a>, but remember it's a prototype - no tests so far, no support. Unfortunately, there was no cake being served at 5pm, so the pie fight had to be cancelled.<br /><br />As I have been asked this a couple of times at the booth: I am convined it makes <span style="font-weight: bold;">no</span> sense turning the presented <span style="font-style: italic;">view</span> framework into a graphical <span style="font-style: italic;">editing</span> framework. I am not entirely opposed to graphical editors but keep in mind that<br /><ol><li>You're going to need much more than graphical editing frameworks provide (projection, navigation, browsing, ...) I'd estimate a factor of 10-20 in the effort of building a graphical tool as opposed to a textual tool.<br /></li><li>The bi-directional mapping from the semantic model to the graphical one is source of a lot of problems. Not all of them can be hidden from the users.<br /></li><li>The structure of the semantic model must match the diagram model. This is not even true for the simplest models like UML2 class diagrams. You should be in a position to change the semantic metamodel to have a perfect structural match.<br /></li></ol>Would have been interested to discuss the last point with Bran Selic, who claimed in his keynote that UML2 is cool but the tools suck...<br /><br />Eclipse Con Europe 2011 was an excellent event as always. I really enjoyed meeting all the nice people from the community. Thanks a lot for the organization and especially for the delicious food.<br /><br />But remember: After the conference is before the conference. The CfP for <a href="http://eclipsecon.org/2012/">Eclipse Con 2012 in Reston, Virgina</a>, is open. Hope to see all of you there.Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com0tag:blogger.com,1999:blog-1495223311988358528.post-40532616953416226862011-10-31T10:31:00.006+01:002011-10-31T11:50:55.002+01:00Join My Pie Fight Session at EclipseCon Europe 2011<a href="http://www.eclipsecon.org/europe2011"><img style="float:right" src="http://www.eclipsecon.org/europe2011/sites/default/files/130x100_speaking.gif?1307137694" alt="EclipseCon Europe 2011" border="0" height="100" width="130" /></a>Competition is hard at <a href="http://www.eclipsecon.org">EclipseCon</a>: Everybody has to make sure to get the most participants into his talk. As <a href="http://blog.efftinge.de/2011/10/this-is-not-your-fathers-java.html">Sven already announced a quiz</a> for the same timeslot as mine I've had to figure out something even more exciting.<br /><br />So here's my idea for <a href="http://www.eclipsecon.org/sessions/fresh-look-graphical-editing">my session</a>:<br /><br />I'll begin the session ranting on every Eclipse project that's somehow related to graphics. I'll shamelessly reveal all of their weaknesses. Everybody involved in one of these projects will be so offended that they start to get personal, first against me then against each other. When emotions boil up, I expect people to self-organize in teams, like <span style="font-style: italic;">The Knights of GMF Runtime</span><span style="font-style: italic;"></span><span style="font-style: italic;"></span><span style="font-style: italic;"></span> or <span style="font-style: italic;">The Zest'o'Maniacs</span>. My session is at 5pm so I expect a good supply of cake as in the years before. I am starting the fight by throwing the first cake, e.g. on the <span style="font-style: italic;">GMF Tooling Ultras</span>. They try to answer but unluckily hit a member of the <span style="font-style: italic;">Spray Front</span>, who's already in the midst of a quarrel with a <span style="font-style: italic;">Graphiti Warrior</span>. Thinking it was a <span style="font-style: italic;">GEF Cyclope</span> who threw the cake... A real pie fight breaks loose.<br /><br />Hehehe (demonic laughter)<br /><br />Well... thinking again... the cake at EclipseCon is usually quite yummy. It would be a pity to waste it in such a way. Maybe I should come up with something more peaceful.<br /><br />OK, I see, I have to make that differently: I am going to point to some general issues with graphical editing. I'll weigh the cost against the usefullness and show, why an interpreted graphical view is so much simpler to implement and to use than a graphical editor. Second part will be a live demo of a prototype for such a framework.<br /><br />Maybe I should bring a helmet, just in case someone did not notice my change of plan.Anonymoushttp://www.blogger.com/profile/02520748795681285494noreply@blogger.com1