Current Status

Things to do: Simba ≤ 1.0 Not mandatory.

• Script Manager
• Debug heaptrc with Simba on Windows (Partially done)
• Change Settings API
• Settings GUI? (Being worked on)
• Report Box?
• Check for script modified (should be trivial now that external editor is done)
• UAC on Windows
• Allow to change font and other stuff via settings
• Add a settings that will force the simba updater to update once
• Add a way to automatically switch between stable and unstable with the Simba GUI
• CTS / Finder cleanup
• Provide Debug builds of Simba (Should not forget to provide these again on new releases)
• Updater form should not always show
• Support for external editor
• Fix open bugs: (There are more open bugs)
  • SendStrings does not work on all keyboard layouts (Windows only fix)
  • StrToInt
• Finish (are we ever) documentation:
• Document MML (Partially done)
• Document exported functions to PascalScript.
• Provide examples
• Switch to new interpreter (Lape or DWS) (Lape integrated)

Things to do: (Simba > 1.0)

• Documentation format / style.
• Change Extensions Settings, the way extensions are stored in Simba.
• Tabs for debug?
• Out of the process plugins / scripts: What route do we take?
• Python Integration
• d3d / ogl capture on Windows? (Already works on Linux)

Script Manager

The script manager server side is pretty simple; and quite complete. The client core library works, too. ReadySteadyGo has done some serious work on the Script Manager GUI.
Simba on github has a script-manager-rework branch which contains some of the work.

Documentation:

Python Integration

• Finish libMML and the accompanying pyMML. (Work in Progress)

Out of the process plugins / scripts.

We need a way to run scripts. This can be done in few ways.

	Bad script crash can cause Simba crash	Easy to share data	Hard(er) to share data	Remote control / network	Run in background
Embed in Simba, use threads	YES/PARTIALLY	YES	X	NO	PARTIALLY
Embed in Simba, use processes*	YES/PARTIALLY	PARTIALLY	YES	NO	PARTIALLY
Use MMLDaemon, use processes	NO	NO	YES	YES	YES

Personally, I think MMLDaemon would be the way to go. It:

• Allows remote control and if a script goes down hard it won't affect Simba in any way; since Simba is not in direct control of the script.
  You can even close Simba and the script will still run. The question is if we really want this?
• Will introduce some network latency.
• May prove to be hard to keep SMART running once a script is stopped. Would be possible with a SMART multiplexer service, using shm to quickly search SMART like we do now. But that is a lot of work.
• Can run multiple scripts / SMARTs at the same time. (Every script is just a new process, which can load a SMART)

It would be ever more neat if we throw the interpreters out of the Simba executable. Say, each interpreter is a shared object (library). Then both MMLDaemon and Simba could load it.

MML Daemon

• Write this page
• Script Manager (Then we can call Simba version 1.0)
• MMLDaemon:
  • Move interpreters out of Simba executable.
  • Make Simba load the interpreters externally.
  • Make MMLDaemon support the external interpreters.
  • Finish libMML.
    • Clean up (indenting + errors).
    • Finish dtm implementation.
    • Add bitmap implementation.
    • Add TPA implementation.
      Probably with a wrapper function (for copying results?) + auto generated functions?
  • Design MMLDaemon protocol. Write C-style library that people can use to work with the protocol.
  • Add MMLDaemon support to Simba.
    Simply with Interpreter -> PascalScript(MMLDaemon)?
  • Add Python support for libMML. (Or the other way around)

  Note that the above tasks do not say anything about how and when processes will start and die. The two main possibilities are to bind it to a tab in Simba indefinitely, or make it run in the background and add the possiblity to bind it to a tab. (The latter would allow people to shut down Simba and let their macros keep on going)

• Migrate documentation to the new format.