Refactor the state machine in binaries/data/mods/public/gui/session/input.js

[Rolf Sievers]

In the input.js file, there is a comment which reads:

// TODO: it'd probably be nice to have a better state-machine system, with guaranteed
// entry/exit functions, since this is a bit broken now

I'd like to fix that, this ticket will document the progress and the discussion.

This ticket is blocked by #2407. (Because I won't drastically modify the file structure of input.js before you commit my patch over there.)

What is there

A rather basic implementation of one concrete state machine. (no abstraction) On closer inspection, it turns out those are actually a bunch of smaller state machines glued together along their entry and exit paths to a „default state.“ There is a second state machine as well, for postGui event processing.

Proposed change

A lightweight abstract system which does not know a lot about it's content. It has a state (Bandboxing, Building, Tribute), such a state describes the mechanics of a „smaller state machine“ from the current code. The outer wrapper is not a state machine (no transitions) as it does not posses any interesting feature. The inner state is not forced to be a state machine, it's internal structure is not inspected by the outer wrapper. As most of the „smaller state machines“ have just a single state, that prevents unnecessary abstraction.

This untangles all the different features contained in that one function.

Furthermore the central code of preEngine event handling and postEngine event handling can be unified.

Interface of a „state“

Without specifying any particular structure yet, a state must allow the following:

• Initializing it (The state receives a quitCallback to terminate itself)
• Processing an event (returns whether it was eaten or not)
• Terminating it

Obvious solutions would be:

• pass three parameters
• pass an object

Open Questions

• May I split that file (input.js) into many small parts? (selectionBox.js, orderStrutureBuild.js, ..)