add: launchTheme.css for consistent styling accross the whole components spectrum related to LaunchWindow
add: correct styles accross the popovers! with unstyled parameters in Popover.tsx because it was needed to make sure its the same
Previously the smoke-export harness only accepted a raw MP4 input path.
Validating the export pipeline on a real editor project (with its own
zoom regions, wallpaper, annotations, and webcam state) required
opening the editor by hand and clicking through the GUI.
This adds three new environment variables that are picked up by the
existing smoke-export query string plumbing:
- RECORDLY_SMOKE_EXPORT_PROJECT — path to a .recordly project file;
when set, the editor opens it via openProjectFileAtPath and applies
the saved state before the auto-export fires.
- RECORDLY_SMOKE_EXPORT_QUALITY — overrides the hard-coded "good"
quality used by the auto-export trigger; accepts medium / good /
high / source.
- RECORDLY_SMOKE_EXPORT_FPS — overrides the frame rate; accepts
24 / 30 / 60.
No behavior change for existing RECORDLY_SMOKE_EXPORT_INPUT runs;
the new inputs are strictly additive and optional. The startup log
line prefers the project path over the raw-input path when both are
populated.
BrowserWindow.setBounds() with x/y is silently ignored on Wayland (the
compositor owns window placement), so the IPC-driven HUD drag never
moved the window \u2014 it stayed put even though pointer events fired and
the cursor changed to grabbing.
Mark the drag handle as -webkit-app-region: drag on Linux (only in the
IPC/overlay mode; webcam-preview mode still uses the in-window CSS
transform) so the OS performs a real xdg_toplevel.move. Mirror the
resulting bounds into hudUserPosition via the window 'moved' event so
commit 224a480's in-place resize behavior keeps working on Linux.
Previously on Linux/Wayland, starting a fullscreen recording required three
separate picker interactions: an in-app source dropdown plus two xdg-desktop-portal
dialogs. The duplicate portal dialogs were caused by:
1. resolveBrowserCaptureSource() calling desktopCapturer.getSources() in the
renderer, which itself triggers the portal on Wayland.
2. setDisplayMediaRequestHandler() in main also calling getSources(), which
triggers another portal.
3. Returning a pre-enumerated source id to Chromium, which on Wayland is stale
and forces Chromium to re-prompt via the portal during MediaStream creation.
Additionally, the editor window failed to appear after recording on some
Wayland sessions because 'ready-to-show' did not fire reliably.
Changes:
- LaunchWindow: skip the in-app source dropdown on Linux and start recording
directly; the OS portal becomes the source picker.
- useScreenRecorder: introduce a 'screen:linux-portal' sentinel source. When
set, route capture through navigator.mediaDevices.getDisplayMedia() so the
portal handles selection in a single dialog. Skip resolveBrowserCaptureSource
for the sentinel to avoid an extra getSources() call.
- electron/main: in setDisplayMediaRequestHandler, when the sentinel is set,
skip desktopCapturer.getSources() entirely and return a synthetic source so
Chromium opens the portal exactly once for the actual capture.
- electron/windows: in createEditorWindow, also call win.show() from
did-finish-load as a fallback for Linux/Wayland where ready-to-show may
not fire.
- Add Linux GPU config: use EGL (better Wayland compat), disable VAAPI
video decoder/encoder (many distros ship broken drivers causing
'vaInitialize failed' and preventing renderer from loading)
- Add ready-to-show fallback for HUD window: if did-finish-load never
fires (GPU failure), show the window after 500ms via ready-to-show
Ref #261
The HUD overlay snaps back to the centered default position whenever
recording starts because the idle-to-recording UI swap triggers a
resize, and applyHudOverlayBounds() always recomputes a centered
location. This is disruptive when the user has intentionally moved
the bar out of the way before a timed recording.
Remember the position after a drag ends and reuse it for subsequent
bounds updates, clamped to the current work area. The position resets
on app restart or when displays change so the bar cannot get stranded
off-screen.
- Add getHudOverlayDisplay() helper using getDisplayMatching()
to detect which display the HUD is currently on
- Replace getPrimaryDisplay() in getHudOverlayBounds(),
set-hud-overlay-compact-width, set-hud-overlay-measured-height
handlers, and createHudOverlayWindow() maxHeight constraint
- Falls back to primary display when HUD window doesn't exist
Tested on Windows 11 with dual-monitor setup. HUD stays on
the external monitor through recording start/stop and
expand/collapse cycles.
- replace path.normalize() with path.posix.normalize() in
resolveRequestedFilePath to preserve forward slashes on Windows
- add empty-string guard for degenerate pathnames
- remove win32 bypass in loadPackagedEditorWindow
path.normalize() converts / to \ on Windows, causing path.resolve
to escape to the drive root and return 403 Forbidden.
wiiiii123