bug: vivoactive6 unusable

> I am not sure if it's a good idea that we can only have now menus on va6 if we also have this ugly thing on the screen. In other words it might be a good idea to make it possible to enable the event triggering onActionMenu without the need to display the indicator.

Revisiting this statement (and my comments about it), now I see that Vivoactive 6 no longer has a button press (or long button press) which is intended to open a context-sensitive menu, unlike almost every other Garmin device in the past. (The one exception was Vivoactive 3, which used a long press of the screen to open a menu)

Now I have a better understanding of where this comment is coming from, specifically: "we can only have now menus on va6 if we also have this ugly thing on the screen."

It does seem that Garmin's intention is that every app (native or CIQ) will have to display the action menu indicator if they want to offer the user any kind of context-sensitive menu. (I assume that if the app wishes to display a full-screen menu, then the "standard" way to do this will be via an item in the action menu.)

I will say that it's still true that nothing prevents you from having a different way to open an action menu, but it's probably not a good idea.

In the previous comments, I was kind of assuming that CIQ will support setActionMenuIndicator() in FR955 and other 5-button touchscreen watches, and that onActionMenu() will work similarly to the native behaviour of the action menu indicator / action menu.

But perhaps this is a bad assumption since the supported devices section of the setMenuIndicator doc explicitly lists Vivoactive 6 and the announcement for SDK 8.1.1 specifically called out va6 with regards to this function.

Regardless, I think it still makes sense to look at the behaviour and purpose of the "action menu indicator" on other devices, even if it's not exactly the same on Vivoactive 6, and even if CIQ won't support it in the same way.

> In other words it might be a good idea to make it possible to enable the event triggering onActionMenu without the need to display the indicator.

If you want to have your own non-standard way of opening an action menu, nothing prevents you from responding to literally any input and calling showActionMenu() (as could've been done in the past.)

In other words, the *purpose* of onActionMenu is to allow apps to respond to the standard "left-swipe on action indicator" gesture. If you don't want to show the indicator, there's no need for onActionMenu.

> I am not sure if it's a good idea that we can only have now menus on va6 if we also have this ugly thing on the screen

I think that's absolutely intentional as clearly the purpose of the action menu indicator is to indicate that there's an action menu.

> In other words it might be a good idea to make it possible to enable the event triggering onActionMenu without the need to display the indicator.

If you want to have your own non-standard way of opening an action menu, nothing prevents you from responding to literally any input and calling showActionMenu() (as could've been done in the past.)

Speaking of onActionMenu, the docs for onActionMenu are confusing:

"Represents the Action Menu behavior.

This will be triggered when action menu is pushed. Invoke WatchUi.showActionMenu to push an action menu."

Yes, I get what was trying to be said here, but the meaning of "action menu is pushed" is completely different from "push an action menu" in the next sentence, so I think it's a very poor choice of words. Here there's two different meanings for "action menu" and two different meanings for "push[ed]".

"Action menu is pushed" clearly refers to the action menu indicator UI element, while "push an action menu" refers to an action menu view.

I don't have a good way to rewrite this, but I think it should be something along the lines of:

"Represents the Action Menu behavior.

This will be triggered will be triggered when the user swipes left on the action menu indicator. On some devices, the user can also tap on the action menu indicator or press START while the action menu indicator is visible [*]

Invoke WatchUi.showActionMenu to push an action menu view."

[*] It's unclear to me whether Garmin actually wants to trigger onActionMenu if the user presses START while the action menu is visible, on 5-button watches. This would match native behaviour, but it could also be limiting to devs who may want to use the START button for something else.

> setActionMenuIndicator as opposed to what it's name hints does not only enable or disable the indicator, but also enables or disables whether the swipe triggers onActionMenu. While I can kind of understand if this was a deliberate decision, I am not sure if it was,

In the native UI of other devices like fr955, the action menu indicator is a button hint next to the START button (at the top right of the screen). (Yes, this button hint is also used for other purposes in the native UI.)

When that button hint is displayed (and an action menu is available), then an action menu can be opened by:

- tapping the button hint

- swiping left (from the button hint or just below it)

- pressing START

Crucially, this hint is always displayed in the native UI when an action menu is available.

So I do think it's logical and intentional that the presence of the action menu indicator is tied to the left-swipe gesture to open the action menu. (At least it makes sense to me in the context of similar behaviour in fr955)

Maybe the confusing part is that it's called an "indicator" but it also "does" something?