I'm not sure how feasible it would be, but perhaps writing iced backends for native toolkits of a platform (qt, gtk, etc.) would work? I know druid supports native platform toolkits so it should be possible.

Let's say that I have an OS, and I want to build that OS around a toolkit that isn't GTK or Qt. I'm already using GTK for building applications in this OS, but I want to see if there are better solutions that I could use should I want to transition away from GTK. So what I want isn't to use a toolkit that has a reliance on GTK or Qt, but a toolkit that I can use as an alternative to them. But that would require that such theoretical toolkit supports defining system themes.

Ah so you mean as in, say, something like a "theming backend", which could perhaps support using GTK themes, or Qt themes etc.?

Having something like /etc/iced/settings.{ron|toml} that supports defining a theme by name, and having themes placed in /usr/share/themes/{NameOfTheme}/iced/, using whatever format works best for iced. This way, if I develop an application for this OS, it would use the system theme by default, but users could change the system theme to one they created. Applications could extend the theme or opt into their own custom theme at the application level.

I guess to be clear, support for GTK and Qt themes is not something I'd expect. Instead, a theme format specific to Iced. I don't generally think it wise to try to guess color schemes and layouts from a GTK theme.

I think it sounds like a good idea! I am not happy with our current default theme. This would be part of the efforts to improve it.

We could make iced search for user settings to obtain the default theme, instead of using the currently hardcoded one. For this, we would need to change the widgets slightly and pass the default theme around when rendering, since it will be chosen at runtime during initialization now.

Where are the hard coded values? I am willing to try and make a draft for this functionality.