It would be better if types which are used on places overloads operator << instead of using token_name function for string representation of tokens. Currently there is used token_name method which has to be specified for such types. But when types with token_name method and other types which usually provide their string representation through << operator have to be combined drawbacks come to light. It would be useful to have one unique way for providing string representation of a type. There is a question whether token_name method should be preserved and a new solution will be a combination of both attempts or it should be completely deleted?

There is barier example inside samples which seems to be a working version.

At the end of generating xdot state-space modify the resulting file, so that the transition names are used instead of their id.

There is problem with drawing blue area. It is cause by grabbing focus in commit: 95e3c75 I didn't make a fix, because I'm not sure about other consequences if I only deleted the grabbing.

I suggest, to implement a diff of two (or more) control sequences. With this it would be useful having a possibility to edit a control sequence. At least, to take a prefix and so on. Another interesting functionality could be a possibility to exchange an order of events in it. (Note. the resulting application could be run in a way that it continually records the control sequence, hence a user gain a prefix of what happen before some crash for example.).

Context still provides methods for tracing values within transitions. They should be removed.

Add a possibility to group the sources in tools. When a user starts working with a bigger number of sources, having a possibility to making groups could be very useful. For example, operations returning more than one source could group them automatically.

There are similar method as ca::all_processes and they are a part of Context. Moreover, this method takes context as its parameter, thus it would make better sense to have it also as a part of Context.

According to documentation and usage, I'd expected that a usage -b and -s arguments work also for MPI versionl. But only share memory version works with those flags. Maybe MPI version should warn about that.

I would exchange @buttons@ list passed into @ObjectList@ constructor for a more general widget or, maybe better, a list of widgets. Buttons are too specific and it limits a usage of this widget.

Now there's only the possibility on the invisible grid, which is not so helpful, because you can't think the net through so well, when you can't see it. It'd be great to have a visible grid in the editor on which you can attach elements of your net.

When the simulator is used and a user choose a specific process then there is still possibility to fire the second phase of transition on a different process. The problem should be visible from the following picture.

When a user imports the project and have open another tab than 'Welcome' or 'Nets' than it fails. An example is before importing project a user open tab tools and then try to import a project.

It'd be very helpful, if there'd be any possibility to remove multiple componets from the net at once. Now it's only possible to remove them one-by-one, which can be a very long-winded activity, if you need to rewrite part of your net radically.

It seems that MPI version of worker sample has stopped working. It lookes as it is freezed just after the start.

It'd be very useful to make PID always visible in token_name string. Now its visibility is not guaranteed, which can be sometimes really problematic, especially when we want to see a preview of token's content, but it's too large and it occupies all the space for token_name.

To achieve this permanent visibility I suggest to make PID independent on token_name function, so it'd be attached to the visible string every time. The second thing I suggest is to reduce the length of the token's "preview string", to make space for PID.

It can be very difficult now to keep track of a really large net. It'd be very useful to have some possibility to know one's location in the editor.

So, it'd be great to have a minimap showing your position.

The faster, but not so great, solution could be the button for getting to the centre of the net.

The bound of collective transition is wrongly computeted. Collective transitions aren't sensitive on the top border, while they are sensitive a bit under the transition. In the following picture is roughly outlined the problem.

Currently there is supposed that types which are used as place types provides some methods. However, there is no interface which I could use when writing a new type. It is true that there are some methods which can be put into header file of Kaira program, but when I write a new code I would like to keep it all at one place.

It'd be very helpful to have a "comment element" containing some text information which wouldn't be active otherwise in a net.

I mean something like this.