Open unmellow opened 3 years ago
I agree, those are nice APIs to have :smile: . And I agree, those APIs really need a rendering or other UI API to discuss, which WASI doesn't yet have.
On the more general option APIs, this is something that interface types will help with. Modules will take functions and imports which will have types, and the types will enable applications to specify what kinds of configuration they can take.
Thought I should add that even if programs prefer to use library's for their GUI the Library itself could use the this preference API e.g. so the user sets dark theme and preferred don't once (one of my biggest problems with Linux)
An API for accessing User preferences such as
preferred font/fonts
light or dark mode
layout preference (mobile/desktop/tiling etc)
font size
these specific examples don't make sense without a rendering API
I believe an API like this can provide a compromise between developers wanting/needing to control their own render pipeline and users who value configuration.
In addition, apps wouldn't bundle their own configuration menu that could be entirely provided by the host even if the app has unique settings, it just informs the host of the names and types of options it takes.
And, the host could generate a configuration menu that contains the settings for every app on the host.
Now that I think about it, what I'm asking for is optional parameters with metadata, E.g., option name, APIs needed to comply a with setting, ETC. (so the user/host can tell what an option is)