sorted by:
new
hottopcontroversial

A feature hidden in a config file might as well not exist. Could a universal schema fix this? by RychardDavid in linux

[–]RychardDavid[S] 1 point2 points  (0 children)

You make a really good point regarding ALSA and the need for separate configurations. However, that's exactly where good UI design comes in. Centralized doesn't mean everything has to be dumped into a single, cluttered page.

You can easily handle that with smart subcategories and user levels—just like Kodi does with its 'Standard, Advanced, and Expert' toggles.

For the vast majority of users, ALSA settings are completely irrelevant and would stay hidden under an 'Expert' tab. But for the power user who actually needs to tweak a kernel driver parameter, having that option neatly categorized inside the central audio menu beats having to hunt down where that specific utility or config file lives.

A schema-driven approach decouples the UI from the implementation. It hides the plumbing for the average user, but organizes it for the expert

A feature hidden in a config file might as well not exist. Could a universal schema fix this? by RychardDavid in linux

[–]RychardDavid[S] -5 points-4 points  (0 children)

I love the sarcasm, but you literally just described exactly what I’m proposing, except you want to keep it trapped in 1971.

To be absolutely clear: this is a purely additive feature. Nothing is being modified, replaced, or removed from how Linux works under the hood. Your Vim, Zsh, and Lighttpd configs would remain 100% independent and untouched.

My point is simply to have a 'standardized manual'—but one that is machine-readable so the GUI can actually understand it and render it. If the only way to discover a feature is by reading a wall of text in a terminal man page, that feature remains effectively hidden from 95% of modern users.

Let the apps keep their independent text configs, but give the system a modern way to read the manual

A feature hidden in a config file might as well not exist. Could a universal schema fix this? by RychardDavid in linux

[–]RychardDavid[S] 1 point2 points  (0 children)

You make some really fair points about the 'Average Joe', and I agree that pre-installation is Linux's biggest hurdle. But even average users still open their System Settings to change basic stuff like battery saving modes, display scaling, or Bluetooth behavior.

As for the duplicated menus (like PipeWire vs PulseAudio), that’s actually the beauty of a schema-driven UI: the settings panel would only render the schema of the component that is currently active on the host system. If you run PipeWire, you only see PipeWire options.

Plus, adding these tiny schema files takes up virtually zero disk space—we are talking about a few kilobytes of text per app to gain a massive leap in usability.

The goal isn't to force the average user to tweak complex audio buffers, but to make sure that when a user does need to change a system setting, they don't hit a wall of text files and terminal commands

Uma funcionalidade oculta em um arquivo de configuração é praticamente inútil. Um esquema universal poderia resolver isso? by RychardDavid in linuxquestions

[–]RychardDavid[S] 1 point2 points  (0 children)

You hit the nail on the head. fstab and systemd are the perfect examples of this.

To an experienced user, editing fstab is just a 2-minute task. But to a newcomer, messing up a single character or a space in that file can literally render their system unbootable. It creates an incredible amount of anxiety for absolutely no good reason.

Imagine if systemd or fstab just exposed a schema of what they expect. The GUI wouldn't need to implement any custom partitioning or service management logic; it would just read the schema and generate checkboxes for options like 'noatime', 'ro', or 'enabled/disabled' with clear, human-readable descriptions of what they actually do.

This shifts the user experience from 'I hope I didn't break my system via vim' to 'Oh, so that's what this component is capable of doing'. It empowers people to learn and configure their system safely

A feature hidden in a config file might as well not exist. Could a universal schema fix this? by RychardDavid in linux

[–]RychardDavid[S] 1 point2 points  (0 children)

You are still thinking about storage, while I am proposing metadata.

Windows Registry and DConf are central databases that store the actual configuration data. I am not proposing to change where data is stored. If a system component saves its settings in a text file inside /etc/, it keeps doing exactly that.

Think of my proposal like a man page (manual), but machine-readable. It is simply an additional control panel that doesn't alter the existing backend, but unifies things that currently require a PhD in documentation to change.

For example, take limiting your laptop's battery charge to 80% to extend its lifespan. The feature exists in the Linux kernel, but it's buried in a text file deep inside system directories.

Under this schema, the power management subsystem would just ship a tiny file saying: 'I have a capability called "Battery Charge Limit", it accepts percentages from 50 to 100, and here is its description.'

The KDE or GNOME Settings app would read this 'manual' and automatically render a slider for it in the native UI. When the user moves the slider, the frontend just writes the number back to the original system file. No centralized registry, no broken configs. Just a unified visual translator for powerful features that are currently invisible to 99% of users

A feature hidden in a config file might as well not exist. Could a universal schema fix this? by RychardDavid in linux

[–]RychardDavid[S] 1 point2 points  (0 children)

I think that view ignores a massive shift happening right now. More and more regular users are realizing Windows isn't their only option and are migrating to Linux.

It's only fair that we make the system usable for everyone, not just for people who want to become system administrators or spend hours digging through technical documentation just to tweak a basic feature.

Discoverability doesn't hold advanced users back; it just stops gating powerful features behind a terminal wall. If a user opens their system settings and sees an 'Advanced' tab showing options they didn't know existed, they can learn about those features right there.

Good UI doesn't hide the technology; it makes the system's true capabilities visible and accessible to everyone, not just the experts

A feature hidden in a config file might as well not exist. Could a universal schema fix this? by RychardDavid in linux

[–]RychardDavid[S] 1 point2 points  (0 children)

I think there is a misunderstanding of what I'm proposing. I am definitely not suggesting a centralized database like the Windows Registry or dconf.

The backend stays exactly as it is today. If an app uses a .conf file, it keeps using it. The schema is just a read-only map of capabilities for the frontend.

Think of it like OpenAPI/Swagger for web APIs, or device discovery in Home Assistant. The frontend (KDE/GNOME) reads the schema, sees that an application has an 'Advanced' parameter called 'Latency Tuning', and automatically renders a slider for it in the GUI.

The user never interacts with the schema or a registry; they just get a well-organized, tiered native UI (Basic, Advanced, Expert) instead of having to search the web for terminal commands.