Add system/e2e UI tests that automate ImGui

[adamkewley]

Estimate: 5-15d

This is a bigger testing change, which is to add the relevant libraries, tags, etc. that are necessary to entirely automatically test parts of the UI "as if" a user were actually clicking around in the UI (unlike the unit test issues like #237 and #637, which will be designed to run headless).

[adamkewley]

Here's some e2e test ideas from previous QAs:

• [ ] The editor/simulator toolbar buttons have the correct icons+comments
• [ ] The editor/simulator toolbar buttons work as expected
• [ ] The simulator toolbar scrubber works as expected
• [ ] 3D viewports in the editor behave correctly w.r.t. keybinds
• [ ] The editor 3D viewport contains gizmos that allow moving/rotating some scene elements
• [ ] The editor 3D viewport gizmos mostly behave as expected for a wide variety of components from the example files
• [ ] The editor 3D viewport gizmos work as expected even when multiple viewports are open
• [ ] The editor 3D viewport gizmos react as expected with the relevant keybinds (R for rotate, etc.)
• [ ] A fresh install has reasonable-ish panel locations
• [ ] All user-facing tutorial documentation can be carried out end-to-end without any confusion, surprises, or crashes
• [ ] The simulator can be stopped/cancelled by closing the simulation tab
• [ ] Can request to monitor model outputs, and they are then shown in the simulator tab
• [ ] The "select muscle" part of the add muscle plot feature says "no muscles" if used on a model with no muscles
• [ ] Exporting a mesh importer scene to an osim clears the dirty flag
• [ ] All user-visible keybinds in the mesh importer work as expected
• [ ] All user-visible buttons in the mesh importer work as expected
• [ ] It's possible to open multiple mesh importer tabs (tabbed interface)
• [ ] Doing anything in one mesh importer tab has no effect on the others. E.g. mouse interaction, keybinds, drag & drop should only affect the currently-open mesh importer tab
• [ ] All buttons in the main menu work as expected
• [ ] The coordinate editor panel works as expected
• [ ] All modals have a clear cancellation button that works
• [ ] Can have multiple 3D viewports open. They operate completely independently of eachover (ignoring scale fixups)
• [ ] Can right-click anything in the 3D viewports to produce a context menu for that thing
• [ ] Can right-click anything in the hierarchy viewer to produce a context menu for that thing
• [ ] Can click the lightning icon in the properties editor to produce a context menu for the selected component
• [ ] Can right-click anything in the hierarchy path (status bar) to produce a context menu for that thing
• [ ] Can right-click any coordinate in the coordinate editor to produce a context menu for that coordinate
• [ ] The hierarchy panel works as expected in the simulator tab
• [ ] The selection details panel works as expected in the simulator tab
• [ ] The outputs listing in the selection details panel allows for CSV (+open) support
• [ ] The outputs listing also enables "watching" the output, which adds it to the outputs watch list
• [ ] The simulation details panel works as expected
• [ ] Can right-click any muscle in a variety of OpenSim models (e.g. from opensim-models repo). It shows a list of coordinates. Clicking the coordinate starts a muscle plot.
• [ ] Can change the number of datapoints that are plotted in a live muscle plot

[adamkewley]

After going through the QA list (above), and clicking around in the UI to imagine some handy automations, the time estimate for this overall issue shot up and can't realistically be delivered by 0.4.1.

Instead, I'll try and at least integrate the necessary support code that's needed to automate the UI (#667), followed by later adding more tests (this issue).

[adamkewley]

I have briefly reviewed the e2e automation test suite used by ImGui (specifically, https://github.com/ocornut/imgui_test_engine) and the original estimate (5-15 days) seems accurate.

It'll take a few days for me to understand exactly how/where to integrate the test engine into OpenSimCreator (e.g. it will need to added as a submodule, wired in with CMake, and wired into the application framework). Then I'd need a few more days to understand exactly how it works, what its limitations are, etc., followed by a week or two of adding some OSC-specific automation.

There's insufficient time to do this before 0.5.2, and I still plan on changing several internals in the graphics/ImGui backend (e.g. making ImGui use OSC's renderer rather than its own custom OpenGL one). So I am going to kick this back until there is a large enough schedule gap later-enough in the project to justify the time investment - if I do it now then there's a high chance I will rip it all up very soon.

That said, there is still a benefit to separating the UI parts of OpenSim Creator from the logical parts and then unit-testing the logical parts - that wouldn't require e2e testing and can be done gradually on the existing codebase with no potential rework once the ImGui backend changes.

[adamkewley]

Dropping: it would be too big of a development burden to automate ImGui. Instead, the stopgap that's been implemented (of automatically loading various tabs one-by-one) is already part of the test suite and tends to kick out the worst bugs.