(alt) feat: customize quick terminal size

[donaldguy]

Resolves #2384
Closes #3742

[donaldguy]

Because #3742 does not address my concern w.r.t. my ultrawide monitor: #2384 (comment), I started in on this and have drifted towards a somewhat different approach than @dmehala

I still need to do like ... all the swift parts (and maybe more Zig) so its not really a viable alternative right now, but I wanted to go ahead and show y'all where my head is at on it:

Approach / UX

While I did appreciate the one-and-done, works-for-all-the-positions idea of the comma-separated mainDimension + secondaryDimension values, I am not sure, in practice, one would ever want to leave @dmehala's quick-terminal-size values untouched while changing quick-terminal-position.

That is probably also true of my (quick-terminal-height and quick-terminal-width) approach, but I think that it probably is easier to look at it and imagine what outcome will be if/when you don't.

I did just the 2 new configs top-level to keep things simple, but in terms of how much both the use and per se meaning of these values is effectively always somewhat dependent on the quick-terminal-position, I do wonder if the correct syntax isn't something like

quick-terminal-position = top width=50% height=25%

instead, with these parts optional, obviously. That would somewhat follow on the keybind syntax (It could also share a KV sub-pair parser logic... but then we are starting pretty quickly to work our way back to a "real" config language (be it TOML or KDL or whatever), and I know that is something of an anti-goal. The absence of such abstraction readily reusable already there did dissuade me from going that direction, and that might be as-intended.)

I can certainly also imagine, e.g.

quick-terminal-position = top(width: 50%, height: 25%)

or so, but that also feels like trending towards "oops I re-invented HCL" (and if thats the way of things, these days it seems like the trend is to just go full lua)

Implementation so far:

For these Config members, I ended up sort of splitting the difference on the prior art of QuickTerminalSize.Size and, I realized after a while, FontStyle (another tagged union).

It did seem worth to me moving the percentage v pixels (…) distinction semantics more into the zig layer rather than just passing it through as a struct to C world and ~re-interpreting over on the Swift side.

further?

It seems potentially worth unifying screen-distance size-and-unit quantities into a single value type for these, window-{height,width}, window-padding-{x,y}, window-position-{x,y}? That needs to [also] speak cell size and/or points?. But I think that's desirable anyway to do rows/columns sizes.

If one goes more that way it may make sense to also put more of the ~conversions and such in zig and leave the swift to just calling the APIs with the final numbers.

That would probably obviate most of the need for a C exposure of this stuff, unless it is desired to be explicitly exposed to other clients in future.

[donaldguy]

Mouse resizing behavior

a priori denying from configuration

I am not sure how valuable full really is (vs e.g. 100%), but I didn't want to single-handedly reject the existing implementation's behavior w.r.t. non-resizability.

Under the quick-terminal-position with optional extensions syntaxes above, it seems like a per se width-resizable=[true|false] as a separate thing is perhaps more useful. (certainly the same can sort of be true with top level quick-terminal-{width,height}-resizable keys … but, if still doubling up v @dmehala, I didn't want to presume to pollute the namespace)

Bug?: edge "ripping"

I kinda assumed and was imagining in my further implementation that a top, bottom, left, or right positioned terminal (with the edge-dimensions as full or default) would only have one resize handle... at the outer edge.

I thought this was how it currently worked, but double checking my assumptions in defiance of ergonomics, it is not so!

[email protected]

this is also true for top, right, and bottom. (Testing bottom I also somehow managed once to move the whole thing away from edge and off-center, without resizing)

I imagine this is not intended?

If it is, then probably the offset from the edge should also be restored upon next toggle on?

Offsets more broadly

Like I said back over on #2384 (comment)

I suppose the ~problem is that [either you could still default to center OR] you need an additional config here (or a 4 number format?) to specify not only per-se width but also offset from edge

I am currently working towards the "still default to center" path - as that is what I in fact want (top center of my ultrawide), but certainly the alternative is not unthinkable

Center(ed) resizability

Discovery of this "ripability" makes it somewhat more surprising to subsequently confirm that center positioned quick-terminal is simply not resizable by mouse at all.

I assume the reason for that comes down to "if it is resized in one direction, it stops being centered?"

the same problem threatens to present itself for the others whereas my comments there say:

• "cross-axis" with width for top/bottom & height for left/right,
  space not utilized by a given value will be evenly distributed to center
  the window "along" the position-naming edge

... so I/someone might need to go ahead and see about hacking a good-enough forced-symmetrical/rebalancing resize operation into macOS? I do not know how flexible windowWillResize callback there is about facilitating such with a smooth UX, but certainly I assume that you could snap e.g. the bottom edge of window down to the same distance from screen center as the top edge upon release of handle on a center resize?

or just say no to mouse?

How much worse UX would it be to just kill off all resize handles for all positions of the quick-terminal and instead have some sort of resize_window action (something I imagine is also desirable with non-quick terminals but invites more of a fight with the window manager?)

[closing the loop one could probably re-bind a click handler into this action, that might

alternatively, the toggle_quick_terminal action could be (supplemented by) seperated out hide_quick_terminal and show_quick_terminal actions,

with the latter taking param(s) for size(-adjustment?) (and position? if one were to do away with this config being a per-restart thing. then always (or as needed) treating the window draw as re-initialization instead of a mere hide/show. Idk how much worse ~normal-case performance that would create.

[this approach could also obviate the addition of these size configs as a whole - just make it part of the keybind action (potentially allowing multiple binds to summon the terminal at different sizes? or indeed multiple quick terminals at different positions [or the same one at different positions]

I don't know how open things are (technically or philosophically) to actions with multiple params (and probably ideally other-than-positional specification)

[donaldguy]

Is this whole approach wrong? (pt. 1)

My inciting interest comes back to that… on my 49" slightly-curved ultrawide, this:

is not especially usable, and is surely a step backwards from iTerm's offering:

window-size v pane-size / size v padding; is full width/height for the best?

But I have no strong opinion that this is actually preferable to:

(with window-padding-x = 1000)

The only problems with padding really is that the config applies to all windows and I will never want as much padding for a normal window as for single pane quick terminal. [technically I can set that padding, open the quick terminal, remove it and reload config, then open other windows, but that's not great]

(Beyond that its just that like:

A. it would probably be slightly convenient if this was still mouse adjustable [as the boundary between 2 split panes is].

B. Looking at that offset-top, what I'd probably like is for adding a second pane to shift-over my centered one (whose padding should then collapse - currently padding remains and the pane is squeezed down to unusable width)

what is a window size here anyway?

The fact that window-padding-color exists already also sort of begs the question:

what about (literally or in effect) window-padding-color = transparent?

And considering that (and assuming its possible), the question dawns on me:

would the quick terminal (in each position) in practice be different if it were just always drawn (non-native) fullscreen window with transparent padding on one side? (or four sides in the case of center)

And like … I think the answer is largely no. The only exceptions I see are:

1. the animation
2. the fact that the "transparent padding" also should allow focus to pass through to windows underneath.
   (otherwise, they have the same limitations already vis-a-vis tabs and menu bar and such)

Maybe (2.) is a big enough "but" that what I'm saying is strictly worse than cajoling a different type of native window out of the OS

(It feels easy enough when quick-terminal-autohide = true and its effectively reduced to a macOS native "Hide"; but with false, I don't know how much becomes asked for in the proxying of the events through - but certainly I think with the same accessibility permissions needed for a global bind, the tools are all there)

But this approach does seem like it might have benefits.

[In particular, is "non-native fullscreen" already implemented on linux where quick-terminal is absent? if so, then it seems like this approach would unify things. It moves the needle away from platform-nativeness, but like … is that a meaningful option for the quick-terminal.

And for something like mouse-resizable or indeed action-resizable (singly or doubly) centered windows [and perhaps even the animation] - would that be easier / more maintainable in the Ghostty-native abstraction framework of cells and panes, vs grafting it onto the less-than-willing OS?

[donaldguy]

Is this whole approach wrong? (pt. 2)

Is the quick terminal a singleton?

Speaking of iTerm's behavior here, and struggling above in pt 1 with the over-application of windows-size-x, I'm reminded of how iTerm, for the most part, treats their HotKey Window as "just another profile"

Ghostty does not have such a concept as profiles or presets (beyond perhaps modified and reloaded config files that don't apply retroactively), but will that remain the case indefinitely?

If so, then yes, the quick-terminal IS probably a singelton special concern and should continue to be treated as such— and its reasonable for it gain further config properties as appropriate [though now that I realize that resize_split action already breaches the "many"-param (neither 0 nor 1) barrier for actions, I do think the idea of adding optional params to a show_quick_terminal (or just extant toggle_quick_terminal ignored when hiding) has some merit as well

If ghostty will need grow such a concept, then it is probably appropriate to start treating quick-terminal as "one of those" sooner rather than later?

(Either way) does it need its own configs for concerns it shares with regular windows?

So, the above question is relevant absolutely in terms of thinking about what is appropriate config syntax / organization (one can imagine config-file per "profile" and that as such, rather than example below, these things should just go off to ~/.config/ghostty/quick-terminal or so)

but even if there will only ever be the quick terminal and "all other normal windows", the question still remains, does this PR-fragment (and the one it proposes to eventually supersede) err when it starts to add semantically redundant configuration keys?

That is, is it desirable to avoid adding EITHER:

• quick-terminal-width and quick-terminal-height OR indeed comma-seperating
• quick-terminal-size

BECAUSE there already exist window-height and window-width. By the same token, would it then be worse if one (did want to support edge-offset positions of quick-terminal, so) added things that did the same thing as window-position-x and window-position-y?

Meanwhile, might it make sense that other extant configs (for colors, fonts, etc.) should be allowed to differ from others as well?

It seems like eventually you could get to a decent subset of configs having a quick-terminal-* form, soooo ... should you go ahead and short circuit that?

Drawing from the global: and all: prefixes of keybinds, I naturally think of (and can fairly easily see the shape of implementations for) each of:

qt:window-height = 25

or instead

window-height = 100 qt:25
# or
# window-height = 100
# window-height = qt:25

[or quick: if qt: is judged too apt to cause confusion with the Qt app/UI framework]

As for units, it may be fine to go ahead and restrict something like quick-terminal height/width units to cells/points.

but since it seems like there may be some interest in supporting at least px elsewhere, then
I go back to above's "further?" and say Ghostty (or at least Ghostty/config) may wish to have a shared size-unit concept.

(As to whether percentage [or fraction or ratio?] is applicable outside the quick-terminal context? probably. The easiest reasoning to me is that it refers to a percentage of the containing window for panes/offsets, and maybe that rolls up to a general percentage of screen for all windows; but also if you follow the logic of pt 1. maybe a quick-terminal is just an always-non-native-full-screen window and "percentage of window" (for a pane) cleanly applies)