Best Scxml Debugger, but why C++ Builder

[ivti]

The Scxml Editor has no real competitor - regarding functionality and stability.

Congratulations.

But why C++ Builder from Embacadero?
What we read in the Web it is still crab - regarding reliability, customer handling and compatibility.
We decided years ago to abandon it, moved to Qt and we use today Clion as IDE. We just made some compatibility libs to speed up the port.

Only with such tools like yours Scxml in C++ can be used seriously.

But C++ builder is a no go. Sorry for that.
If you want help for porting we can provide some experiences.

This is definitely an opinion. You can delete it if you don't want it here.

[alexzhornyak]

Hi, ten years ago we started to use SCXML in our company projects. Initially SCXML files were written manually and it was a full mess with a lot of syntax mistakes, etc. Later we have found two option to use IDE: ScxmlGui and Eclipse Studio plugin later known as Yakindu.

ScxmlGui was too simple with a lot of missing very important features
Yakindu had very difficult graphic interface and redundant for our tasks but still missing all our needs.

So we decided to develop our own application that would be suit all our needs. We chose C++ Builder at that time mostly because of rapid development and small team. And in 2016 it became popular among scxml users, so we decided make it available for download.

I completely agree that C++ Builder is not a best option for it.

I personally see the best implementation of Scxml IDE would be as a plugin to Visual Studio Code. And there is even an active develompent of such project.

And the second way is to develop Qt Scxml Editor to the level of ScxmlEditor but unfortunately it seems like Qt company stopped development of scxml.

To summarize all this I think that the main problem of SCXML is a small C++ community interest

[ivti]

Hi, thank you for your answer. I saw it lately because it was sorted in other github messages.

We are using now the SCXML Editor for a while with a Qt project.
That the Qt company is not supporting SCXML in development is bad news.

What we found difficult during development is to find the best granularity between code and SCXML.

When using such a tool you must think more about your development and design process. And about designs in general.

This is somewhat in conflict with rapid development approaches - on what level ever.

SCXML was not made for Qt.

So, the signal/slot approach is in competition with SCXML.
There is always the temptation to make simply a local method to maintain state actions and thus to hide those actions.

For me the value of SCXML is to get the important structure of the application visible and force to think about the logic in the first place.

After forcing my programming colleagues to follow this path by and by , the advantage becomes visible to them.

It is a learning curve and there is no book where they can learn how to use this paradigm efficiently with C++ and/or Qt.

The common C++ programming patterns contradict also SCXML. It feels like something additional that is only overhead.

For us this is different because we have a massive module approach that allows to recombine compiled code just by configuration text files.

Everything is written in C++ but is configured by the configuration system.

So, C++ patterns appear only within functional modules. On the application or user use case level we have then SCXML and configurations.

But still this needs some additional abstract ideas to make clear where what shall be used.

So, this is not done by a snap and there is no good theoretical help. You must develop this by yourself.

It is not mainstream, it has implementation hurdles and this is I think the main problem behind the scenes.

The Qt editor implementation stops too early. Also another attempt like KDAB's (KDAB.COM) editor is also not really usable.

Your editor is a big step forward, but it needs also a learning curve to understand the details.

By the way: your tutorials are great

The only fear I have now is this damn C++ Builder company embarcadero. They produce again and again buggy versions.
Sometimes they abandon complete functionalities. This is why we left them years ago.

So it may be that some day it is not possible to compile the editor for an actual Windows Version.

[alexzhornyak]

I think that we need an option to export scxml with visual layout to Qt Creator layout format. To be able at least to save visual designs if ScxmlEditor won't compile anymore

[ivti]

I just thought porting to Qt ...

We have a database compatibility lib for TQuery.

And I found this here:

https://sourceforge.net/projects/dfm2qt4ui/

== dfm to Qt ui file converter.

But the effort is probably too high.

[alexzhornyak]

https://alexzhornyak.github.io/ScxmlEditor-Tutorial/Doc/ExportScxmlToSVG.html

It's much more easier for you to use SVG instead of DFM. You can write you parser from SVG to Qt Creator layout