yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Desktop: fold the Jobs tab into Settings — library jobs under Library, metadata jobs elsewhere #27

New Issue
Closed
opened 2026-08-18 05:55:00 +00:00 by logan · 1 comment
logan commented 2026-08-18 05:55:00 +00:00
Collaborator
Copy Link
Copy Source

Report

The background-jobs tab should become a panel inside Settings. Library-related jobs (scans, mostly) belong in the Library section of Settings; the metadata-related ones belong wherever they fit best.

Findings

  • backend/jobs is the registry every long-running operation reports through — progress, pause/cancel, a global indicator, and a scan pause that survives a restart. Library scans, index builds, downloads and the autotag apply are registered.
  • The frontend has components/jobs/ (the view) and job-indicator (the header indicator) plus job-controls.ts, which keys its "you will discard hours of downloading" confirmation on KindIndexBuild — that confirmation must survive the move.
  • Settings is HTMX + templ server-rendered fragments in places and Lit in others; check which half a job panel lands in.

Direction

Split by job kind: scan/rescan/removal under Settings → Library, catalog/index/enrichment under the Explore or Metadata section, downloads under Downloads. Keep the global job-indicator in the header — it is the one thing that must remain visible from every page. Removing the tab pairs with the sidebar-toggles issue.

**Report** The background-jobs tab should become a panel inside Settings. Library-related jobs (scans, mostly) belong in the Library section of Settings; the metadata-related ones belong wherever they fit best. **Findings** - `backend/jobs` is the registry every long-running operation reports through — progress, pause/cancel, a global indicator, and a scan pause that survives a restart. Library scans, index builds, downloads and the autotag apply are registered. - The frontend has `components/jobs/` (the view) and `job-indicator` (the header indicator) plus `job-controls.ts`, which keys its "you will discard hours of downloading" confirmation on `KindIndexBuild` — that confirmation must survive the move. - Settings is HTMX + templ server-rendered fragments in places and Lit in others; check which half a job panel lands in. **Direction** Split by job kind: scan/rescan/removal under Settings → Library, catalog/index/enrichment under the Explore or Metadata section, downloads under Downloads. Keep the global `job-indicator` in the header — it is the one thing that must remain visible from every page. Removing the tab pairs with the sidebar-toggles issue.
logan added the Area/SettingsKind/EnhancementPlatform/Desktop
Priority
Medium
3
 labels 2026-08-18 14:36:08 +00:00
logan self-assigned this 2026-08-20 00:10:31 +00:00
logan added the
Status
In Progress
 label 2026-08-20 00:10:31 +00:00
logan commented 2026-08-20 00:10:32 +00:00
Author
Collaborator
Copy Link
Copy Source

Claiming. Branch: feat/27-jobs-into-settings.

Approach. Honouring the Direction's split-by-kind rather than
moving the page into one Settings section, because reading the code
first turned up that four of the five job kinds already have a home
that shows their work:

  • index-build / catalog-enrich — Settings → Search Index already
    renders per-tier progress, counts and errors.
  • download — downloads-view already shows every download with its
    lifecycle state.
  • autotag-apply — autotag-view already draws its own progress ring.
  • library-scan — nothing outside the Jobs tab, and the tab's own
    comment says the per-library scan controls used to live in
    Settings    .

So what the tab uniquely carries is (a) the per-library scan controls,
"Scan all" and "Full rescan", and (b) the generic job affordances —
pause/cancel, "Details", the log drawer, "Recently finished" — which
those four surfaces do not have.

Plan:

  • A <job-panel kinds="..."> in components/jobs/, reusing job-row,
    applyJobControl and job-details-drawer, embedded once each in
    Settings → Libraries, Settings → Search Index, the Downloads clients
    section and autotag-view. Every kind keeps a home, so no catch-all
    section is needed — a catch-all is the tab again under another name.
  • The scan controls and Full rescan return to Settings → Libraries.
  • jobs-view is deleted, and jobs goes from VIEW_TAGS,
    VIEW_LOADERS, services/view-meta.ts and backend/config.Views.
  • The header job-indicator is untouched, per the Direction. It is the
    cross-cutting view of everything at once, and it is on every page.

Two things I expect to bite, both noted for the PR.

job-controls.ts keys its "you will discard hours of downloading"
confirmation on KindIndexBuild, and that has to survive the move —
applyJobControl is shared, so embedding the panel rather than
re-implementing rows is what keeps it.

And a retired destination is the one case #25's storage shape does
not make free. An absent key takes its default and an unknown key is
dropped, but DefaultPage = "jobs" is a value: it would fail
validation on load and the app would refuse to start. That needs an
explicit retired-view list, which is a migration — worth having the
contrast written down next to the note that says the other half needed
none.

While there: config-page's Launch Page <select> still hardcodes its
ten options, which #25 left as a second copy of the launchable set. It
will be derived from VIEW_META, or removing Jobs means editing the
list in two places — exactly the fault this shape exists to avoid.

Claiming. Branch: `feat/27-jobs-into-settings`. **Approach.** Honouring the Direction's split-by-kind rather than moving the page into one Settings section, because reading the code first turned up that **four of the five job kinds already have a home that shows their work**: - `index-build` / `catalog-enrich` — Settings → Search Index already renders per-tier progress, counts and errors. - `download` — `downloads-view` already shows every download with its lifecycle state. - `autotag-apply` — `autotag-view` already draws its own progress ring. - `library-scan` — nothing outside the Jobs tab, and the tab's own comment says the per-library scan controls *used to live in Settings*. So what the tab uniquely carries is (a) the per-library scan controls, "Scan all" and "Full rescan", and (b) the generic job affordances — pause/cancel, "Details", the log drawer, "Recently finished" — which those four surfaces do **not** have. Plan: - A `<job-panel kinds="...">` in `components/jobs/`, reusing `job-row`, `applyJobControl` and `job-details-drawer`, embedded once each in Settings → Libraries, Settings → Search Index, the Downloads clients section and `autotag-view`. Every kind keeps a home, so no catch-all section is needed — a catch-all is the tab again under another name. - The scan controls and Full rescan return to Settings → Libraries. - `jobs-view` is deleted, and `jobs` goes from `VIEW_TAGS`, `VIEW_LOADERS`, `services/view-meta.ts` and `backend/config.Views`. - The header `job-indicator` is untouched, per the Direction. It is the cross-cutting view of everything at once, and it is on every page. **Two things I expect to bite, both noted for the PR.** `job-controls.ts` keys its "you will discard hours of downloading" confirmation on `KindIndexBuild`, and that has to survive the move — `applyJobControl` is shared, so embedding the panel rather than re-implementing rows is what keeps it. And **a retired destination is the one case #25's storage shape does not make free.** An absent key takes its default and an unknown key is dropped, but `DefaultPage = "jobs"` is a *value*: it would fail validation on load and the app would refuse to start. That needs an explicit retired-view list, which is a migration — worth having the contrast written down next to the note that says the other half needed none. While there: `config-page`'s Launch Page `<select>` still hardcodes its ten options, which #25 left as a second copy of the launchable set. It will be derived from `VIEW_META`, or removing Jobs means editing the list in two places — exactly the fault this shape exists to avoid.
logan closed this issue 2026-08-20 01:02:41 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-20 01:02:49 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Settings Kind/Enhancement Platform/Desktop
Priority
Medium
3
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees logan
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#27