Allow importing joystick mappings from BlueOS extensions

[rafaellehmkuhl]

Opening in draft as there were some suggestions in the RadCam meeting that I'm going to change before opening it for review:

• From joao: it would be nice to have joystick suggestions by source
• From joao: show somewhere the suggestions that were already accepted
• From wilson: add an "accept all suggestions" button (per source)

Fix #1859

[rafaellehmkuhl]

As noticed by @joaoantoniocardoso: we are missing a protocol field in the suggestions. Without it, we are registering based solely on IDs, which could (could?) cause conflicts between different protocols.

[joaoantoniocardoso]

Hi @rafaellehmkuhl, when I was implementing the API on my extension, I noticed that this implementation is using camelCase convention for the fields, which differs from the external widgets (see ExternalWidgetSetupInfo), and it is using kebab-case for the enum variants, which also differs from the external widgets (see WidgetType or MiniWidgetType).

It would be good if we could agree to stick to a convention for the entire cockpit_extras API.

[joaoantoniocardoso]

I added the joystick mapping using the current API to the Radcam Manager (current master), and it showed on Cockpit (only when it's running on BlueOS, and not locally, because of some CORS thing).

However, the mapped actions seem to be conflicting with already existing ones, somehow creating this oscillatory behavior when I click them (see it on the graphs):

mapped_buttons_are_fighting_each_other.mp4

[rafaellehmkuhl]

Hi @rafaellehmkuhl, when I was implementing the API on my extension, I noticed that this implementation is using camelCase convention for the fields, which differs from the external widgets (see ExternalWidgetSetupInfo), and it is using kebab-case for the enum variants, which also differs from the external widgets (see WidgetType or MiniWidgetType).

It would be good if we could agree to stick to a convention for the entire cockpit_extras API.

Fixed the usage of camelCase in the API. It is all in snake_case now.

The enums will have to stay as they are for historical purposes, otherwise we would break already-stablished APIs.

[joaoantoniocardoso]

Hi @rafaellehmkuhl, when I was implementing the API on my extension, I noticed that this implementation is using camelCase convention for the fields, which differs from the external widgets (see ExternalWidgetSetupInfo), and it is using kebab-case for the enum variants, which also differs from the external widgets (see WidgetType or MiniWidgetType).
It would be good if we could agree to stick to a convention for the entire cockpit_extras API.

Fixed the usage of camelCase in the API. It is all in snake_case now.

The enums will have to stay as they are for historical purposes, otherwise we would break already-stablished APIs.

Okay, but you could also make a parser that normalizes the old format to a new format, keeping backward compatibility while updating to this new uniform style.