On X11 gdk_device_get_modifier_state does not correctly return the
modifier state, while the modifier state passed to the key callback
does. On Wayland, the situation is exactly reversed.
Therefore on X11 we use the mods provided by the key callback and on
Wayland we continue to get the modifier state from the device.
`App.modifier_state_from_xkb` is removed since we can lift the
conditional out of the function call (we would need to make a second,
redundant check for the presence of `x11_xkb` otherwise).
Noticed that windows glitch when cascading: they show up in center of
screen, then quickly move to the correct position at last-cascade point.
This fixes the issue, by moving the `showWindow` call to _after_ the
setting of the last cascade point.
Now if you look at the code and think: "shouldn't this work without the
async-dispatch, like this?"
```swift
if (!window.styleMask.contains(.fullScreen)) {
Self.lastCascadePoint = window.cascadeTopLeft(from: Self.lastCascadePoint)
}
c.showWindow(self)
```
Then, yes, I had the same thought, but it doesn't. And as discussed on
Discord, we probably don't know what's going on behind the scenes.
So this is the simplified code of the version we have to live with:
async dispatching the cascade and non-cascade versions both.
A lot of the state that we put on Exec is just there to copy to
StreamHandler, but we already have it in DerivedConfig. I think this
whole copy copy copy is just legacy cruft since termio.Exec is one of
the older parts of the source code.
This rearchitects the Exec struct to act more like Surface and Renderer
where it stores its derived config. This lets us avoid a few extra
allocations and removes a LOT of struct member noise from termio.Exec.
For pointer lifetimes, the memory allocated is now owned by
DerivedConfig. When changeConfig is called, its the only time BOTH are
still alive, so we can safely swap pointers and deinit without having to
duplicate across threads. This is the same as renderer/surface.
Before this change I couldn't submit the dialog with return. Or
cmd+return.
From what I understand the problem was that the `TextEditor` always
steals the default focus. I tried a bunch of workarounds I found to set
the default focus on the button, but none of them worked.
Then I thought: do we even need a full-on Text*Editor*? So I switched
`TextEditor` to `Text` with a `ScrollView`: things look the same, text
is selectable and scrollable, but I can hit return to submit the dialog.
Fixes#1214
This introduces the `window-colorspace` configuration which allows
configuring the colorspace to use for windows on macOS. The default is
sRGB (same as before) but this can also be set to `display-p3`.
Fixes#1099
We previously applied application keypad mode logic (`ESC=` or mode 66)
whenever it was active. However, from looking at the behavior of other
terminals (xterm and foot) it appears this isn't correct.
For xterm, application keypad mode only applies unconditionally if the
keyboard mode is VT220 (`-kt vt220`). For modern terminals, application
keypad mode is only applied if mode 1035 is disabled.
Mode 1035 is the "ignore numpad state with keypad mode" mode. It
defaults to true on terminal startup. If this is true, keypads are
always encoded in numerical mode. If this is false, the numlock state
will be respected.
