This enables the standard effect created by a sytem tab bar, which
ensures unselected tabs blend with the window's/titlebar's background
color. This also ensures the `windowButtonsBackdrop` view matches the
color of the adjacent tab (be it selected or not).
In a light appearance there was a shadow cast on top of the inactive
tabs that looked bad. In a dark appearance the shadow manifests as a
solid line that required a faux border to look right. This removes both
and improves the aesthetics of the tab bar in light themes.
FAR from a perfect fix, as the background seen through the tabs during window drags will be behind by a frame or so still, but definitely a vast improvement over not updating at all.
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.
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#1227Fixes#1206
This moves the logic that respects `window-width` and `window-height` to
the controller window initialization. This is where it should've been
all the time but we previously didn't use a controller architecture so
we did our best to use heuristics in the view to do this.
This location now ensures that this only happens on window
initialization and only if we have one surface.
This prevents an unnecessary SurfaceView from being created. Creating a
SurfaceView is very expensive because this starts multiple threads,
creates the pty, starts the pty process, etc.
Additionally, this was exposing what I believe to be #497 when restoring
state: a surface view was created and destroyed very quickly causing
hangs on some machines. This still needs to be resolved but the behavior
in this commit was still a bug anyways.
