cockpit icon indicating copy to clipboard operation
cockpit copied to clipboard

Add support for action-calls-on-interaction from read-only input widgets

Open rafaellehmkuhl opened this issue 2 months ago • 1 comments

This came to my mind after reading this discussion.

The idea is: the user has a variable that is read-only (e.g.: a value coming from the MAVLink stream), like an arm state (boolean), and it creates an input widget of Switch type to show this state. As of now, the user interacting with this switch will cause nothing (or wrongly toggle the switch state till the updated arm state comes from the vehicle), but wouldn't it make sense for the user to actually be able to arm/disarm the vehicle by clicking this switch?

Today the user can kind of do that in a very convoluted way, by creating a middle-man variable with the desired state, assigning that to the input widget, creating an action linked to that variable to send new states of it to the action and creating a javascript action that updates the value of the middle-man one based on the value of the actual variable, with some proper delay. Yeah, I feel tired just from writing it.

This could be done in a much more fashioned way by adding a forms to the input widget configuration panel that allows the user to select the variable to which the input widget should be linked (e.g.: MAVLink/arm), the necessary configs for the action and the action field that should receive the new value when the input widget is interacted with (e.g.: the first parameter field in a MAVLink Action for arming). Under the hood we would simply create the Action, the middle-man DataLakeVariable and the ActionLink.

A much simpler alternative that could allow for easier integration (and will be needed for this more complex implementation anyway) is to simply allow an Input widget to:

  1. Show the value of a data-lake variable
  2. When interacted with, send the new value to a different data-lake variable, and not the one its showing the value of
  3. Enter a "loading" state after interacted with, and this loading state is finished when the value of the "show" variable changes and/or after some amount of time (configurable by the user)

Besides the arm/disarm, that could also be used for things like motor throttle, depth, altitude, velocity, zoom, focus. Thinking more about it, this would be a hell of a feature.

rafaellehmkuhl avatar Oct 08 '25 15:10 rafaellehmkuhl

Relevant to #2168 and #1868.

I think this meshes well with the idea of a more general "ViewDo" mini-widget, which I think is the best way forward for our general status indicators and buttons and the like. Many of our existing mini-widgets could get folded into that (just created as default configurations of it), and it leaves dedicated implementation and listing for just the ones which are actually doing something quite unique.

ES-Alexander avatar Oct 13 '25 21:10 ES-Alexander