Rationalize the flow of configuration updates.

[jcollie]

Right now when a configuration reload is triggered, the core App sends a change_config message to every apprt Surface.

ghostty/src/App.zig

Lines 145 to 148 in 3f715c2

	// Go through and update all of the surface configurations.
	for (self.surfaces.items) |surface| {
	try surface.core_surface.handleMessage(.{ .change_config = config });
	}

On GTK, Windows will have their updateConfig methods called multiple times (once for every surface contained in the window):

ghostty/src/apprt/gtk/App.zig

Lines 907 to 912 in 3f715c2

	.surface => |surface| surface: {
	const window = surface.rt_surface.container.window() orelse break :surface;
	window.updateConfig(new_config) catch |err| {
	log.warn("error updating config for window err={}", .{err});
	};
	},

This has not been a problem so far, but with trying to do more in the GTK apprt with the DerivedConfig model it could cause problems with extra allocs/deallocs, extra copying, and extra work by GTK as it processes the repeated changes.

The flow of configuration reloads should be rationalized so that duplicate work is not being done.

[mitchellh]

I want to think about this further, but I still believe this is a GTK apprt issue and not a core issue.

The App changeConfig says: change the configuration for the app and every surface. That's the semantics I'm specifically trying to achieve with that. For updating the config ONLY at the app-level, there is App.updateConfig. They're explicitly different, and designed to do what they're currently doing.

The change_config apprt message says "hey, the config for this target (app/surface) has changed, by the way." Triggering it on the app PLUS every surface makes sense, because the config did change in all those targets. If someone called updateConfig, then it'd only trigger in the app (because the surfaces didn't update).

What I think the issue is: I think GTK assuming a surface config update warrants a window update is a mistake and there's some config dependency binding there that isn't correct.

The behavior that I believe is correct: the window should apply app-level settings for things like window-decoration, SSD, etc. For title, colors, and so on, it should use the settings of the focused surface.

• When updating surface configs, the surface should derive any configs and the window may use those, but the window should only care if the focused surface changes configs (N=1 for the whole app).

• When updating app configs, every window should be reloaded, but Ghostty only triggers the app notification once, so this is no big deal.

In conclusion, I think the core flow of config updates are "rational" (as the title requests). The GTK flow of config updates are irrational.