Multitouch gesture support for Zest graphs

When I read Jan Köhnlein’s post about multitouch gestures support in their graph viewer, I was thinking, these gestures would be a nice addition to the Zest visualization library. In addition to that, it could be my first new feature as a Zest committer, so I opened bug 371152.

So I looked into the multitouch API in SWT (btw. it is really to use, check snippet 353). Luckily, only a gesture listener had to be added, that is already supported by the Zest graph widget.

I thought about what gestures could be universally supported in the Zest graph, and found that scrolling is already supported, magnification is easy to implement, and for rotation I found a possible use.

Today, I finished the implementation, and created a short video presentation that shows the features in action. See the Youtube video: http://youtu.be/cVVxOIwHN7s

Additionally, it is possible to replace the built-in gestures by creating the graph with a specific style bit, and adding other gesture listeners manually as below:

//Disabling default gestures
Graph graph = new Graph(parent, ZestStyles.GESTURES_DISABLED);
//Adding own gesture listener
graph.addGestureListener(new GestureListener() {

  public void gesture(GestureEvent e) {
    switch (e.detail) {
      // Do nothing
    }
  }
});

I believe the base implementation of the gesture support is useful, but I am open to change it if someone has a better idea.

Reflective tree editor for Xtext-based languages

Xtext is a great technology. I really mean it. After 15-30 minutes (depending on your previous domain knowledge) you can get a really fancy textual editor, that parses your text into an EMF model. Xbase is even better: you can simply include Java-like expressions into your language, that can be easily translated into pure Java code.

However, while using Xtext I found some minor “paper-cuts”. One of the most problematic of them was the fact that I cannot open my textual models using the Sample Reflective Ecore  Model editor, as I get an exception: java.net.MalformedURLException: unknown protocol: java.

A similar exception occurred if I tried to open the files programatically (but without the help of the generated Xtext editor). When I asked in the Eclipse forums how to open Xtext model files programatically, I was answered (btw. very quickly – kudos for that 🙂 ) that a specific ResourceSet implementation is needed that refers to model files and classes available in a Java project.

This gave me the idea to create an Xtext extension that allows opening an EMF tree editor, the Xtext Reflective Tree Editor. The plug-in consists of two parts:

  1. An extended version of the org.eclipse.emf.ecore.presentation.EcoreEditor class, that opens its ResourceSet using the Xtext API (more specifically, uses an injected ResourceSet);
  2. And an Xtext generator fragment, that can be used to generate a new editor extension to the ui project (with the corresponding dependency added to the reflective editor plug-in).

Usage

To use the plug-in, just follow the following simple steps:

  1. Add hu.cubussapiens.xtext.reflectiveeditor as a dependency to your language project.
  2. Extend your editor generation workflow:
    1. Import the generator package: import hu.cubussapiens.xtext.reflectiveeditor.generator.*
    2. Add the new generator fragment at the end of the generator (file.extensions is the list of file extensions defined in the default workflow):
      fragment = ReflectiveXtextEditorFragment {
      fileExtensions = file.extensions
      }
    3. Regenerate your language.
  3. Unless the plugin.xml files are updated automatically, you have to copy the newly generated editor extension from the end of the plugin.xml_gen file of the ui plug-in to the plugin.xml file. The simplest way to do this is to select both files, and open the compare editor from the popup menu (Compare with/Each other…), the copy the changes manually.
  4. Finally, open the runtime workbench, and open your textual model files from the popup menu using Open with/«LanguageName» Reflective Editor. The result should be similar to the screenshot below.
https://i1.wp.com/cubussapiens.hu/wp-content/uploads/2012/02/xtext-reflective.png?resize=500%2C287 500w, https://i0.wp.com/cubussapiens.hu/wp-content/uploads/2012/02/xtext-reflective.png?w=519 519w" sizes="(max-width: 300px) 85vw, 300px" />
The Xtext Reflective Editor

In my case, the editor shows both the domain model generated from the file directly (the Pattern Model element), the inferred JVM model classes (the various JVM Generic Type instances), and also the referred Java classes as external resources (the resources beginning with the java:/ URIs).

Download

If you are interested in the plug-in in action, download it from our update site: http://eclipse.cubussapiens.hu, or take a look at the repository on Github: https://github.com/ujhelyiz/xtext-reflective

Version 0.5.3 is already available, and hopefully works well for all languages.

BMÓ project

2006-ot írunk. A Cubus Sapiens faj nemcsak elkezdte világhódító terveinek kiteljesítését, de már a gyerekeket is megfelelő egyedi intézményekbe járatja. Ilyen intézmény a BMÓ (Budapesti Műszaki és Gazdaságtudományi Óvoda). Az egyik nap, amikor a gyerekek kint játszottak az udvaron, az őket felügyelő két jómunkásember (óvó néni) rájött, hogy egyre kevesebb gyereket felügyelnek – kiderült, hogy elfelejtették feltelepíteni a legújabb biztonsági frissítést, és valahogy port nyílt a tűzfalon. A felügyelők azonnali igazgatósági értekezlet összehívása mellett döntöttek, ahol rövid tanácskozás után arra a döntésre jutottak, hogy az óvó nénik feladata lesz, hogy visszahozzák az elcsatangolt kölyköket. Egyszerre legfeljebb két óvó néni tud kinn a terepen lépkedni, a többiek a benn levőkre vigyáznak.

2006-ot írunk. A Cubus Sapiens faj nemcsak elkezdte világhódító terveinek kiteljesítését, de már a gyerekeket is megfelelő egyedi intézményekbe járatja. Ilyen intézmény a BMÓ (Budapesti Műszaki és Gazdaságtudományi Óvoda). Az egyik nap, amikor a gyerekek kint játszottak az udvaron, az őket felügyelő két jómunkásember (óvó néni) rájött, hogy egyre kevesebb gyereket felügyelnek – kiderült, hogy elfelejtették feltelepíteni a legújabb biztonsági frissítést, és valahogy port nyílt a tűzfalon. A felügyelők azonnali igazgatósági értekezlet összehívása mellett döntöttek, ahol rövid tanácskozás után arra a döntésre jutottak, hogy az óvó nénik feladata lesz, hogy visszahozzák az elcsatangolt kölyköket. Egyszerre legfeljebb két óvó néni tud kinn a terepen lépkedni, a többiek a benn levőkre vigyáznak.

A gyerekek mind szeretik a csokoládét, ezért egy 3-jegyű bináris szelettel (később 3Bit vagy csoki) könnyen rávehetők a visszatérésre. Az óvó nénik 5 szelet csokit tudnak egyszerre magukkal vinni, a készlet a pályán található csokiautomatákból pótolható. Ilyen automaták szerte a környéken vannak, valamint az óvodában is található egy. Ha egy óvó néni egy gyereknek csokit ad, az sorba áll az óvó néni mögött, így egy óvó néni egyszerre akárhány gyereket is vezethet.

A környéken szokott kóborolni minden nap Watch, a dog. Watch időnként minden látható ok nélkül elkezd ugatni, amit a BMÓs gyerekek nem szeretnek, és elszaladnak előle. A BMÓ környékén csokiautomaták és üzletek is fellelhetők – köztük a gyerekek kedvence, a PlayStation Cubus játékbolt, aminek előszeretettel nézegetik a kirakatát. Ha elmennek egy ilyen üzlet mellett, bizonyos gyerekek nekiállhatnak bámulni a kirakatot, aminek hatására elengedik a szomszédaik kezét, így megtörve a sort. Előfordulhat az is, hogy egy gyerek egy csokiautomatát kezd el bámulni. Ekkor is elengedi a szomszédai kezét.Egyéb épületek is lehetnek a pályán – a játékban annyi a szerepük, hogy sem az óvó nénik, sem a lurkók, sem Watch nem mehet keresztül rajtuk. Ezen felül lehetnek még utak és ligetek – ezek adják meg a lehetséges haladási irányokat.

A játékosok óvó néniket irányítanak, és céljuk az, hogy minél több elkóborolt lurkót kísérjenek vissza a BMÓra.

A csapat: Cubus Sapiens

A csapatban mindvégig maximálisan megvalósult a munkamegosztás a kódolás és dokumentáció terén a modern eszközök (cvs, wiki) révén. Mindazonáltal mindenki hozzájárult még ezen felül azzal az egyedi tálentumával, amire ő utánozhatatlanul képes. Íme a tagok (szigorúan alfabetikus rendezés szerint):

Grill Balázs Levente ‘Balage’

Az alázat és alkalmazkodóképesség megtestesülése. Photoshop-kezelő képességeit a GTA első részeit is lefőző játékgrafika megalkotására fordította.

Harmath Dénes Izidor ‘thSoft’

Gugli bácsi segítségével ő próbált minél kevésbé ízléstelen ikonokat keresni és találni a kezelőfelület csinosítására. A team dicsőségét megörökítendő, annak monogramját beleszerkesztette a 3. pályába. (Reméli, hogy az utókor ezt nem valamiféle kódszegmensre vagy sztrájkellenes játékprogramra való utalásként értelmezi.)

Kishonti István ‘Overander’

Az objektum-orientált szépség következetes képviselője. Mennyiségi rekordot állított fel az egy use-case diagramon elhelyezett use-case-ek, valamint az egy pályán szabadon eresztett lurkók számában.

Ujhelyi Zoltán ‘Stampie’

Őreá hárult a csapat rugdosásának hálás feladata és az egyéb adminisztrációs teendők. A team webmestereként ő lőtte be fáradságos munkával a fent említett online toolokat a hatékony csapatmunka érdekében. Az OpenOffice.org és a MagicDraw varázslatos világában elmerülve világcsúcsot állított fel a “Legtöbb Wiki Oldalból Generált PDF”, illetve a “Legtapasztaltabb UML-Diagram Készítő” kategóriákban.

Letöltés

Az utókor okulására a program fejlesztésének különböző fázisait is közzétesszük. Felhívjuk azonban a figyelmet arra, hogy bár az itt szereplő anyagok javarészt teljesítették a követelményeket, ezek fenntartások nélküli lemásolása, bizonyos (utólag már általunk is kevésbé bölcsnek ítélt) tervezői döntések átvétele nem javasolt, figyelembe véve a félévek egyedi feladatspecifikációt és projekt követelményeit.