mad-star-studio/element-web
2
0
Fork 0
Code Pull requests Activity

Apply prettier formatting

Browse source
This commit is contained in:
Michael Weimann 2022-12-09 13:28:29 +01:00
parent a32f12c8f3
commit 7921a6cbf8
No known key found for this signature in database
GPG key ID: 53F535A266BB9584
104 changed files with 12169 additions and 11047 deletions
Download patch file Download diff file Expand all files Collapse all files

20
docs/jitsi-dev.md
View file

@ -1,7 +1,7 @@
# Jitsi wrapper developer docs
*If you're looking for information on how to set up Jitsi in your Element, see
[jitsi.md](./jitsi.md) instead.*
_If you're looking for information on how to set up Jitsi in your Element, see
[jitsi.md](./jitsi.md) instead._
These docs are for developers wondering how the different conference buttons work
within Element. If you're not a developer, you're probably looking for [jitsi.md](./jitsi.md).
@ -46,24 +46,24 @@ end up creating a widget with a URL like `https://integrations.example.org?widge
The integration manager's wrapper will typically have another iframe to isolate the
widget from the client by yet another layer. The wrapper often provides other functionality
which might not be available on the embedded site, such as a fullscreen button or the
communication layer with the client (all widgets *should* be talking to the client
communication layer with the client (all widgets _should_ be talking to the client
over `postMessage`, even if they aren't going to be using the widget APIs).
Widgets added with the `/addwidget` command will *not* be wrapped as they are not going
through an integration manager. The widgets themselves *should* also work outside of
Widgets added with the `/addwidget` command will _not_ be wrapped as they are not going
through an integration manager. The widgets themselves _should_ also work outside of
Element. Widgets currently have a "pop out" button which opens them in a new tab and
therefore have no connection back to Riot.
## Jitsi widgets from integration managers
Integration managers will create an entire widget event and send it over `postMessage`
for the client to add to the room. This means that the integration manager gets to
for the client to add to the room. This means that the integration manager gets to
decide the conference domain, conference name, and other aspects of the widget. As
a result, users can end up with a Jitsi widget that does not use the same conference
server they specified in their config.json - this is expected.
Some integration managers allow the user to change the conference name while others
will generate one for the user.
will generate one for the user.
## Jitsi widgets generated by Element itself
@ -79,7 +79,7 @@ The Jitsi widget created by Element uses a local `jitsi.html` wrapper (or one ho
required `postMessage` calls are fulfilled.
**Note**: Per [jitsi.md](./jitsi.md) the `preferredDomain` can also come from the server's
client .well-known data.
client .well-known data.
## The Jitsi wrapper in Element
@ -92,9 +92,9 @@ and less risky to load. The local wrapper URL is populated with the conference i
from the original widget (which could be a v1 or v2 widget) so the user joins the right
call.
Critically, when the widget URL is reconstructed it does *not* take into account the
Critically, when the widget URL is reconstructed it does _not_ take into account the
config.json's `preferredDomain` for Jitsi. If it did this, users would end up on different
conference servers and therefore different calls entirely.
conference servers and therefore different calls entirely.
**Note**: Per [jitsi.md](./jitsi.md) the `preferredDomain` can also come from the server's
client .well-known data.