mirror of
https://github.com/narrrl/proton-stream.git
synced 2026-11-04 00:47:00 +01:00
nvrl
d9ca8f8d60
- Desktop shows Proton's CAPTCHA instead of failing the sign-in: a wry webview in a child process of the app (`pstr-app::verify`), confined to https://*.proton.me, hands the token back and the sign-in is retried. Linux packages and CI gain WebKitGTK 4.1; the Windows zip and MSI ship WebView2Loader.dll, without which a -gnu build does not start. - The desktop keyring splits a secret too long for one entry across several, so a Proton session with many key salts survives Windows' 1280-unit cap. Short secrets stay one entry, so every existing secret still reads. - `WatchSync` runs against a small `HistoryDrive` trait and is tested end to end against an in-memory Drive: two devices, newer wins, no re-upload of an unchanged history, a missing file written again, an unreadable own file never overwritten, a newer-format file left alone. - An installation's file unwritten for 90 days is retired by the next device to sync, after its entries are merged and carried in that device's file. - Removing a share keeps its watch state: sync would bring it back from the other devices anyway, and re-adding the share picks up where it left off. - Watch history syncs once more on desktop exit (bounded to 3 s) and, on Android, through a WorkManager job enqueued when the app leaves the screen. - The second-factor prompts say security keys are not supported.
36 lines
1.3 KiB
Rust
36 lines
1.3 KiB
Rust
//! The `proton-stream` desktop application, as a library.
|
|
//!
|
|
//! A window over one or more Proton Drive public links: crawl them once, and
|
|
//! what is behind them becomes a library that plays without downloading first.
|
|
//!
|
|
//! Three threads' worth of work, kept apart on purpose:
|
|
//!
|
|
//! * **The UI thread** draws. It never opens a share, reads the catalog or
|
|
//! decodes an image — see [`engine`]. It is also the only thread that may
|
|
//! touch OpenGL, which is why [`video`] and the construction of a
|
|
//! [`playback::Playback`] both live on it.
|
|
//! * **The tokio runtime** does everything with a network or a disk in it. It is
|
|
//! built by the binary rather than with `#[tokio::main]`, because
|
|
//! [`pstr_player`] needs an `Arc<Runtime>` it can block on from mpv's demuxer
|
|
//! thread, which is outside tokio entirely.
|
|
//! * **A player thread** drives mpv for the length of a file — see [`playback`].
|
|
//!
|
|
//! This is a library as well as a binary so the parts that can only be checked
|
|
//! against a real GPU are reachable from `examples/` — see
|
|
//! `examples/embedded_video.rs`, which is the smoke test for [`video`].
|
|
|
|
pub mod app;
|
|
pub mod desktop_prefs;
|
|
pub mod engine;
|
|
pub mod inhibit;
|
|
pub mod instance;
|
|
pub mod media;
|
|
pub mod notify;
|
|
pub mod pacing;
|
|
pub mod playback;
|
|
pub mod theme;
|
|
pub mod ui;
|
|
pub mod verify;
|
|
pub mod video;
|
|
pub mod window;
|