gtk: add GSettings support for window state persistence

[evertonstz]

Implement GSettings to save and restore the window size in terminal grid dimensions on Linux. Include the necessary schema and update the application to handle window state management.

My solution is similar to how ptyxis does it in gnome.

[evertonstz]

By setting the initial value to (0, 0) we allow the terminal to first lauch with the default size, on close we will replace the (0, 0) with the default size (110, 25) or the current size, if the user resized his terminal in this first launch

[evertonstz]

For package managers this should be handled automatically, but the AppImage maintainer will probably need to run glib-compile-schemas when packaging.

[evertonstz]

Fails gracefully if the GSettings schema is not present (ex: appimage maintainer forgot to compile), in the failure case Ghostty will just have its current behaviour of not restoring or saving its size!

[pluiedev]

Looks good overall

[pluiedev]

This should be something we can do within the Zig build system. Meson does it automatically, for example.

[mitchellh]

Looks good generally. Some questions that I plan on researching myself, but feel free to provide some color as well to help me:

1. How does versioning work? In macOS, it's standard to put a "version" monotonic Int into the settings schema so that you can provide upgrade paths or ignore unknown versions. This also lets you change structure. Do we need that here? Seems like we would but I'm not sure if GSettings provides another way.

2. I think the compiled schema is something we'd want to put in our dist tarball and it doesn't look like we're doing it here.

3. Not required for this PR: but is there any way we can localize the description string? Asking since we already localize many other things in GTK.

[evertonstz]

Looks good generally. Some questions that I plan on researching myself, but feel free to provide some color as well to help me:

1. How does versioning work? In macOS, it's standard to put a "version" monotonic Int into the settings schema so that you can provide upgrade paths or ignore unknown versions. This also lets you change structure. Do we need that here? Seems like we would but I'm not sure if GSettings provides another way.

As far as I am aware GGSettings does not have a built-in, automated schema versioning mechanism with explicit version numbers in the schema files themselves, instead they are managed via some best practices to make or life easier:

• Adding new keys as optional, mark old unused keys as deprecated;
• Avoid rename, changing the type or removing old keys;

In case of breaking changes:

• Ship both schemas
• Add a migration logic that will check if the old schema still has user-set values. If so, read them and write them to the new schema's keys, then reset the old keys to their defaults (or remove them).

eg:

<!-- Old key - deprecated -->
<key name="window-size" type="(uu)" deprecated="true">
  <default>(0, 0)</default>
</key>

<!-- New key with different structure -->
<key name="window-state-v2" type="a{sv}">
  <default>{}</default>
</key>

Kinda of a pain in the ass if you ask me, but its the gnome way :<

2. I think the compiled schema is something we'd want to put in our dist tarball and it doesn't look like we're doing it here.

If making glib-compile-schemas a build-time dep is not a problem, I think we can do it, but package managers typically handle schema compilation automatically via post-install hooks and we are already shipping the schema source, so that can be an option too, if we keep it as it is we would probably just need to update in PACKAGING.md that package managers should run glib-compile-schemas post-install hook and we should be fine. I think its a common practice to do that.

3. Not required for this PR: but is there any way we can localize the description string? Asking since we already localize many other things in GTK.

Yes! GSettings supports localization using gettext:

• Mark translatable strings with underscore, eg: <_summary> and <_description> tags
• Extract strings to the .pot file
• Translators add them to .po files
• GSettings automatically uses localized strings at runtime

eg:

<?xml version="1.0" encoding="UTF-8"?>
<schemalist gettext-domain="com.mitchellh.ghostty">
  <schema id="com.mitchellh.ghostty" path="/com/mitchellh/ghostty/">
    <key name="window-size" type="(uu)">
      <default>(0, 0)</default>
      <_summary>Last window size</_summary>
      <_description>
        The last window size in terminal columns and rows. This is used to
        restore the window size when window-save-state is enabled. A value
        of (0, 0) means no size has been saved yet.
      </_description>
    </key>
  </schema>
</schemalist>

The strings will show in English until translations are added. If interested I can update the PR to let the schema ready for translation.

Thinking better about it, it is not that simple because I will actually need to convert the xml to a template to fill in the schema-id via build time from the current build_config.bundle_id, it is possible but I will need to thinker with it a bit more to get to a viable solution :>

[evertonstz]

3. Not required for this PR: but is there any way we can localize the description string? Asking since we already localize many other things in GTK.

I managed to get translations working for the GSchemas, but it needed some changes in how mo files are generated, I made a draft PR at #9464 using the current PR as base, so it can be reviewed after we merge this one.