Freitag, 27. April 2012

Eclipse User Help in your Xtext Hover


If you implemented your own language using Xtext and even documented all of its features in the eclipse user help you might want to show part of these information in your Xtext Hovers, too. This is more convenient to the users, since they don't have to search the whole user guide for the piece of information they are interesed in. 



Note:  This is not a post about how to implement Xtext hovers, Christian Dietrich wrote an excellent blog post on this topic called hover support in xtext 2.0.

The first thing you have to do is to register a context in your contexts.xml of your help plugin:

<context id="GeneratorContext" title="Code Generator Help">
     <topic href="help/user/CodeGenerators/generators.html" 
       label="Code Generator Help" />
</context>

In your MyDslEObjectDocumentationProvider, you can access the Eclipse Help Context using some classes of the org.eclipse.help plugin, which are unfortunately not public API. It makes sense to add some kind of caching, because this method is called every time a hover gets visible.


public class MyDslDocumentationProvider { 
 public String getDocumentation(EObject o) {
    ... 
    //Parse the help topic
    ContextFileProvider provider = new ContextFileProvider();
    IContext context = provider.getContext("GeneratorContext",
      Locale.getDefault().toString());
    IHelpResource[] relatedTopics = context.getRelatedTopics();
    // We assume that there is only one topic registered
    IHelpResource helpResource = relatedTopics[0];
    String href = helpResource.getHref().substring(1);
    URL url = new URL("platform:/plugin/" + href);
    return toString(url.openConnection().getInputStream());
 }
}

If you do not have a seperate html file for each proposal option,  you have to cut the relevant part out if it. I did this by placing html comments in my user guide, like <!-- Start  feature_outlet--> and <!-- End  feature_outlet-->. The identifier can be derived by the name of the context EObject.

Donnerstag, 29. März 2012

Yakindu M13 new and noteworthy

We published a new preview (called M13) of the upcoming Statechart Tools (SCT) 2.0 today!

The focus of this version was definitely on rounding the existing features off. So a lot of work was spent in Bug Fixing, writing Test Cases, as well as polishing meta models and APIs. Nevertheless the major feature in this release is the User Guide.
Of course it is integrated into the Eclipse help.
Installation & Update
It is available via our milestones update site: http://updates.yakindu.com/indigo/milestones . Use this Eclipse update site link to install the statechart tools into your existing Eclipse Indigo (3.7.2). For a new installation choose Eclipse menu Help/Install New Software … and Help/Check for Updates if you have already installed a preview version of SCT

Donnerstag, 15. September 2011

New features in SCT 2 Milestone 5

We published a new preview of the upcoming Statechart Tools 2.0 today! It is available via our milestones update site: http://updates.yakindu.com/indigo/milestones/
Apart from several bug fixes and some art work (thanks to our designer Carsten for the really cool icon set!)
we implemented the following major features in this milestone:


Submachine States
A submachine state is semantically equivalent to a composite state but it adds the mechanism to be reused in different contexts.   
 In the YAKINDU Statechart Tools, submachine states can be created directly via the diagram palette. This opens a dialog where the Statemachine can be selected, that should be included as a submachine. Submachine states are displayed with a small pictogram at the bottom right. A click on the pictogram opens the submachine diagram in a new editor.

Simulation 
The simulation of a state machines is integrated into the state machine diagram editor and provides visual highlighting of the active state and the current transitions. Additionally, the user can interact with the simulation by sending triggers to or by changing variable values within the simulator to drive the state machine.

The Debug View does also support multiple runtime instances (launches) of the same statechart. The Declarations View on the right and the diagram editor are aware of the selected lauch.
If a statechart with submachine states is executed, the Debug View shows the active states of the submachine ordered by the active regions. A selection of an active state opens the submachine in a new editor and highlights the active states.

Property Pages
Another major improvement are the form based property pages. For each selectable element in the statechart diagram, a custom property page is shown with rich controls like i.e. the Xtext StyledText widget.
The property pages also integrate tightly in the Eclipse help infrastructure and display context sensitive informations in the Dynamic Help View. In the future, we will add detailed information especially for the complex expression languages.

Code Generator for C++
the new preview also consists of a first implementation of a C++ code generator. The generator can be invoked via the context menu in the project explorer by selecting "Generate C++ code".
The code g enerator for C++ code creates the class "<Name>Statemachine" to be used by the programmer. The interface is defined in Statemachine.h and DataRepository.h. The interface mainly consists of a method to raise an event (queueEvent()) and to run one statemachine cycle (runCycle()). Additionally the class offers access to the variables via getter and setter methods. If there is a variable named "myVar" it is read by get_myVar() and can be written by set_myVar(value).
The statemachine implementation follows the event driven paradigm, therefore events can be fired at will and one cycle pops the oldest event and dispaches it. The method eventWaiting() indicates queued events ready to handle by a runCycle() call. To firstly initialize the statemachine, use the init() method.

Miscellaneous enhancements
  • Perspectives (Simulation / Modeling)
  • Hot Model Replacement (Edit the model during simulation)
  • Common Navigator Framework implementation for a tree based view of the semantic model
  • Launch Shortcuts
  • Several Validation rules added
  • Named entry and exit points
  • ....
I hope you enjoy this new version and please provide us some feedback!

Montag, 27. Juni 2011

YAKINDU Statechart Tools 2.0 preview online!

For everyone who is curious about what is going on with YAKINDU SCT (Statechart Tools) we have published a preview of the upcoming version 2 (SCT2).

YAKINDU SCT 1.x has been around for quite a while and finally got into maintenance state. Meanwhile we collected a lot of requirements and ideas about the future development of the statechart tools. The main goals are to improve the usability of the modeling and simulation tools, extend the statechart modeling features, wider support for testing and finally allowing domain specific extensions of statecharts. Since this is a big bunch of stuff we decided to go for a new major version of the YAKINDU SCT and not to care about backwards compatibility. So we have the option to continue parts that fit well but also are able to drop things that don't fit.

After roughly a half year of development some functionality is ready for a public preview. Some key features are still missing in this preview, i.e. the simulation engine and the code generators, but the meta model and the diagram editor is stable.





We implemented the following major improvements in this current preview:

new statechart editor
Version 1.0 of the statechart editor was created with GMF tooling. While GMF tooling is great for developing run-of-the-mill graphical editors in a couple of minutes, there are some major drawbacks when developing high-grade customized editors like the statechart tools. Thus, we decided to start version 2.0 as a complete redevelopment against the GMF runtime. The result is a graphical editor with 100% handwritten code that is well structured and easily maintainable.

usability & visual polishing
Some effort was spent in improving the usability by reworking the handling and visual design of statechart elements. This also included things like changing layouts, additional editing actions etc. Also the coloring in version 1.0 were always a matter of taste ;-) In SCT2 we use more decent coloring and font styles. These are just the first steps towards a very cool statechart editor.

advanced textual editing support
The most striking features is the wider use of textual parts on transitions, states, and statechart level. Since there was no good editor support in SCT 1.x (even though we used Xtext for parsing). We use Xtext-based in-diagram editors to provide code completion, syntax highlighting, validation, cross referencing etc. to support the user creating complex statements. Give it a try - it is really cool. Those who are interested in the technical details can read my previous post.

extended modeling capabilities
We defined a new version of the statechart meta model that consists of elements that have graphical notation and others with textual notations. This meta model comes with a bunch a new modeling features like structured interfaces, events with values, local reactions (aka internal transitions), operations, derived events, clocks etc.. You can just play around with the code completion in the textual parts in order to explore the features.

The current plan is to provide a version of YAKINDU SCT2 that roughly covers the same functionality as the 1.x version has in respect to code generation and simulation features by end of september 2011. Everyone who wants to take a closer look may load the statechart tools from the update site:



Yakindu - http://updates.yakindu.com/indigo/milestones/ 
 
 

Montag, 18. April 2011

Xtext CellEditor integration

Recently, I wrote an article for the German Eclipse magazin together with my colleague Alexander about embedding an Xtext editor into a GMF editor. Although GMF comes with an (quite complex) API for integrating parsers and code completion, there are several good reasons to integrate Xtext to do the job.
Apart from syntactical parsing and code completion, Xtext offers syntax highlighing, cross-referencing, custom validation, and quickfixes to name just a few.


Especially when using complex statements like expression languages within a diagram, Xtext can help you building comfortable and robust editors, as you can see in the upcoming version 2.0 of the YAKINDU Statechart Tools I am currently working on. In this project, we integrate Xtext to specify state behavior among other things as you can see in the following screenshot.







 From the technical point of view, integrating Xtext in your diagram editor is straight forward with the API provided. All you have to do is to extend the abstract base class XtextLabelEditPart that defines two methods to set and receive the edit string, and one method to receive an instance of DirectEditManager.
This method can be implemented as follows:

@Override
    protected DirectEditManager createXTextDirectEditManager() {
        return new XtextDirectEditManager(this, getInjector(), getEditorStyles());
    }


The Guice injector used by the XTextDirectEditManager can be obtained from the Activator of the UI plug-in of your Xtext language. Possible edit styles are SWT.SINGLE or SWT.MULTI for single / multi line editors. The XtextDirectEditManager then creates an XtextCellEditor that has no dependencies to GMF. Because of this, one can use this CellEditor within a JFace StructuredViewer, as you can see in the following screenshot of a property page.


If you want to learn more about integrating Xtext into your GEF / GMF based editors you can either buy the 
 Eclipse Magazin or take a look at the YAKINDU SCT2 source code!