Adds Element Call support, call UI elements, and rudimentary widget support#2335
Adds Element Call support, call UI elements, and rudimentary widget support#2335GigiaJ wants to merge 258 commits intocinnyapp:devfrom
Conversation
add groundwork for intercepting the read_events so we can correctly process them (not sure what is wrong but I believe there is a weird set of version mismatches between the embedded app, cinny, and the matrix widget api)
Adds a separator for rooms based on voice vs text rooms
…have persistence that way)
…for when in call menu (not working yet)
still need to fix embedded behavior (standalone works for testing rn)
…planting a string with the url)
…dpoint if provided
CEbbinghaus
left a comment
There was a problem hiding this comment.
I cannot comment much on most of the UI code since I'm not overly familiar with frontend dev.
One big bit of UX to note is that unlike element, only "call" rooms have call functionality which sucks since it requires moving to entirely different rooms almost completely dedicated to calling.
Instead element allows for calling in any room via the top call button. It would be great if cinny could support this too. Especially given cinny (with this PR) isn't even able to accept a call initiated in a DM from a element client.
| const errcodes = [ | ||
| 'M_UNKNOWN', | ||
| 'M_BAD_JSON', | ||
| 'M_ROOM_IN_USE', | ||
| 'M_INVALID_ROOM_STATE', | ||
| 'M_UNSUPPORTED_ROOM_VERSION', | ||
| ]; |
There was a problem hiding this comment.
A lot of these changes are simply formatting changes, Probably best to reset all purely cosmetic changes to declutter the PR and make reviewing easier. Best to make stylistic changes in a separate PR
| const showRoom = roomToUnread.has(roomId) || roomId === selectedRoomId; | ||
| if (showRoom) return false; | ||
| return true; | ||
| const showRoomAnyway = |
There was a problem hiding this comment.
Why rename this to showRoomAnyways. showRoom is probably sufficient.
| count: hierarchy.length, | ||
| getScrollElement: () => scrollRef.current, | ||
| estimateSize: () => 0, | ||
| estimateSize: () => 32, |
There was a problem hiding this comment.
Pardon the novice question but what is the purpose of estimateSize and why are we changing it to 32?
| {!isSpace && ( | ||
| <SettingTile | ||
| title="Room type" | ||
| options={ | ||
| <SegmentControl | ||
| selected={roomType} | ||
| segments={[{ text: 'Text' }, { text: 'Call' }]} | ||
| onSelect={setRoomType} | ||
| /> | ||
| } | ||
| content={<Text variant="b3">Select the type of room.</Text>} | ||
| /> | ||
| )} |
There was a problem hiding this comment.
Apologies for the question but are matrix rooms locked into only one of the two options?
After having tested it there is always the ability to chat in a room with calls. and on element it is always possible to call in a room with chat (not so for cinny it seems), so why the arbitrary limit (note that element does support "call" rooms which I didn't know existed.
There was a problem hiding this comment.
Note however that I haven't yet found a way to create a call only room in element...
There was a problem hiding this comment.
edit: May only be a thing on the Element client.
I believe you may only be able to create a call-only room inside of a space. You click on the + button next to the space name, then New video room:
![]()
The result is a room which has the Video icon and text displayed under its name, to indicate it's a video room. The difference is that on desktop, it auto-throws you into the Element Call UI as soon as you click on the room. The room does still have a chat as usual.

There was a problem hiding this comment.
Hmmm that would make sense. Having call specific rooms I'n spaces seems sensible. Less so for just any odd room being created
There was a problem hiding this comment.
As it turns out element is able to create calls rooms outside of spaces too. But regardless, While call rooms being supported in cinny is awesome. Calls in arbitrary rooms & DMs is the primary feature Most will be looking for out of this PR
|
A few things which I see are holding this back:
Decisions and implementations would probably be needed for:
But from a practical point of view, the conflicts are the first blocker. This PR is 9mo old, I'm unsure how easy it would be to resolve them. Would it be an easier and faster option to try to reimplement the changes in the latest version of Cinny? |
| <RoomViewHeader /> | ||
| <Box grow="Yes"> | ||
| <CallView room={room} /> | ||
| {room.isCallRoom() && screenSize === ScreenSize.Desktop && ( |
There was a problem hiding this comment.
I think most people would like all rooms to have a call icon, not just call rooms. Although, only call rooms should have the widget shown in the chat window by default.
There was a problem hiding this comment.
As an alternative, I propose:
- Every room has the regular # icon by default, indicating it's a text chat
- When someone initiates a call in any room, the # icon changes into a speaker icon, indicating there's an active call.
I think that would be cleaner.
There was a problem hiding this comment.
100% agree, I misunderstood what you were referring to.
There was a problem hiding this comment.
No stress. Had a feeling. That's why we clarify 😄
| "ua-parser-js": "1.0.35" | ||
| }, | ||
| "devDependencies": { | ||
| "@element-hq/element-call-embedded": "0.12.2", |
There was a problem hiding this comment.
| "@element-hq/element-call-embedded": "0.12.2", | |
| "@element-hq/element-call-embedded": "0.16.3", |
There was a problem hiding this comment.
if you bump the element call version you will need to change src/app/features/call/SmallWidget.ts a bit on line 59
replacing hideHeader: 'true', with header: 'none', because hideheader doesnt exist anymore
and adding confineToRoom: 'true', to hide the weird "call lobby" ui that they automatically put you in when you leave the call
| "jotai": "2.6.0", | ||
| "linkify-react": "4.1.3", | ||
| "linkifyjs": "4.1.3", | ||
| "matrix-widget-api": "1.11.0", |
There was a problem hiding this comment.
| "matrix-widget-api": "1.11.0", | |
| "matrix-widget-api": "1.17.0", |
| "@atlaskit/pragmatic-drag-and-drop-auto-scroll": "1.3.0", | ||
| "@atlaskit/pragmatic-drag-and-drop-hitbox": "1.0.3", | ||
| "@fontsource/inter": "4.5.14", | ||
| "@matrix-org/react-sdk-module-api": "2.5.0", |
There was a problem hiding this comment.
This module does not exists anymore ...
|
Edit: figured most of it out |
|
The previous implementation of the actual call/lobby display was a bit jank imo, so I made a bunch of improvements to it and replaced the element call lobby with a custom one |
cinny-call.mp4 |
|
another change is that the ui shows the call controls even while not in call, so if you want to join a call muted you can do that |
Ask your questions here or in the relevant issue. |
|
@YoJames2019 you can make a pull request to this user's branch on their repo, or just create a new PR to cinny itself |
|
What's the progress on this looking like, as im sure many people will be considering a migration from discord to cinny |
I made a pr to GigiaJs branch, waiting on review and approval, if anyone else wants to go review it and suggest changes to the code it is very welcome |
|
Currently starting work on resolving conflicts with my branch and the current cinny dev branch and getting it up to date |
|
I wonder what will happen with cinny-desktop since tauri doesn't really support webrtc on linux |
|
I think the cinny-desktop tauri v2 PR would probably fix that. |
You might have to PR against cinny. I don’t think GigiaJs has been around in over 6 months but I could be wrong. |
|
Yeah we might need a fork of GigiaJ's PR that has been rebased against upstream. So basically a new PR. I wanted to do that if we didn't get any response from GigiaJ but looks like @YoJames2019 might be ahead of me |
I have literally 0 experience with this type of thing so it will probably take me a lot longer to figure out how this works. Here's my fork of this pr with all the changes i made above, you're very welcome to try to rebase it against upstream and make a new pr against cinny if you have experience since i dont see it getting pulled in to this pr anytime soon on account of GigiaJ being MIA |
|
after that we can actually work on direct message call support and polishing it up |
|
This looks so nice. |
I've had a very busy week but I will try to get some time on the weekend to jump onto this. 🤞 |
|
These additions are exactly what I need to get friends to move over, excellent PR! The desktop version performance is rough on Nvidia Linux due to having to use WEBKIT_DISABLE_DMABUF_RENDERER=1, but the PWA is fine for now, and will likely see these features sooner. Thanks for your hard work! |
I've done it, here's the new PR #2599 |
|
Closing in favor of #2599 |

Description
Adds Element Call support for both the npm embedded package as well as a hosted instance.
Adds a level of rudimentary widget support (not entirely sure of the extent even needed).
Adds calling interface elements such as a nav bar status section with a mute/unmute button, video enable/disable button, and hang up button. Icons are somewhat of a placeholder, but are relatively fitting.
Added a segmentation between Text rooms and Call rooms and provided an icon for call rooms (need to add the visibility icon support such as public/private/etc)
Added a --disabled for now-- icon for calling in DMs in the room header
Added dual iframe state juggling to provide lobby support akin to Discord where a user might wish to view another call's lobby or text channel
Added a text channel toggle to show or hide the room text channel
Added user icons and usernames to appear in the room nav to provide call activity visibility akin to Discord's previous interface implementation
Added mobile support for calling and text channel swapping and made the default behavior on mobile simply place you in the lobby and never in a call (does currently pop on your camera and mic, but is not joined to a call.)
Adjusted Room Header to account for a call room vs text room and behave accordingly
** Added a call or text room creation option in the room creation menu
Probably some other bits I'm forgetting, apologies. I feel like this is at a good enough stage to open a dialogue and move forward with, so I'm opening a PR.
Fixes #
#528
Type of change
Checklist: