GUI support implementation: remaining tasks

[atsushieno]

Now that dc32932 brought in the basic implementation for GUI support from plugin Web UI down to remote plugin instance, we are in general "done" with the designing phase (#34) and switch to the implementation phase.

Here is the list of what we have done and what we need to do:

• document basic design. -> docs/design/GUI.md
• androidaudioplugin-ui-compose can show the WebUI and native UI to send parameter changes and note operations.
• activity based UI (mostly for Activity embedding)
• parameter changes need to be reflected on the compose host controls
• parameter change notifications from plugin need to be reflected on the UI (compose host controls and Web UI)
• aap-juce hosting: AudioProcessorEditor::createEditor implementation
  • for Web UI (using AndroidViewComponent; their WebBrowserComponent is incapable of handling JavaScript so it's not an option)
  • for native View (using GUI extension API) - maybe juceaap::AndroidAudioPluginFormat takes an option to enable native UI or not. Since it basically goes against Android practice, it should be disabled by default.

Many of those compose UI issues could rather be achieved by redesigning everything that depends on androidaudioplugin-samples-host-engine... (the features it offers are awkward right now).

[atsushieno]

Building Web UI for JUCE plugin atsushieno/aap-juce#22 is another issue that is more like an enhancement: it may be useful, but those desktop GUI is basically useless on mobiles and only visually attracting. It can be useful bait but Activity embedding would be enough for that purpose.

[atsushieno]

WIP

[atsushieno]

Looks like native UI does not show up on aap-lv2 plugins, and probably aap-juce plugins. Or in other words, only aapinstrumentpluginsample works so far.

aap-lv2 plugins and aap-juce plugins successfully provide Web UI and they show up. They seem to be stuck at aap::NonRealtimeLoopRunner, namely handleMessage() is not kicked.

[atsushieno]

superceded by #158.