Lukas Parsons
185667954c
CSS: added comprehensive zoom compensation for ALL modal-content variants (memory, tasks, preset, doclib, gallery, notes-pane, research, compare, email-lib) and a safety net for user-resized windows carrying inline height styles. JS (windowResize.js): _uiZoom() helper reads computed zoom from :root. Restore path divides saved localStorage dimensions by zoom factor. Resize-move viewport clamps use zoom-adjusted vh/vw so dragging never pushes the window beyond the visible area. Also added docs/improvement-tasks.md as the Ulysses task board.
48 lines
No EOL
4.2 KiB
Markdown
48 lines
No EOL
4.2 KiB
Markdown
# Ulysses Improvement Tasks
|
||
|
||
Last updated: 2026-07-07
|
||
|
||
## Priority: HIGH
|
||
|
||
- [ ] **Floating windows overflow viewport after zoom/font changes — unreachable controls**
|
||
`:root.ui-scale-125 { zoom: 1.25 }` renders all content 25% larger, but `window.innerHeight` doesn't change with `zoom` (CSS rendering only, not DOM). The `windowResize.js` saved-size restore at line 224 clamps to `window.innerHeight`, which after zoom makes windows 1.25× the visible viewport — pushing headers, close buttons, and top resize handles off-screen. The user literally can't close or move them. Fix: (a) divide restored height by zoom factor in the restore path; (b) add a general safety net — any `.modal-content` on open should clamp to `calc(100dvh / var(--ui-zoom, 1) - 40px)`. Also `windowResize.js` line 134 `if (top + height > vh)` needs zoom-aware `vh`. Current zoom compensation rules (line 181-196) only cover `.modal-content`, `.cal-modal-content`, `.settings-modal-content`, `#theme-popup`, `#cookbook-modal`, and `.pdf-export-overlay` — many windows lack the divisor.
|
||
|
||
- [ ] **Fix manage_documents tool schema — missing "read" action**
|
||
The `manage_documents` function-calling schema in `tool_schemas.py` has `"enum": ["list", "delete", "tidy"]` but the handler in `document_tools.py` supports `"read", "view", "open", "get"`. The model can't read documents through function calling. Fix: add read/view/open/get to enum, add `document_id`/`offset`/`limit` params, update description to mention reading.
|
||
|
||
- [ ] **Add "Send to Chat" button to document editor**
|
||
Button left of the Save button in `#doc-actions-footer`. Sends a document reference (title + doc_id + snippet) to the active chat, similar to how Cursor injects file references. Must NOT paste full content — just a reference the agent can resolve. Backend needs an endpoint or the existing `open_panel: documents` UI action may be enough. Requires: `POST /api/document/<id>/reference` or use existing `ui_control` with a new action. Frontend: insert button in `document.js` `_buildPaneHTML()` at line ~4598, wire JS handler.
|
||
|
||
## Priority: MEDIUM
|
||
|
||
- [ ] **Bolster Library/Documents CRUD via MCP or native tools**
|
||
Current document tools are solid but disjointed from agent-mode workflow. The agent has filesystem access (`read_file`, `write_file`, `edit_file`, `glob`, `ls`, `grep`, `bash`) but these tools operate on disk files, not Ulysses library documents. Need to bridge the gap: the agent should be able to list, read, grep, and edit library documents as naturally as files. Consider:
|
||
- A unified `read_document` tool distinct from `manage_documents` (which is an admin-style multi-action tool)
|
||
- A `grep_documents` or `search_documents` tool for semantic/fulltext search
|
||
- Auto-inject active document content into agent context when relevant
|
||
|
||
- [ ] **First-party document support in agent mode**
|
||
Documents feel "disjointed from the agent." The agent creates documents fine but can't easily discover or reference existing ones contextually. Ideas:
|
||
- "Agent workspace" awareness — automatically surface relevant documents based on chat context
|
||
- Document references in chat that are clickable and auto-expand
|
||
- The "Send to Chat" button (HIGH priority) is step 1; step 2 is making the agent proactively aware of library contents
|
||
|
||
- [ ] **Improve `create_document` schema description**
|
||
Current description is verbose and overlaps with `edit_file`/`write_file` disambiguation. Models sometimes use `create_document` for disk files. Add a clear leading signal: "DOCUMENT PANEL (not disk)" prefix like the existing "FILESYSTEM TOOL (not memory)" pattern.
|
||
|
||
## Priority: LOW
|
||
|
||
- [ ] **Document library: batch operations**
|
||
Multi-select, bulk delete, bulk export. Currently only single-document operations.
|
||
|
||
- [ ] **Document version diff view**
|
||
The version history panel shows versions but doesn't offer a side-by-side diff view between versions.
|
||
|
||
- [ ] **Auto-language detection on document open**
|
||
The editor auto-detects language on typing but not on initial document open from the library. Opening a Python file saved as "markdown" should suggest the language switch.
|
||
|
||
---
|
||
|
||
## Completed
|
||
|
||
<!-- Move completed items here with completion date --> |