Custom toolbar button with state

[k1ng]

It would be great to be able to add a custom button to the right-hand toolbar cluster and bind a custom command from keymap.conf to it.

The second part is the real point: the button should be able to act as an indicator. A script changes its look (filled / outlined icon, or just a different symbol), so the same button both shows a state and toggles it on click. Exactly like the flag at the bottom of the sidebar or the split button in the toolbar: filled when on, outlined when off.

Roughly:

command "My toggle" cmd+opt+t --toolbar circle

agtermctl toolbar state "My toggle" --symbol circle.fill

Without --toolbar nothing changes; the button only appears for those who explicitly ask for it.

[umputun]

I am sceptical about this one. The toolbar is per-window while custom commands are app-global, so what an untargeted toolbar state would even mean is the first thing to settle.

the cost is that a custom control and its state become a permanent feature to maintain, and the rough syntax needs a keymap change, since the format has no flags today.

on --symbol circle.fill specifically: I went the other way for the status glyph in #277 and shipped a fixed set of six shapes rather than free-form SF Symbol names, rendering a lot of candidates at the real 13pt and rejecting the ones that did not read distinctly at that size. Whatever this turned into, I would want a small legible set.

today agtermctl session context puts caller-owned text on the titlebar, and every custom command is already in the ⌃⇧O palette.

so, two questions. What is the workflow, concretely, and where does its state live? And is showing the state essential, or would a button that only runs the command still be useful? I need to understand the workflow before I can decide whether this belongs in agterm.

[k1ng]

Thanks, the questions helped. The honest answer to the second one: state is not essential. The indicator idea was layered on top, I have no real case for it, and I'm dropping it.

I'm still experimenting with custom commands, but more than once I've caught myself wishing I could put one of them on a button, so it's within reach of the mouse. I have half a dozen already and I don't remember which chord is which. Concretely, these are what I'd put on buttons:

• Finder in the current session's directory.
• Dashboard over flagged sessions only. My script on top of dashboard; it would sit naturally next to your dashboard button.
• A hotkey cheat sheet in an overlay. The irony is that opening the list of chords requires remembering a chord.
• Possibly the custom-command palette itself, as the mouse form of ⌃⇧O.

State lives nowhere: the button runs the command, that's all. Per-window then isn't a question: the command is app-global, the button is the same in every window, and it takes its context from that window's active session, exactly like a chord does.

On keymap: the form is yours. I wouldn't touch the command grammar; I'd add a separate line that refers to a command by name, something like toolbar "Finder here" folder. Without such a line nothing in the toolbar changes.

On the icon. The six status silhouettes don't fit here: in the toolbar they'd read as an indicator rather than a command, and filled at that size they're nearly indistinguishable. I understand why you didn't allow free-form names in #277, but that argument was about 13pt in the sidebar and telling states apart; this is different: the toolbar buttons are SF Symbols themselves at toolbar size, and the icon's meaning is set by whoever put the command on it. If free-form names are still unwelcome, a small list picked for toolbar size and clear of both the built-in buttons and the status shapes would do: folder, bolt, play, wrench, paperplane, questionmark.circle. And if even that is too much, a monogram works: the first letter of the command name in a rounded square.

[umputun]

not doing this one, and it's a product call rather than a cost one.

a direct button would be quicker than what exists today, I'm not disputing that. But custom toolbar elements are an IDE idea, and agterm is keyboard-first. The toolbar is a small set of app-owned controls, and once one of them can come from keymap.conf I end up owning the rest of it: order, grouping, which ones to hide, what a dozen of them do to the title bar. That is toolbar management, and it's not something I want to build or carry here.

on the recall part: ⌃⇧O lists every custom command with its assigned shortcut, and Navigate ▸ Custom Commands opens the same list by mouse, without remembering a shortcut. It still costs you a selection, so it's no replacement for a pinned button. It does cover not knowing which chord is which.

the icon question is moot now.

[umputun]

went a different way on this. Custom toolbar buttons from keymap.conf are still out, for the reasons above, but the part I could give you is a button on the toolbar: #582 adds a Custom commands button to the title bar. It is off by default, Settings ▸ Interface turns it on. A click opens a popover with every custom command and its chord, in the order of keymap.conf, and a click on a row runs it. So put the ones you reach for most at the top of the file.

this covers your list: your existing Finder, flagged-dashboard and cheat-sheet commands are one click plus one pick each, and the fourth, a mouse form of the command list, is the button itself.

[k1ng]

Thank you, this covers it. One click plus one pick is a fair trade for not owning a toolbar, and the button itself is the fourth item from my list. Ordering by the file is a nice touch: it makes the top of keymap.conf a priority list without any new syntax. I will turn it on as soon as it ships.