Usage in QtQuick application is impossible without using internal API

[msarehn]

Currently, the StateMachineView can only be used with QtWidgets, even though it makes heavy use of QML internally. It would be nice if the widgets part were decoupled from the QtQuick part so that StateMachineView can be used in a QtQuick-only application.
At the moment this is only possible by employing some hacks like defining the _quickView QML context variable in the QtQuick application.

[krf]

That's right. So far it was always assumed KDSME is going to be embedded into a full-fledged Qt Widgets desktop application.

I'm not sure I have time to work on this, though. Patches welcome, though!

[krf]

Just had a deeper look at all this: It definitely won't be possible to get rid off the QtWidgets dependency altogether. Too many things from there are being pulled in by KDSME: E.g. the QUndoStack classes, the extra widgets supporting the central state machine view (e.g. the code editor, palette, etc.). So that's not possible.

It might be feasible and doable to decouple at least the StateMachineView class from QtWidgets, but on the other hand I'm not sure if there's a valid use-case for it.

Could you explain a bit more how you're using KDSME? Or is this just some research project?

[msarehn]

We had (ab-)used KDSME as a nice interface to graphviz layouting.
Background: Initially, we wanted to display an actual stategraph in our application (which is written with QtQuick). But we only need a single-level graph, no subgraphs. Additionally, we needed to define our own delegates for the states. So in the end we just used the KDSME core to interface with graphviz's layouting and did the rest manually.

By now we've moved to directly interfacing with graphviz. That gives us more options for customizing the graph properties (nodesep, ranksep, etc..). In the end, using KDSME for our rather simple use-case was overkill and the wrong tool for the job.

I still think that KDSME is a very nice tool and support for QtQuick hosts would make it even better. But for now, we don't need it.