79a6f26c2f8c494e910b9410bd8239eb33e3b6d5
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
79a6f26c2f
|
Open on the Feed, and refresh it without hammering yt-dlp
The tab order was Watch, Search, Feed, Browse, Downloads, and the app opened on Watch -- which is where the other tabs send you, not somewhere you start. It is now Feed, Search, Browse, Downloads, Watch, with icons. Routing is unaffected: _tab_index_of resolves by widget identity, not position. Refresh-on-open needed care rather than a call in showEvent. A local refresh is one yt-dlp subprocess per subscribed channel, serially, so it is braked four ways: only channels not seen for feed.auto_refresh_on_open_minutes (30, 0 to disable), at most eight per visit, once per interval per session, and after a delay so it does not race the tab transition or first-run setup. The cached feed is already on screen throughout. That is a new config key rather than the dead auto_refresh_minutes, because existing configs store that as 0 and would have read as opting out of a feature that did not exist yet. SmoothTabWidget gained the currentChanged signal, icons and a corner slot it never had. Its set_current_index needed a re-entrancy flag, not just an index check: setting the tab bar's index emits its currentChanged straight back into the same method, and at that point the stack has not moved, so every switch fired the activation hook twice. The grid was cleared and rebuilt after every channel finished -- flicker, lost scroll position and every thumbnail re-read from disk each time. merge_entries keeps existing cards. While there, _relayout was re-adding cards the layout already owned, so layout items accumulated on every Load more, and the resize check compared against columnCount(), which never shrinks, so it relaid out on every resize event. Smaller things this exposed: feed errors were written into the label the next success overwrote, so failures were invisible; switching to account mode left the local videos on screen; cancel() had no callers, so a refresh outlived the tab and the window; Browse's Subscribe never said Unsubscribe though it toggles; "Play all" queued one page while claiming otherwise; and the feed sorted publish times against wall-clock fetch times in one COALESCE, so the last-refreshed channel floated to the top. Feed is the first thing seen now, so an empty one says what to do about it instead of showing a bare grid. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
27933dd495
|
Make the player answer the keyboard and the mouse
PlayerPanel.keyPressEvent handled Space, F and Escape and was dead code: nothing in the player called setFocusPolicy, so focus went to whichever child button, slider or combo box was first in the tab order, and that child ate the keys. Fixing focus alone would not have been enough -- clicking play parks focus on the play button, which then swallows Space -- so the control bar is explicitly NoFocus and the bindings are QShortcuts with WidgetWithChildrenShortcut context on the panel. That fires whichever descendant holds focus, and does not reach the Search box or the URL field on other tabs the way an application shortcut would. mpv's own input stays disabled. With vo=libmpv there is no mpv-owned window, so its input layer receives nothing; enabling default bindings would mean hand-forwarding events through a Qt-to-mpv key-name table, handing mpv the OSD and OSC that are switched off here, and letting `q` quit the core out from under the Qt UI. One declarative action table now drives the shortcuts, the context menu and the buttons. There was no mouse handling at all. Click pauses, double-click goes fullscreen -- via a doubleClickInterval timer, so a double-click does not also pause on the way -- the wheel changes volume and Ctrl+wheel seeks, with sub-notch deltas accumulated so a trackpad is not inert. The control bar gained previous, next and mute. Mute and volume are driven by observed mpv properties rather than assumed, so the icon follows a change made by key, menu or mpv itself. Buffering was completely invisible: a stalled stream showed a frozen frame for 25 seconds before the retry with nothing on screen, so paused-for-cache now surfaces a label over the video. WatchPage owns next/previous because it owns the queue; the panel only asks. Previous restarts the current item when it is more than five seconds in, as every other player does, and pushes the interrupted item back onto the head of the queue rather than dropping it. Verified: all 38 bindings install, every action is a no-op rather than an exception with nothing loaded, focus policies are as intended, and a fullscreen round trip drives the player state correctly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
3aca43b372
|
Give the app icons, tooltips and a finished theme
There was no icon system at all. Transport buttons called QStyle.standardIcon(SP_MediaPlay), which returns the platform theme's dark monochrome glyph -- painted onto the app's saturated red buttons at a fixed 36px with no text, that is the black square. Everything else called an icon was an emoji baked into en.json, which is tofu wherever the emoji font is missing. Qt stylesheets cannot recolour a QIcon, so the colour is an argument to the new helper; that is the whole fix. The SVGs are drawn here rather than vendored, which keeps a third-party licence out of the tree, and they live in the module rather than as asset files, which keeps them out of package-data and safe in a frozen build. Tooltips were the other half: three widgets in the entire application had one and nothing set an accessible name. Filling that in at the call sites would have meant editing well over a hundred of them, most in upstream-owned files. Instead one application-level event filter handles QEvent.Polish, which Qt sends to every widget once before it is shown -- so it also reaches dialogs built by upstream code, and survives the next merge. It maps placeholder emoji to icons, fills empty tooltips from the button text, and logs icon-only buttons that still have none so the gaps are findable. StyleSheet.MAIN styles the window, inputs, buttons and tables and nothing else, so the main tab bar, combos, sliders, lists, menus, splitters, tooltips and the horizontal scrollbar fell through to the platform style. EXTRA_QSS covers them, in a fork-owned module appended at the one application site. SmoothTabWidget names its frame "tabContent" with the comment "We draw border on content instead" -- that rule existed only inside two dialogs, and now exists for the main window too. Two corrections to rules that were already there: the pressed style changed the padding, shifting every label two pixels and clipping fixed-width icon buttons, and checkboxes were fully rounded, which reads as a radio button rather than an on/off toggle. Verified by screenshot on the real display: tab bar, buttons, combo carets and checkboxes all render as intended, and all 35 icons rasterise non-empty. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
5ae2817eea
|
Stop the player freeing a render context libmpv still uses
The segfault: Qt destroys and recreates a widget's QOpenGLContext whenever it moves to another top-level window, then calls initializeGL() again. libmpv permits one render context per handle, so the second creation failed with "There is already a mpv_render_context set" -- and the except branch assigned self._render_ctx = None, dropping the last Python reference to the first context, which libmpv was still holding a function pointer into. python-mpv's MpvRenderContext has no __del__ and free() does not unregister the callback, so the ctypes trampoline was collected while registered and the next frame notification jumped into freed memory. Two invariants fix it. initializeGL() now tears down any existing render context first, so a second call is an ordinary recreation. Teardown clears update_cb, calls free() with the GL context current, and only then drops the reference -- and it is connected to QOpenGLContext.aboutToBeDestroyed, so it runs before the GL context dies instead of never. The local reference during teardown is load-bearing: it is what keeps the trampoline alive until free() returns. Three things were destroying that context. Fullscreen reparented the panel into a new top-level window (twice per toggle) and put it back at the end of the splitter, losing the pane layout; it now fullscreens the main window and hides the chrome, reparenting nothing. The tab cross-fade and the dialog blur both grab() the widget tree, which on an OpenGL surface forces a framebuffer readback and returns black -- the fade is skipped for pages holding the video, and dialogs dim rather than blur. Verified on a real Wayland GL context: ten forced context destroy/recreate cycles re-establish the render context every time, and the full app survives tab switching, six fullscreen toggles and resizes with no render-context error and a clean exit. Before this, the same startup dumped core. Also here because they are one-line consequences of touching _create_mpv: an explicit per-platform hwdec list ending in software decoding, and the restored volume actually reaching mpv -- the slider set its value before connecting its signal, so playback always started at 100. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
2420091a4e
|
Check for SageTube updates, not YTSage's
The update check asked PyPI for the `ytsage` package's version, asked GitHub for oop7/YTSage's release notes, and pointed the download button at upstream's releases. None of that describes this program. Being reminded to install YTSage was the visible symptom; the cause was that the check had never been repointed when the fork was made. It now reads SageTube's own releases from git.houmeres.sk. Gitea's release API is shaped like GitHub's, so the dialog and the caller are unchanged -- the class keeps its name and signal signature, and only its body moved out to core/ytsage_app_update.py, which is fork-owned and will not conflict on the next merge from upstream. Upstream's inherited tags end in `b` (v5.3.0b and earlier). packaging reads that as a beta marker, so they sort below v5.4.0 and a stable instance cannot be handed one. Tag parsing is defensive anyway: one unparseable tag must not take the whole check down with it. Also: the check is rate-limited to once a day rather than every start, the dialog gained a "Skip this version" that survives a restart, the thread is now joined on close, and the About dialog says SageTube. The three binary updaters -- yt-dlp, Deno, ffmpeg -- legitimately track their own upstreams and are deliberately untouched; ytsage_app_update's docstring says so, because "update" is an overloaded word in this codebase. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
089b144626
|
Correct the version and make the config merge deeply
The package version had been left at the scaffolded 0.1.0 while the released tag was v5.4.0. Nothing in the code chose 0.1.0 -- it was npm-init's equivalent, never updated -- and it made every version comparison meaningless: the window title, the About dialog and the update check all read it. ConfigManager merged a stored config over the defaults with dict.update(), which is shallow. A config written by an older build carries partial "player" and "feed" objects, and a shallow update replaces the whole nested default with the partial one, so keys added since came back missing. The `or 15` and `or "auto"` fallbacks at the call sites were load-bearing because of it. The merge is now recursive, and keys present only in the stored file are kept so a downgrade cannot destroy settings. Configs now carry a config_version. A file written before 5.4.0 -- including one inherited from an upstream YTSage install -- has its stored check_app_updates cleared once, because that setting used to point at PyPI's `ytsage` package and oop7/YTSage's releases, neither of which is this program. The settings tab read a missing check_app_updates as enabled and persisted that reading on OK, so merely opening Custom Options turned the checker back on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
b3772ff484
|
The fork's documentation on the wiki, and the history left alone
Building, upstream tracking and YTSage's own README moved to the wiki; README points there. The history is not rewritten, unlike every other repository here. This one still merges from oop7/YTSage and a rewrite would change every commit id, which costs more than a clean history is worth in a fork. .github/ and readme-translations/ are upstream's files and stay where upstream put them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |