* Document and support the established naming convention for config opts
This change:
* Rename `ConfigOptions` to `IConfigOptions` to match code convention/style, plus move it to a dedicated file
* Update comments and surrounding documentation
* Define every single documented option (from element-web's config.md)
* Enable a linter to enforce the convention
* Invent a translation layer for a different change to use
* No attempt to fix build errors from doing this (at this stage)
* Add demo of lint rule in action
* Fix all obvious instances of SdkConfig case conflicts
* Fix tests to use SdkConfig directly
* Add docs to make unset() calling safer
* Appease the linter
* Update documentation to match snake_case_config
* Fix more instances of square brackets off SdkConfig
* Remove leading slash from /addwidget Jitsi confs
Fixes https://github.com/vector-im/element-web/issues/19839
Signed-off-by: Andrew Ferrazzutti <fair@miscworks.net>
* Make requested changes
Signed-off-by: Andrew Ferrazzutti <fair@miscworks.net>
If your homeserver is configured with an experiment `widget_build_url`, this
will take over the functionality of the call buttons and turn them into a
general widget installer.
Behaviour constraints:
* If you're not in the conference, use a grey button that does nothing.
* If you're in the conference, show a button:
* If you're able to modify widgets in the room, annotate it in the context of ending the call for everyone and remove the widget. Use a confirmation dialog.
* If you're not able to modify widgets in the room, hang up.
For this we know that persistent Jitsi widgets will mean that the user is in the call, so we use that to determine if they are actually participating.
In theory, widgets could use iframe unload/beforeunload events for
cleanup, but in practice browsers have restrictions on what can be done
in those events which may not give sufficient time for clean
termination.
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Turns out that setUserWidget() wasn't updated to take a real WidgetType, but the code in ScalarMessaging thought it did. This leads to integration managers trying to add sticker widgets with an object `type` rather than a string `type`, which doesn't work.
This updates other code paths which call into the various widget classes to use WidgetType more often. The actual code path for fixing widgets is resolved in WidgetUtils for the setUserWidget function body.
Travis Ralston