The case where the split if fully opaque (`unfocused-split-opacity = 1.0`) should result in the overlay being fully transparent (`opacity: 0.0`).
This would be consistent with how this is implemented in the macos app:
dcc492f19b/macos/Sources/Ghostty/Ghostty.Config.swift (L302)
The case when `quit-after-last-window-closed=true` and
`quit-after-last-window-closed-delay=null` was broken because control
gets stuck inside `g_main_context_iteration` and never returns to our
code. In that case add a 0ms timer that will return control flow from
GLib back to our code so that we can quit.
Fixes#2039
Instead of "polling" to see if a quit timer has expired, start a single
timer that expires after the confiugred delay when no more surfaces are
open. That timer can be cancelled if necessary.
This patch fixes#2010 by implementing `quit-after-last-window-closed`
for the GTK apprt. It also adds the ability for the GTK apprt to exit
after a delay once all surfaces have been closed and adds the ability to
start Ghostty without opening an initial window.
Left a FIXME where the "Copy" button action is disabled.
Though very hackish this was the best way I found to do this currently.
Disable sensitivity on the button didn't do anything and trying to
remove the button altogether like on macOS, causes the menu to become
really buggy. Either by the context menu turning into a scrollable list
or by it becoming really janky and showing the user pre-update UI.
In b7699b9a, mouse shape functionality was moved from the GL area widget
to the overlay that was newly created for the URL target information
that was included as part of #1928. This seems to have the side effect
of causing the pointer shape to revert to the default shape (here, the
basic arrow pointer) when dragging the mouse during selections.
This moves it back to the GL area, which seems to correct this. It
doesn't seem to need to be added to both - everything seems to function
correctly when a link is moused over, and then selection is made down to
the overlay area (not that this scenario is very likely, though).
When a split is created from a menu action, the focus is lost before the
split is made which prevents the surface from having the
unfocused_widget. Move the logic to add the unfocused_widget to the
overlay to an exported function which is called when the split is
created.
Refactor the GTK unfocused split code to use a GtkDrawingArea widget to
dim the unfocused split. The GtkDrawingArea is added to the overlay and
a CSS style is used to give it a background color and opacity. This
aligns with the macOS design of drawing on top of the surface. In GTK,
we don't need to actually draw a rectangle because we can apply CSS
directly to the widget.
Add a class to the GtkNotebook which holds our tabs so we can more
precisely set the background color of just this `stack`. A collision was
occurring with the menu widgets, which are also a `stack`.
For a long time, us GTK users have been subject to lesser UX by not
knowing which split was focused. Improve the GTK UX by implementing both
unfocused-split-opacity and unfocused-split-fill. This is implemented by
setting the background-color of the notebook stack, and conditionally
applying a new css class "unfocused-split" to the unfocused split.