This is based on our conversation on Discord and adds a setting for GTK
that allows disabling the GTK single-instance mode.
If this is off, it's possible to start multiple applications from the
same release binary.
Tested like this:
```
$ zig build -Dapp-runtime=gtk -Doptimize=ReleaseFast && ./zig-out/bin/ghostty --gtk-single-instance=false
[... starts new application ...]
```
and
```
$ zig build -Dapp-runtime=gtk -Doptimize=ReleaseFast && ./zig-out/bin/ghostty --gtk-single-instance=true
info: ghostty version=0.1.0-main+42a22893
info: runtime=apprt.Runtime.gtk
info: font_backend=font.main.Backend.fontconfig_freetype
info: dependency harfbuzz=8.0.0
info: dependency fontconfig=21400
info: renderer=renderer.OpenGL
info: libxev backend=main.Backend.io_uring
info(os): LANG is not valid according to libc, will use en_US.UTF-8
info: reading configuration file path=/home/mrnugget/.config/ghostty/config
info(config): default shell source=env value=/usr/bin/zsh
(process:49045): GLib-GIO-WARNING **: 13:55:56.116: Your application did not unregister from D-Bus before destruction. Consider using g_application_run().
[exits]
```
This is part of #319 by fixing it for GTK and introducing the
configuration option.
This adds `window-decoration = false` as a possible configuration
option. If set to `false`, then no window decorations are used.
Fixes#290
Previously, our io_uring loops were exiting on EINTR. EINTR is sent for
various reasons but particularly when a process is stopped such as for
sleeping. We should not exit these loops.
Longer term we should be more resilient to detecting that our renderer
and/or IO thread as died and behave in some better way but this
addresses a major issue in the mean time.
Fixes#366
The comment in the Swift code explains what was happening here:
> I don't know if this is the right place, but because of WindowAccessor in our
> SwiftUI hierarchy, we have a reference cycle between view and window and windows
> are never freed. When the window is closed, the window controller is deinitialized,
> so we can use this opportunity detach the view from the window and break the cycle.
An alternate solution would be to make our reference back to the window
"weak" but we appear to not be able to do that with SwiftUI property
wrappers such as `@State` and `@Binding` and so on.
This is a weird one. By using intCast on the `idx` I am periodically
getting a panic on index out of bounds where the index is larger than
FontIndex can possibly be. Very strange!
I tried to just remove intCasts and believe it or not that worked.
Previously, `cat /dev/urandom` would trigger the issue in seconds and
now I've had it running 20+ minutes without the issue.
The additional `if` check is just a safety mechanism
