09b955dc751c4282e893dc753788f335b0dcae57
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
09b955dc75 |
Manage plugins from Setup > Plugins (#6420)
* Give built-in plugins an honest on/off state Every built-in reported itself enabled no matter what. A bar widget said "enabled" while sitting nowhere near the bar, and disabling a built-in service silently did nothing, because enabled meant "listed in plugins[]" and a built-in never is. Nothing surfaced that, since the only caller listing plugins was the CLI. For a widget, on and off is its place in the bar, so listPlugins reports layout membership -- what enable/disable actually toggles. For everything else built in, loading by default is the right behaviour to keep, so switching one off is recorded the other way round, in disabledPlugins[]. shell.json still carries only the deviation from the defaults: the key is dropped the moment nothing is switched off, leaving a config that never disabled anything byte-identical. isEnabled still answers a separate question -- whether the component loads at all -- and deliberately does not follow a widget out of the bar. omarchy.menu is both a widget and the menu itself, so tying the two together would let taking its button off the bar lock the menu out of the shell, with no way back that isn't the CLI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Manage plugins from Setup > Plugins Plugins were CLI-only. Setup > Plugins now offers Enable, Disable, Add, and Remove, each list living in the menu itself so picking a row acts on it. Enable and Disable cover the built-ins as well as anything installed -- the bar widgets you can put in the bar, the services and overlays you can switch off. Remove is limited to plugins the user installed, since a built-in has no checkout to delete, and stays hidden until there is one. Whole-bar replacements are left out; those are chosen under Style. Enabling a bar widget asks for a section first, because enabling alone drops it on the right and the only way to move it was a follow-up bar plugin move. The CLI asks the same question after its own add, so both paths place a widget the same way. Add and Remove run in a terminal: one needs a git URL and shows the trust warning before cloning, the other deletes a checkout and prints where it backed it up. Providers grew two hooks for this. placementFor turns a row into a submenu instead of an action, and volatile re-runs the enumeration when its submenu is entered -- picking from these lists is what changes them, and rows a provider no longer returns now drop out instead of lingering forever. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Trim the plugin menu after review Menu.qml carried its own shellQuote while already importing Util and calling Util.shellQuote a few lines up; two copies of the same escaping is one place for a future fix to miss. isDisabled walked the array by hand to compare values it writes itself, and dropDisabled was an eight-line helper with one caller. Two bugs came out of the same pass. A whole-bar replacement belongs under Style rather than these lists, but the exclusion sat in the shared row builder, so a third-party bar could be installed and never removed -- Remove would show an empty list under a guard that said something was there. The exclusion now sits on the two lists that mean it. Rows are keyed by id, and distinct plugin ids can slugify alike: acme.foo, acme_foo and acme-foo all give acme-foo. The merge keeps the first row per id, so the rest simply vanished from the list with nothing to say why. Row ids are now made distinct before merging. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Pick a plugin the way we pick a theme Setup > Plugins listed plugins as menu rows, which needed three providers, a placement submenu, a volatile-refresh hook and a row-swap in the merge. Only Font and Apps are built that way. Theme, Background, Unlock, Timezone and Keybindings all pipe a list into omarchy-menu-select instead, which is one action string and a small script -- so that is what these use now. The trade is search: a plugin name is no longer findable from the root prompt. Neither is a theme name or a timezone, and Enable Plugin still is, so the loss sits where the rest of the menu already puts it. Two pieces of the row machinery stay, because they are worth having for the lists that remain. A volatile provider re-runs when its submenu is entered, so a font installed since the shell started now shows up without restarting it, and rows a provider stops returning drop out. Row ids are still made distinct before merging: Fira Code and Fira-Code both slug to fira-code, and a repeated id was silently dropped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Let a picked option carry an icon Moving the plugin lists onto omarchy-menu-select cost them their glyphs: the select mode has always hardcoded an empty icon, which is why Timezone and Keybindings have none either. An option may now lead with one, as "<glyph><TAB><label>". The menu shows the glyph, filters on the label, and hands the label back, so a caller never strips a glyph off its own selection and a list of plain strings behaves exactly as before. The plugin picker uses it for the puzzle glyph on each plugin and the align glyphs on the sections, which also regain the capitals they lost when the section names were passed through raw. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Switch bars by enabling one A bar option was kept out of Enable and Disable on the grounds that picking which bar to run belongs under Style -- but nothing under Style ever offered it, so an installed bar could be added and removed and never actually put to use. The menu was guarding a door to a room that was never built. Enabling one is the switch. setEnabled already assigns bar.id for a bar option, so a bar has always replaced the one before it; only the picker's filter stood in the way. Dropping it costs nothing else, because enabled for a bar option means active: the bar in use is the one row absent from Enable, every other installed bar is one pick away, and the built-in is just another entry, so going back to it is enabling Bar. Disable keeps the exclusion. That is the one verb a bar cannot answer -- there is no off, only a successor -- and offering it would have listed the built-in bar on a stock system, where turning it off deletes a bar.id that was never set and nothing happens. A bar carries the bar glyph rather than the puzzle one, so a row that replaces the whole bar does not read like one more widget to switch on, and enable now says "Now using X as the bar" instead of "Enabled X", which understated a whole-bar swap in both the enable and the freshly-added path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Refuse a plugin that declares a kind it cannot load A kind is a promise to supply something to load, and the shell reads that something from a fixed key: entryPoints.bar to draw a bar, entryPoints.menu to open a menu. Nothing checked the promise. A manifest could claim kinds ["bar"] with no bar entry point, pass validation, install, and enable -- and then the bar would fall back to the built-in and the widget would be skipped, leaving a plugin that does nothing, explained only by a console.warn nobody reads. Our own plugins have been held to this table by plugins-test.sh all along. This holds third-party ones to the same table, at add and update time, where there is still someone to tell. A kind outside the table is left alone rather than guessed at, so a shell that learns a new kind does not need this list updated first. The cost is that a misspelled kind still installs quietly. omarchy-plugin-validate had no tests; it has some now. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Act on the plugin whose row was picked The picker showed a name and then looked that name up again across every plugin, filtered set or not, taking the first match. Two plugins can share a name: cloning one keeps the name it was cloned from, so the documented `omarchy plugin clone omarchy.clock local.clock` leaves two plugins called Clock. Enable listed the clone -- the built-in was already enabled, so only the clone was eligible -- and then enabled omarchy.clock, moving the built-in widget instead. Remove listed the clone and tried to delete a built-in that has no checkout to delete. A row now carries its id alongside its label, and the id is read back off the row that was picked instead of being derived from the name a second time. Where a name is not unique among the rows on offer, the label carries the id too, so two rows that would both say Clock can be told apart at all -- which they could not before, whichever one the pick resolved to. The verb prompt only ever sees the first two fields, so the menu shows what it always did. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Never ask a bar where to sit in the bar A manifest may declare both bar and bar-widget, and validation accepts it. The picker saw bar-widget, asked for a section, and passed it to enable. setEnabled takes bar as the dominant kind: it writes bar.id and returns, adding nothing to any layout, so the move that followed had no widget to find and failed -- after the bar had already been switched. A partial success with an error on the way out. Bar wins ahead of bar-widget now, in the picker and in the placement prompt `plugin add --enable` asks, so a bar is enabled without a placement it cannot use. The CLI refuses a placement on a bar outright, before the bar is switched rather than after, since `omarchy plugin enable <bar> --section left` could reach the same half-applied state without going through either. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Only replacement, no off * Add default placement for bar widgets * Simplify plugin menu actions * Document plugin placement behavior * Allow dropping widgets in empty bar space * Treat plugin dependencies as runtime invariants * Reject duplicate plugin ids on add --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
e57f3b286c |
Send and receive files with Taildrop (#6375)
* Send files to a tailnet machine with Taildrop The panel gets a send button next to the copy one on every machine that Tailscale grades as a Taildrop target, and `s` does the same from the keyboard. Picking runs through the XDG portal chooser, so it looks like the file dialog every other app opens. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TJQJfHXXApUk6En8EZisHg * Save incoming Taildrop files and say so Linux keeps Taildrop files in the daemon's inbox until someone asks for them, so nothing arrived until you ran `tailscale file get` by hand. A user service now stages each delivery next to the downloads directory, hands it over under a free name, and announces it — with a preview when it's an image, and a click to open it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TJQJfHXXApUk6En8EZisHg * Float every portal dialog, not just the titled ones The portal only ever shows dialogs, and the title regex missed any chooser an app names something else — ours included. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TJQJfHXXApUk6En8EZisHg * Re-run the Taildrop enable now that the unit ships The unit was never installed to /usr/lib/systemd/user/, so the enable had nothing to act on and machines that already ran the migration carry a marker for a no-op. Rename it so they get a working pass, and report what systemctl says instead of a bare failure line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Wait for the file chooser on the connection that asked for it The portal answers a request with a Response signal directed at the connection that made it, and dbus-daemon delivers directed signals only to that connection. gdbus monitor registers with AddMatch rather than BecomeMonitor, so it never saw the reply: every pick left omarchy-file-select blocked on a read that could not arrive, taking omarchy-tailscale-send down with it before it reached either its notification or the transfer. Make the call and wait for the signal on one connection, and give up after ten minutes so an unanswered dialog cannot strand the caller. Drop the "Sending to" notification while here, so a send reports once. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Mark Taildrop notifications with the panel's send glyph Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Stop a hung tailscale poll from freezing the panel Each poll is skipped while its own process is still running, so one that never exits leaves the panel showing whatever it last read, for good: the peer list keeps a woken machine missing, and opening the panel cannot help because open runs the same refresh that hits the same guard. Reap anything still running fifteen seconds after a refresh, well inside the thirty second interval, so the next tick starts clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Place a moved widget where an added one lands 'move omarchy.media left' named a section, not a slot, but the section went through as an explicit target, which resolves a missing index by appending. The widget landed on the far end of the row instead of after the section anchor where 'add' puts it. Its test has never run: the assertion covering this went in four hours after an unrelated layout change had already stopped the file, and the runner stops the whole suite at the first failure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Keep the config test from failing on things it is not about The center layout assertion pinned the whole row, so parking the indicators left of the clock broke a test named for update sitting next to weather. Assert that adjacency instead. The package-defaults check reads PKGBUILDs from the omarchy-pkgs repo and blew up with a traceback wherever that is not a sibling checkout. Skip it when the checkout is absent, honour OMARCHY_PKGS_ROOT when it is somewhere else, and keep failing when it is present and wrong. Between them these stopped the suite eighty files early. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Make the file chooser a Python command rather than a bash host for one The portal work was a heredoc wedged inside a bash script that existed only to parse two flags. Drop the host: argparse covers the flags, and the file says at the top why it is the one command here not written in bash. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Tell a chooser that never opened apart from one that was dismissed Three fixes from review: The poll watchdog rearmed on every refresh, so a refresh interval shorter than its timeout — the setting goes down to five seconds — pushed the deadline ahead of a hung process forever. Arm it on the launch that needs watching and leave it alone. omarchy-file-select exited 1 both for nothing picked and for a chooser that could not run, and omarchy-tailscale-send read it through a process substitution, which drops the status anyway. A session bus that was not there looked exactly like someone changing their mind. Separate the two exits and read them with a command substitution. Delivery picked a free name and then renamed, which overwrites anything that takes the name in between. Link to the name instead: link(2) refuses one that is taken, so the check and the claim are the same step. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
David Heinemeier Hansson
|
57923f0378 | Support positional section when moving bar widgets | ||
|
David Heinemeier HanssonandClaude Opus 5
|
d407454511 |
Use arithmetic conditionals for numeric tests in bin
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
2baf967e06 |
Extract shared shell.json editing helpers for the bar commands
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Kyunghyun Park
|
876d6bcd23 | Fix bar plugin JSON value validation | ||
|
David Heinemeier Hansson
|
182330465a |
Simplify omarchy-bar into a bar-settings and bar-plugin split
The omarchy-bar command had grown three overlapping ways to inspect the bar (show/layout/list/options, plus selected/active/available/widgets aliases) and mixed layout mutation in with bar-level settings. Untangle it into two focused commands: - omarchy-bar keeps only the bar-level settings that write shell.json: use, reset, position, transparent, and settings. reset now delegates to `use omarchy.bar` rather than duplicating the del(.bar.id) write. - omarchy-bar-plugin owns all layout mutation: add, move, remove, set, and replace, with the placement flags and jq resolve/anchor helpers. `omarchy bar plugin ...` routes here via the dispatcher. Drop the inspection commands entirely: the layout is visible on the bar, the config is shell.json, and widget/option ids come from `omarchy plugin list`. Nothing consumed the show output programmatically except tests. This also removes omarchy-bar-position, whose jq write was a duplicate of `omarchy bar position`. Strip environment-invariant guards (require_command, require_omarchy_path) that defended against jq or OMARCHY_PATH being absent — neither happens on a real system. Keep the user-input validation (--section/--index) and the atomic shell.json write. Update callers (service install/remove, refresh-shell, plugin-clone, plugin enable), keybindings, the menu, tests, and docs to the new split. |