Feature: Interactive GUI

[aleneum]

Requirements:

• directed graphs
• nesting/subgraphs
• dynamic updates
• user interaction

Preferable:

• Python (but feels like Javascript/NodeJS offer waaaay more options)
• Graphviz/Dot support (including subgraphs)

Candidates:

• http://js.cytoscape.org
• https://github.com/cpettitt/dagre-d3

Note: This will probably end up in a separate project.

[tyarkoni]

Agree both that this would be great, and that it should probably go in a different project. But, in order to make it as modular as possible, it might be nice to try to design a JSON spec that serves as an intermediate representation between GUI and Python code. Then we could implement some JSONReader functionality in transitions that takes a JSON object as input, and constructs and returns a corresponding Machine instance (the location of the model definition would presumably be specified inside the JSON object, or passed in simultaneously). If we can do that, then the GUI would ideally generate a JSON spec for transitions rather than interfacing directly with the package.

If we decide to go the above route, it would also be nice to import export functionality in Machine that outputs the configuration to JSON. Then, people who don't need to maintain state but only want to track the configuration could easily store and send around compact, human-readable representations.

Of course, I may be overthinking this, as it's not like the typical Machine requires a lot of code, plus there would be little point in implementing an intermediate spec if literally the only thing using it is a GUI package.

[aleneum]

If we can do that, then the GUI would ideally generate a JSON spec for transitions rather than interfacing directly with the package.

Just to clarify what features we consider useful for such a GUI since I have been vague with this ticket: I am personally interested in a way to monitor and control a(n already instantiated) state machine remotely. Having a way to let transitions generate a state machine from JSON sounds like an interactive state machine creator. Do you think of a GUI more as a Controller or Creator (or both)? For both cases a JSON-spec sounds nonetheless useful though.

[johnarnold]

A tangent, but being able to dump machine state to json (instead of just pickle) would be cool for some other uses. There's probably a ton of stuff that won't serialize to json though.

[parthsharma1996]

Are there any updates on this? This feature would be super useful!

[parthsharma1996]

Pardon me for asking again but are there any plans to implement this? I might be able to help with some PRs

[aleneum]

Hi @parthsharma1996,

Pardon me for asking again but are there any plans to implement this?

unfortunately, I cannot give you a roadmap for this feature. What are you particularly interested in? A way to visualise graphs or a way to create/control graphs?

[parthsharma1996]

I am using the FSMs for Dialog Management in a chatbot.

I am more interested in

a way to create/control graphs

as I am currently dealing with FSMs with 10-20 states and 40-50 transitions and it would be great to be able to manage all that with a GUI instead of keep adding a dict for each transitions.
It gets very hard to get a high level overview of the relationships between states just by looking at the code.

I am also using a slightly modified and unsupported version (The DepedningMachine you illustrated in #269) so currently visualization isn't working very well either (I'll have to modify the GraphMachine to make that work I assume)

[aleneum]

it would be great to be able to manage all that with a GUI instead of keep adding a dict for each transitions.

I see. What I can offer is to publish the dev-json branch I am working on (what I just did) which adds an intermediate layer between the visualisation and Machine itself (MarkupMachine and HierarchicalMarkupMachine). This JSON representation will act as an exchange format. Additionally, I can outline the tornado (web) server to visualise the graph and trigger events.
Making graphs/machines editable may be a long road but this should illustrate the general idea.

I am also using a slightly modified and unsupported version

You probably have to alter the MarkupMachine._convert_transitions link to deal with this:

{'trigger': 'do', 'source': 'A', 'dest': {'1': 'B', '2': 'C'} , 'depends_on': 'func'} => 
{'trigger': 'do(func=1)', 'source': 'A', 'dest': 'B'} ...

This should at also 'fix' the pygraphviz visualization.
Note that dev-json is WIP and will be rebased to clean up the history when things settle.

[aleneum]

@parthsharma1996:

I published the initial version of transitions-gui. Feel free to check it out.

[Synss]

I have not actually checked it but just the idea: it is awesome!

[loicpw]

gave it a try, really nice, looks clear and simple to me, as a user I would love to have the ability to right click and directly add/write python scripts to handle transition events. Maybe a dummy question but would it be easily integrated into a web project like Django or others ?

[aleneum]

Hi @loicpw,

ability to right click and directly add/write python scripts to handle transition events

writing Python code which is sent to the web server and evaluated/executed is currently not on my list due to security concerns. However, the ability to add callback/condition names to states and transitions (model method strings ('do_something') as well as import handles ('imported.module.do_something')) definitely is.

Maybe a dummy question but would it be easily integrated into a web project like Django or others ?

very legit question! Since the user interaction and graph editing is handled by the client (javascript), it should not be an issue to use Django instead of Tornado.
main.js can be hosted by any web server with Websocket capability.
The client library currently expects a Websocket endpoint at ws://${document.location.host}/ws. Messages should be of the format {"method": "<method_name>", "arg": "<arguments>"}. The following messages are supported:

Generate graph (server -> client)

{
  "method": "update_machine",
  "arg": "<MarkupMachine.markup>"
}

Highlight transition (server -> client)

{
  "method": "state_changed",
  "arg": {
    "model": "<model_name>",
    "transition": {
      "source": "<source>",
      "dest": "<dest>", 
      "trigger": "<event_name>"
    }
  }
}

Trigger event (client -> server)

{
  "method": "trigger",
  "arg": "<trigger_name>"
}

Having a look at the WebSocketHandler and the overloaded _change_state in WebMachine here should provide a general idea. Basically a potential handler just needs to forward received Websocket messages to the machine, provide a send_message method for the machine to publish state changes and handle new connections by sending the machine's markup to the client.

[parthsharma1996]

@aleneum Thanks a lot for creating the GUI for transitions! I will check it out! Sorry for the delayed response, I was off from the project for a while.

Regarding this,

You probably have to alter the MarkupMachine._convert_transitions link to deal with this:

{'trigger': 'do', 'source': 'A', 'dest': {'1': 'B', '2': 'C'} , 'depends_on': 'func'} => 
{'trigger': 'do(func=1)', 'source': 'A', 'dest': 'B'} ...

This should at also 'fix' the pygraphviz visualization.
Note that dev-json is WIP and will be rebased to clean up the history when things settle.

I can't find the relevant code in any of the current branches. I assume that this has been changed ? I see markup_transitions instead of the json_transtions in them.

Which branch should I currently use? dev-json?
Also I don't see anything related to source and dest in the _convert_transitions function in the dev-json branch, so how do I got about converting the required representation :

{'trigger': 'do', 'source': 'A', 'dest': {'1': 'B', '2': 'C'} , 'depends_on': 'func'} => 
{'trigger': 'do(func=1)', 'source': 'A', 'dest': 'B'} ...

[aleneum]

Use next-release. The function MarkupMachine._convert_transitions starts here. This line:
t_def = _convert(trans, self.transition_attributes, self.skip_references) tries to convert every transition attribute into a string representation to create valid JSON. So right BEFORE that, you should check whether trans.dest is a dictionary. If thats the case you should create a set of 'dummy' transitions which are converted to json instead of the customized transition.

[aleneum]

Closing this issue since transitions-gui has been transferred to the pytransitions org and published on PyPI. Since 0.7.0 has been released, it no longer depends on the next-release branch of transitions. For feature requests or bug reports use the project's issue tracker.