My question is simple: instead of lshw, lspci - and hardinfo, is there any extension that actually parses these information and wraps within the gnome control center? If you have multiple devices, 4 or 5g modems, wireless, and more - simply Gnome shell doesn’t help if you need debugging, or find hw errors, or connected devices. Right?
When you “need debugging, or find hw errors”, you also often need to ask for help on a forum, post on the software’s git Issues, or create a bug report. All these work better if you can post text that can be indexed, machine translated, and searched. The POSIX shells provide a full range of tools to manipulate text that can help select relevant entries from logs, etc. While there are many users who have never used a POSIX shell and would benefit from GUI troubleshooting tools, it is important to think about the impact on the community if users rely too heavily on tools that don’t generate text reports suitable for posts in forums and bug reports. Any text reports would need to include the parameters used to generate the diagnostic text in a way that others could reproduce in a terminal. Current uses of images in this forum often (in addition to lack of support for search, translation, and indexing ) fail to capture the full error message, are hard to read on laptop screens, and vastly increase the number of bytes needed to convey information that only needs a few bytes of text.
I understand the concept that everything is accessible from the terminal, and many times the terminal much quicker tool to access information. But this is not what I talking. Situation is - would be great to know what driver is loaded/not loaded/not working within Gnome UI. It would be great to see my HW listed in settings, that actually works. Gnome settings only gives a limited access to setup in gui, eg. if I have multiple modems, or BT, or similar the gui won’t tell that witch one is used.
It is a feature of every gui app that what the user sees and can do is only what the developer has included within the app.
If you wish more to be included you must
Encourage the developer to add your desired functions.
Be ready for yourself and all other users of the same app to accept the necessary software bloat that always occurs when adding features.
The reason there are many many small single purpose cli commands is that each does its job simply and does so very well with very little code. A gui that does the same thing bloats the code by orders of magnitude, introduces the possibility of errors significantly, and makes the app less portable [in that it must also account for the OS where it is used (including the DE where it is running) – which is why apps on Fedora do not always work on Debian/Ubuntu and vice versa]. A gnome app may not work with cinnamon or kde and vice versa – thus adding to the maintenance labor costs.
Which leads to fragmentation of the community into distro “tribes” as well as a disconnect between GUI users and those who work primarily with command-line tools. GUI support for things every user will encounter is a priority, as it helps new users get up and running. Use cases that don’t apply to nearly all users are lower priority, and developer resources are in short supply.
One way to
is to provide a high quality patch. Even then, patch may go unused if the developer judges the increment in package size can’t be justified if it won’t be widely used.