cockpit icon indicating copy to clipboard operation
cockpit copied to clipboard

frontend: combine button-based mini-widgets

Open ES-Alexander opened this issue 7 months ago • 3 comments

Current behaviour

There's a growing list of mini-widgets that are just a single button (fullscreen, edit mode, joystick connection indicator, takeoff, change alt), with an icon (possibly indicating a state) and/or some text. Maintaining and documenting these separately is annoying, and it makes the widgets list needlessly long, which makes it harder to find desired widgets.

Expected or desired behaviour

Combining widgets with similar functionality/interfaces allows users to more easily reason about the application, while also reducing the maintenance load to keep interfaces consistent.

  1. Similar to the VeryGenericIndicator, I think the button widgets should be combined into a set of presets for the Action Button widget, and allow specifying the button icon/colour depending on the state of a data-lake variable.
  2. We could potentially even add Action functionality to the VeryGenericIndicator and turn it into a more generic ViewDo widget. This would combine a bunch of display logic, while also making it easier for existing indicator widgets to have some logical function associated with them (e.g. centring the camera, toggling input hold, toggling the lights, etc).

Prerequisites

  • [x] I have checked to make sure that a similar request has not already been filed or fixed.

ES-Alexander avatar May 06 '25 01:05 ES-Alexander

Totally!

rafaellehmkuhl avatar May 06 '25 02:05 rafaellehmkuhl

This concept could also be extended to include switches and checkboxes, which could be used as either inputs or (non-interactive) indicators depending on which kind of variable they're tied to (or tied to a configuration, if necessary).

ES-Alexander avatar Oct 08 '25 11:10 ES-Alexander

This concept could also be extended to include switches and checkboxes, which could be used as either inputs or (non-interactive) indicators depending on which kind of variable they're tied to (or tied to a configuration, if necessary).

To make things simpler and more clear, I think they should always be tied to data-lake variables, but they should have a read-only option in the configuration, to act as pure indicators.

In the case of variables that have allowUserToChangeValue as true, the read-only would be enforced.

rafaellehmkuhl avatar Oct 08 '25 12:10 rafaellehmkuhl