GUI preference pane

[haze]

I'd like to contribute a native preference pane for Ghostty. I'm only comfortable with working on the macOS variant of this feature, so I'll only be commenting on preference panes native to macOS, but I want to make it clear that this issue can also be used for discussion around other windowing systems and their respective UX/UI guidelines.

macOS

macOS has moved away from the older preference pane style to a newer, iOS-esque style sidebar navigation view. Personally, I'm indifferent, but I find discovery to be calmer in the previous iteration.

Pre macOS Ventura	Post macOS Ventura

I'd also like to drop some inspiration from some other cool Mac apps:

Nova

Main preference pane	Child view

CodeEdit

Terminal.app

My questions are:

• Which preference pane style should Ghostty adopt?
• Are there any configuration elements that require a richer set of inputs than the standard methods defined in SwiftUI?
• Would it make sense to stay native to each platform, or have a window that shares its layout across all desktop environments?

[mitchellh]

This would be very helpful! I'm sure you'll run into some limitations of the Ghostty C API, but I'm happy to help with those as you run into them. Your questions:

Which preference pane style should Ghostty adopt?

I like Nova's.

Are there any configuration elements that require a richer set of inputs than the standard methods defined in SwiftUI?

Probably, but you can just focus on the easy ones to start. When we get there we'll figure it out.

Would it make sense to stay native to each platform, or would it make sense to have a window that shares its layout across all desktop environments?

Nah, let's make it native per platform. These things tend to have very different idiomatic feel per platform.

[kjvdven]

It takes more clicks for the Nova's design to switch to another section.

[goonzoid]

Thanks for pulling together some examples from a few different apps / styles. It'll be helpful for discussion.

I want to take a small step back and ask a different question: should Ghostty even have a preference pane? For me, text based configuration is a huge selling point for an application. Before Ghostty I was an iTerm2, Alacritty, and (briefly) Kitty user, and I much preferred the experience of configuring Alacritty and Kitty in text, compared to iTerm2 in the GUI. I don't think it makes sense for every app domain, but terminals are inherently text based, so it feels like a good fit to me.

Of course I can see the other side of this argument. For configuring colours and themes in particular, there's no doubt that a well designed GUI can provide a richer experience.

Maybe we can have the best of both - a preference pane as an interface for editing a plain text file?

One other thought more directly related to your initial question: I think @mitchellh had mentioned the idea of web based configuration at some point. Obviously the cool thing about this is that it can easily be completely cross platform. EDIT: Mitchell clearly types faster than me. Seems like the native per platform approach is favored (and I don't disagree).

[mitchellh]

I think a graphical preference window is desirable. Its something I'd like to see. But that doesn't mean doing away with the text-based config, either!

Maybe we can have the best of both - a preference pane as an interface for editing a plain text file?

I think this is worthwhile and in line with what I was thinking.

The way we do parsing of the text file right now it'd be a pain to preserve whitespace and comments in order to rewrite it. I think we should instead go with a priority approach, something like: GUI takes priority over the XDG file at ~/.config/ghostty/config. This way, we never overwrite a user's text config.

We store the GUI config in NSUserDefaults (or something). The reason I want to use NSUserDefaults is for iCloud syncing. I think it'd be a really nice value-add for GUI-based configuration for macOS to automatically sync between all devices, in a way that the user owns all their data (i.e. we don't have to run any service -- which is always going to be a hard no for us).

The exact value stored in NSUserDefaults can be an "encoded" ghostty_config_t (we need to add an API for this), but since its owned by the GUI, we don't need to worry about preserving whitespace or comments. We'd only write values that differ from defaults.

This is where we'd load it: https://github.com/mitchellh/ghostty/blob/e11d737a80f570488a87d0b9a635b318904b9252/macos/Sources/Ghostty/AppState.swift#L130-L132

[haze]

Thanks for pulling together some examples from a few different apps / styles. It'll be helpful for discussion.

I want to take a small step back and ask a different question: should Ghostty even have a preference pane? For me, text based configuration is a huge selling point for an application. Before Ghostty I was an iTerm2, Alacritty, and (briefly) Kitty user, and I much preferred the experience of configuring Alacritty and Kitty in text, compared to iTerm2 in the GUI. I don't think it makes sense for every app domain, but terminals are inherently text based, so it feels like a good fit to me.

In my mind, the preference pane would be an alternative editor for the text based configuration file; it would load it's configuration from the same text file you can edit on disk and save changes to that file as well. This unfortunately means that after using the preference editor, defaults are exposed explicitly.

I think a GUI preference pane not only helps with configuration discovery (beyond parsing the config struct as noted in the READMEs) but also ease of use. It's probably much nicer to see the color you're editing in real time without relying on shell/editor functionality to preview the hex.

Fig also has a cool preference pane where they have a video demonstrating the outcome of your settings, which makes understanding what you selected easier. I like that feature a lot.

[goonzoid]

I think it'd be a really nice value-add for GUI-based configuration for macOS to automatically sync between all devices.

For sure, that's a killer feature (when iCloud syncing works as it's supposed to 😬).

GUI takes priority over the XDG file at ~/.config/ghostty/config.

Agree in principle, but slightly scared that this could end up feeling a bit opaque or hard to manage, and lead to very frustrating "why isn't my config being applied?" type moments. Not advocating against it, but just calling out something I think it's worth being thoughtful about if we have multiple config sources. Your comment about only writing values that differ from defaults goes some way towards solving this, but I think we might also want to do something to make it very visible to user which values are being stored in user defaults.

[mitchellh]

Merging in #1032 here. I know this is about a GUI pref pane but I think including this suggestion as a first step or even alternate option for some people makes sense.

Currently the Settings menu item on MacOS is greyed out and the shortcut cmd+, does nothing.

We could implement the open settings menu item and shortcut to open the settings file with the default system editor.

An example on which to base the implementation could be Kitty, which already has this feature.

[erf]

I find the CodeEdit design quite nice - and maybe we should adhere to the new macOS design style, like using the sidebar, to be more future proof?

I'm not sure if the design guideline forces this type of design but there is some more information in the video at Adopt the new look of macOS and at Settings.

I find the text based XDG config file nice. I have it in a "dotfile" type git repo and it's easy to change and push changes. I like the idea of a native GUI based settings view as well, but i rather it don't interfere or override my text configuration if possible. Maybe the GUI window could read the XDG config on open and save to it again, preferably, without messing up the file too much, and that iCloud sync could be OPT-in ? Maybe this would be difficult with the current file and another file format would be more suitable. VSCode uses a JSON file which might be more suitable and cross-platform. Although, less human-readable it might be a good balance for both machines and humans (although i do like the TOML format). The settings would have to be converted between native macOS format (NSUserDefaults?) and our text format in order to be synched.

[clebs]

I would be up to try to build the file opening option which can be expanded upon as the proposal evolves.

I do not have experience with swift, but as mentioned in my duplicate issue, Kitty does it that way and would serve as reference implementation.

[clebs]

I have been delving into the code and think I have a grasp on how to add actions to the different runtimes and bring them together in the platform independent core (+ Bindings).

@mitchellh would it be fine to give this a try on Mac OS first and subsequently on Linux and Windows?

I also was thinking if it would be worth it to add an editor config field that would allow to tell Ghostty which editor to use in actions that require it (similar to how it can be set on git). Default would always be OS default editor.

[mitchellh]

Yes, feel free to take a stab at it! I'm open to this functionality.

EDIT: And yes, it's okay if it only supports one platform to start. Don't worry about Windows, yet.

[clebs]

Just added the first step for the preferences feature on MacOS here #1116. This enables the settings menu item and binds the given shortcut to it (cmd + ,). It is implemented as action, so it can be used in the config file with another binding if desired as open_config.

In the future this action can be recycled as a button on the preferences panel being discussed here.

I will next add the linux shortcut and menu in the same way next.

[gwww]

Reading through the comments here, it seems there is interest in keeping both config file and GUI. I'm assuming only one of the two configs would be used at any one time. Is it something such as if a config file exists, use that. If no config file exists assume its the GUI?

Like some others on this thread, I'm partial to config file that is a part of my dotfiles repo.

[rnpatel]

I would hope that it's not either-or, but rather a preference pane that reads and writes the configuration file.

[JoshuaBrest]

I'm working on this now. These are my thoughts

[kjvdven]

In the examples, for new mac os and code edit, the search is in the left side bar, probably so that it won't scrolls along.
Is the top of the right panel fixed? I assume it is.

[JoshuaBrest]

@kjvdven It is part of the "toolbar"

[mitchellh]

See this too: #2354 (comment)

[mitchellh]

I want to note that to ease long term maintenance, we have an opportunity to potentially programmatically generate the UI, especially with SwiftUI. We already generate a Zig package help_strings that we use to automatically generate our man pages, markdown, HTML, etc.

I don't think that has enough information today but we can expand on that to provide types, options (enums), etc. And from there we can probably expose it via the C API (libghostty) that macOS uses. Using this we can probably use Zig to generate enough rich information as needed by libghostty consumers to generate a settings view.

[lucanos]

I'd suggest having a look at Tabby.

It has a GUI for setting preferences, but the preferences are read from/written to a JSON config file. So you can manually change the JSON file, or you can make changes via the GUI.

Having the config file also means you can sync the file between machines (even across OSes) so you have the same settings/accounts/stored credentials everywhere.