Skip to content

feat(love): show who is sharing their screen - #11125

Merged
ArtyomSavchenko merged 1 commit into
hcengineering:developfrom
MichaelUray:feat/love-screen-share-name
Oct 29, 2026
Merged

ArtyomSavchenko merged 1 commit into
hcengineering:developfrom
MichaelUray:feat/love-screen-share-name

Conversation

@MichaelUray

Copy link
Copy Markdown
Contributor

Fixes #6188

Problem and change

The screen sharing view only attached the screen share video track and
did not keep the participant that published it, so viewers could not tell
whose screen was shown.

ScreenSharingView now remembers the publishing LiveKit participant along
with the active track, resolves the person from the participant identity
(falling back to the LiveKit participant name) and overlays a
"{name} is sharing the screen" label in the top left corner, styled like
the participant name labels. Adds the ScreenSharedBy string to all love
language files.

Tests

No unit test (Svelte wiring around LiveKit events). It needs a configured media server to try: start a meeting with two users and share a screen; the other participant sees "{name} is sharing the screen" in the room view and in the video popup, and the label disappears when sharing stops.

The screen sharing view only attached the screen share video track and
did not keep the participant that published it, so viewers could not tell
whose screen was shown.

ScreenSharingView now remembers the publishing LiveKit participant along
with the active track, resolves the person from the participant identity
(falling back to the LiveKit participant name) and overlays a
"{name} is sharing the screen" label in the top left corner, styled like
the participant name labels. Adds the ScreenSharedBy string to all love
language files.

Fixes hcengineering#6188

Signed-off-by: Michael Uray <michaeluray@users.noreply.github.com>
@MichaelUray
MichaelUray force-pushed the feat/love-screen-share-name branch from e6211d5 to 1b9203d Compare October 26, 2026 13:26
@ArtyomSavchenko

Copy link
Copy Markdown
Member

@MichaelUray Please take a look at the failed formatting step

@MichaelUray

Copy link
Copy Markdown
Contributor Author

@ArtyomSavchenko Thanks for checking this. I investigated the latest CI run on 1b9203d1; the formatting failure comes from mixed merge revisions.

The build checks out the moving PR merge ref, while formatting checks out the event’s original merge SHA. The build cache includes source files, so restoring it overlays newer develop changes onto the older checkout:

  • build logs Merge 1b9203d1… into f292d165… and Cache saved with key: Linux-build-cache-build-results-9f2be673ac330e6a8935f93bbae8d0f3f0939088.
  • formatting logs HEAD is now at 9f2be673ac Merge 1b9203d1… into e3f4f168…, logs Cache restored from key: Linux-build-cache-build-results-9f2be673ac330e6a8935f93bbae8d0f3f0939088, then exits 1 on five file diffs.
  • I matched every diff hunk to develop e3f4f168…f292d165, from #11144, #11072, #11068: plugins/tracker-resources/src/components/NewIssueHeader.svelte, plugins/tracker-resources/src/components/issues/edit/ControlPanel.svelte, plugins/view-resources/src/actionImpl.ts, plugins/view-resources/src/components/ActionHandler.svelte, plugins/view-resources/src/components/ActionsPopup.svelte. None of these files is changed by this PR.

I’m preparing a separate workflow-fix PR to pin the checkouts to github.sha, make cache consumers restore-only, and rebuild on a cache miss. Re-running an old run keeps its original workflow definition and can repeat these failures.

@ArtyomSavchenko
ArtyomSavchenko merged commit 9edcc46 into hcengineering:develop Oct 29, 2026
12 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Show person name, who is showing their display in LOVE app

2 participants