sverweij / state-machine-cat

write beautiful state charts :scream_cat:

Home Page:https://state-machine-cat.js.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add explicit bias for state placement and transition attachment?

LeeDoty opened this issue · comments

The most important issue I'm dealing with using smcat (which is awesome, BTW) is that the diagrams would be greatly improved with some manual tweaking.

Context

It's the primary blocker for using smcat to display state in our production monitoring system

Proposed Behavior

It would be nice if I could add bias when defining states and transitions.

Maybe something like this:

    X [label="X" color="black", position="below Y"]
    A [label="A" color="black", position="center"]

meaning: try to place state X below Y in it's superstate, or on the diagram generally. Try to bias placing state A in the middle of the graph (or the middle of it's superstate)

and

    X => Y [from="right", to="top"] : Done;

meaning: try to have the arrow go from the right side of state X to the top side of state Y

Some possible bias behavior examples:

  • move state X to the middle (or toward bottom, left, etc.) of the diagram or it's superstate
  • attach transition A to the right side of state X (instead of the top, etc.)
  • bias transitions from state X to state Y to emit from the left of x and terminate on the top of Y
  • Align state Y below state X, or even below and to the right of X
  • for superstate X, emit all internal transitions from the top, (or right side, etc.) to the internal states

Current Behavior

no control (that I'm aware of)

Playground for making things clearer

X [label="X" color="black"] :
{
X.Y [label="Y" color="gray"] :
{
X.Y.V [label="V" color="gray"] :
{
X.Y.V => X.Y.Z : 1. Done;
},
X.Y.Z [label="Z" color="gray"] : ,
X.Y.T [label="T" color="gray"] :
{
X.Y.T => X.Y.V : 3. bb;
X.Y.T => X.Y.V : 4. bb;
X.Y.T => X.U : 2. jj;
X.Y.T => X.W : 1. Done;
};
X.Y => X.Y.T : 2. aa;
X.Y => X.Y.T : 1. cc;
X.Y => X.Y.T : 9. dd;
X.Y => X.Y.T : 3. ee;
X.Y => X.Y.T : 6. ff;
X.Y => X.Y.T : 4. gg;
X.Y => X.Y.T : 8. hh;
X.Y => X.Y.T : 7. ii;
X.Y => X.Y.T : 5. ll;
},
X.W [label="W" active color="red"] :
{
X.W => X.Y.T : 2. aa;
X.W => X.Y.V : 8. dd;
X.W => X.U : 4. jj;
X.W => X.Y.V : 1. kk;
X.W => X.Y.V : 5. ff;
X.W => X.Y.T : 3. gg;
X.W => X.Y.V : 7. hh;
X.W => X.Y.V : 6. ii;
},
X.U [label="U" color="gray"] : ;
X.initial => X.W;
};

@LeeDoty thanks for this suggestion.

As noted in #117 I take it to be a bit broader - to pass more to the underlying render engine to nudge it into nicer behaviour (e.g. group and rank on states and removing constraints on some edges might help). This is already possible on graph level and on all states and/ or transitions at the same time (see the --dot-xxx-attrs parameters in the cli, and the dotXxxAttrs options in the API), but not on individual states and transitions yet.

(The same caveat as in #117 applies regarding timing, though ...)

commented

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.