feat(flatpak): add runtime fallbacks for sandbox#47
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 13e20bba66
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…from host ydotool Addresses both Codex review findings on PR #47: - P2: _restore_clipboard now handles the Qt clipboard backend, mirroring _copy_to_clipboard's Wayland/X11/Qt order. Previously a Qt-only host wrote the new text via Qt but left the transcribed text in the clipboard after autopaste instead of restoring the original. - P1: TestPasteClipboardRestore autopaste cases now mock app.paste_service.shutil.which so the paste() ydotool guard no longer short-circuits on CI runners that lack the host ydotool binary.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0f5ab822c1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if QThread.currentThread() == app.thread(): | ||
| return cb.text() | ||
| else: | ||
| return None |
There was a problem hiding this comment.
Marshal Qt clipboard reads before restoring
When the Qt fallback is the selected clipboard backend and paste is invoked from the transcription worker (see app/blitztext_linux.py where QThreadPool runs _TranscribeWorker.run), this branch returns None instead of reading the current clipboard. If ydotool is installed and auto-paste succeeds in an environment without wl-copy/xclip, previous_clipboard stays None, so _restore_clipboard(previous_clipboard) becomes a no-op and the user's original clipboard is overwritten. The existing fix only marshals Qt writes; Qt reads need the same treatment for worker-thread paste calls.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Bewusst als akzeptierter Narrow Edge-Case / Folgepunkt behandelt — Thread absichtlich NICHT resolved.
Der Fix in 13e20bb marshallt Qt-Clipboard-Writes auf den GUI-Thread; Qt-Reads aus dem Worker-Thread bleiben bewusst konservativ: _qt_read() gibt außerhalb des GUI-Threads None zurück (app/paste_service.py:401-404). Betroffen ist ausschließlich die seltene Kombination: Qt-Fallback als einziges Backend (weder wl-copy noch xclip vorhanden) UND ydotool installiert UND Paste aus dem Transkriptions-Worker (QThreadPool). Nur dann bleibt previous_clipboard=None, _restore_clipboard wird zum No-op und der transkribierte Text bleibt im Clipboard stehen.
Auf Standard-Wayland/X11-Hosts sowie bei GUI-Thread-Paste (ComposeWindow._on_paste_clicked) greift der Restore unverändert. Kein Datenverlust über den Clipboard-Inhalt hinaus. Wird als bekannter Folgepunkt für ein späteres Worker-Thread-Read-Marshalling dokumentiert.
GUI-only MVP scope: Qt6 shell, Qt clipboard fallback, PulseAudio recording, OpenAI cloud calls. Global hotkeys (evdev) and ydotool auto-paste stay visibly disabled inside the sandbox, matching the existing graceful-degradation code from PR #47. Local Whisper/torch transcription is deferred to keep the build check lightweight. Structural validation only (--show-manifest/--show-deps); no full flatpak-builder run since org.kde.Platform//6.8 + Sdk would need a ~1.5 GB download not in scope for this spike.
Adds runtime fallbacks so Blitztext can degrade gracefully inside a future Flatpak sandbox without introducing packaging files.
Summary:
Verification:
Scope: