Better use of animation screens

[krisgesling]

Want to reconsider how we use the different animation screens to simplify the visual feedback for the user and make it clearer what's going on.
Note: these should probably all move to the Mark II Enclosure too.

Currently for a single utterance you can cycle through a range of screens, eg "play the news" may result in:

"listening" > "thinking" > "speaking" > idle screen > CPS UI

When ideally this should be at most:

"listening" > "thinking" > CPS UI

Likewise with the "current time" instead of:

"listening" > "thinking" > Time.qml

We can cut out the thinking animation.

Listening
After the wake word is detected, the vertical bar animation shows the device is listening. The challenge here is the time taken from activation to the animation starting. For very short intents you may finish speaking as the animation starts. If we can't get it to be relatively instant then maybe it's better to only use the LEDs on the device?

Thinking
Currently the dot rotating around the circle is shown after the listening has ended, until something else happens. This means that even for simple intents like the time, the thinking screen shows very briefly.
Suggest that we only show "thinking" when some delayed process is happening eg: Fallback Skills, Common Play

Speaking
This is shown if the Skill doesn't register a screen before the speech. Partly this would be a developer education issue - "you should display content and then trigger the speech".
Alternatively perhaps we provide a way for Skills to indicate that they handle the GUI. So it will display for any Skill not intentionally using the GUI.
Not sure the right way to go on this one...

[AIIX]

As I currently understand the process of animations it is very generically tied down to events that come in from mycroft-core, the skill only reacts with a animation to show when the core emits certain message on the bus, so maybe one solution could possibly be that if a skill needs to have something handled independently then it is for the skill to be displayed to tell core don't send so and so message over the bus so one of the animations do not get triggered, similarly for the Thinking part we don't know how much delay is to be expected before we start showing the thinking animation, this needs to be told by core to this skill that "hey its taking too long" lets start displaying the thinking circle animation by emitting that message bus event.

For listening, could replace the listening bars with something more around always running, than waiting for something to receive data, something non lottie and simple like:

[forslund]

We still have the page switch from the idle screen even if it's always running but maybe some latency can be cut if it didn't go via the mark-2 skill?

A hardcoded listening animation (in mycroft-gui-mark-2?) reacting to the wakeword detected / end of recording messages?

[AIIX]

We still have the page switch from the idle screen even if it's always running but maybe some latency can be cut if it didn't go via the mark-2 skill?

A hardcoded listening animation (in mycroft-gui-mark-2?) reacting to the wakeword detected / end of recording messages?

yes possibly, could be over layed above the skill view, with some simple animation running and visibility connected to the wakeword and end of listening events, this could avoid changing pages and page transition latency, similar to something like the status spinner you see in the mycroft-gui-app which is shown when wakeword is detected:

[notmart]

if that listening page with bars and what not is baked in the plasma shell and preloaded (so not in the mark2 skill), would for sure cut some delay as there would be much less moving parts to it