Feature Request: Using Back/Lap button in WatchFace mode

What is it you're wanting to do based on the user input? As I said, functionality is limited in a watchface, as far as what it can do - things like Comm and accessing sensors, you can't do. IIRC, no tones or vibrations either, and I'm sure I'm missing a few more.

Also, is it something that would work in "low power mode"? (that's how a watchface runs 99.9% of the time, where it only updates (runs) once per minute, and when it drops out of low power and runs every second, that only lasts about 10 seconds)

I would like to bring this discussion back to the light.

Time moved on. Developers are more educated and know what to do to save battery and cpu cycles.
Users are more demanding having smart devices on the hand and personaly i really dislike moments when finding out something is artificially limited while no really good reason has been provided why it is a must.

Most of the watchfaces turned to be "kind of widget" types with lot of data these days anyway.

I can imagine a lot of opportunities how to use toggle button - e.g. multi screen watchface using button to show currently preferred screen and/or cycling various graph data without need to fiddle with app settings  ... and many more.

Hence i would like Garmin guys to comment and potentially reconsider more than 4 years after. Is there more of you with the same view ?

One of the things that has changed is you can have a delegate in a watch face, but only for one specific reason - exceeding th power budget when using onPartialUpdate.

Trying do do input to a watch face still has the same restrictions.  Consider the case of onBack.  If you are viewing a watch face while in an activity from the widget loop, back is already used to return to the activity.

And if onBack was allowed in a watch face, what would the default behavior be if it wasn't handled?

I'm all for the idea of enabling the back button for watch faces, all it does is enable the light now

Another suggestion I made in the past to allow single click or double click events for touch devices was turned down too in the past. 

When/If reconsidering the back button behavior you might want to reconsider the click events too :)

Input control would allow for cool interactive watch faces 

Understand Jim, and i did not think it will be super easy. Your example is one of those which needs to be thought thru and newbie developer as me may have no clue about. 
However, coming from environment where figuring out how things can be done rather than rejecting them for whatever good reason is daily requirement, i still believe it is possible if there is a will.

I have WFs where what's displayed changes.  I start with a list of what can change, the user selects why items they are interested in seeing, and then those items rotate every minute (a full update of the WF when in low power mode).

If you want some additional data, a widget is only a button/swipe away to see that data.  The power usage for WFs is extremely important.  That's one the the reasons many things aren't allowed in watch faces.

I am aware of your proposed solution. Sounded acceptable, but after trying have to say user experience is not good regardless i can do more in widget. In addition widget occupies slot and times out. Thats not something i have in mind.

I would buy CPU cycles, but I am not buying power usage. Omiting fact it should be user/developer who decides what is acceptable for them from app power consumption perspective, many Garmin developers are very carefully thinking what and how they will code in more complicated apps. Sounds more as an artificial argument to me.

I can imagine required changes may be significant and Garmin may not have resources to work on it. Still, this request is 5 years old and so obvious and expectable. It would brings so many new options which could result into more sales and business that it seems like missed opportunity to me.

The "let the developer and user decide" isn't really that great an idea.  You could have "this burns a whole bunch of battery" in the description, and many users won't see it or remember they saw it, but instead complain about "battery usage in CIQ".

I think CPU cycles are irrelevant for this discussion, allowing user input by catching the lap button or allowing click events to be captured would not significantly increase the load on the cpu.