Remove reviewer reply/roadmap drafts from repo
This commit is contained in:
@@ -1,15 +0,0 @@
|
|||||||
## Reply Draft (Copy/Paste)
|
|
||||||
|
|
||||||
Thanks for the very concrete review - that matches the real friction points almost perfectly.
|
|
||||||
|
|
||||||
A few things are intentionally built as Alpha/MVP tradeoffs, but I agree with your priorities:
|
|
||||||
|
|
||||||
- The dual backend is deliberately framed as "tauri first, chromium when needed", not as a defeat. The README now includes a simple decision rule and concrete examples.
|
|
||||||
- Build time is currently the biggest hurdle for time-to-first-success. This is exactly why the Chromium backend exists: many users want "works now" instead of a 2-5 minute local build plus prerequisites.
|
|
||||||
- Config persistence is the next logical step: update without having to re-specify URL/config should be the default once metadata is stored under `~/.local/share/deskify/`.
|
|
||||||
- Distribution: CI and a tag-based GitHub Release workflow already produce a Linux binary asset. Next step is to make "install from releases" more prominent and enable community packaging (e.g. AUR `-bin`).
|
|
||||||
|
|
||||||
Thanks also for calling out the WebKitGTK reality. That's why the backend story is explicit: system WebView where it works well, Chromium app mode when a site needs a newer engine.
|
|
||||||
|
|
||||||
If you're up for it, I'd love to keep you as a sparring partner specifically on time-to-first-success (docs/install/release), since that's often more decisive than feature count in OSS adoption.
|
|
||||||
|
|
||||||
@@ -1,36 +0,0 @@
|
|||||||
# Roadmap (Alpha)
|
|
||||||
|
|
||||||
This roadmap is intentionally pragmatic: it prioritizes "time-to-first-success" and UX gaps before deeper architecture work.
|
|
||||||
|
|
||||||
## P0 - Config Persistence
|
|
||||||
|
|
||||||
Goal: `deskify update <id>` works without `--url`, and `deskify list --verbose` can show URL/backend.
|
|
||||||
|
|
||||||
- Store metadata under `~/.local/share/deskify/apps/<id>.json`
|
|
||||||
- Persist (v1):
|
|
||||||
- `id`, `name`, `url`
|
|
||||||
- `backend`, `browser_bin` (optional), `profile_scope`
|
|
||||||
- `fullscreen`, `no_decorations`, `user_agent` (optional), `width`, `height`, `dark_mode`
|
|
||||||
- `schema_version`
|
|
||||||
- Migration: older installs without metadata should be migrated on first update/build
|
|
||||||
|
|
||||||
## P1 - Distribution / Onboarding
|
|
||||||
|
|
||||||
Goal: install `deskify` without a full Rust/Tauri toolchain.
|
|
||||||
|
|
||||||
- Promote "install from GitHub Releases" in README
|
|
||||||
- Keep CI releases producing a Linux binary asset
|
|
||||||
- Enable community packaging (AUR `deskify-bin`, etc.)
|
|
||||||
|
|
||||||
## P2 - Shared Runtime Model (only after P0/P1)
|
|
||||||
|
|
||||||
Goal: reduce per-app build time and prerequisites for the `tauri` backend.
|
|
||||||
|
|
||||||
- Concept: shared runtime/launcher + per-app configs (no per-app compile)
|
|
||||||
|
|
||||||
## P3 - QoL
|
|
||||||
|
|
||||||
- `deskify list --verbose` improvements (URLs/backend/profile scope)
|
|
||||||
- Better FAQ: WebView vs Chromium backend tradeoffs
|
|
||||||
- Optional DE integrations (later): KDE/GNOME widgets/extensions
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user