Create "Q Manager" consolidation of some existing and one future Qubes-specific applets

[ninavizz]

The problem you're addressing (if any) There are more disparate "applets" to manage and setup things in Qubes, than is common in Windows, other Linux, or Mac systems. As such, discoverability of sought functionality can be tedious—and other less-than-optimal experience things.

Describe the solution you'd like "All Things" with regards to setting-up and doing the day to day within the OS of a computer, can fall into a 3 or fewer topical mental models of functional "buckets." My macro-recommendation, is to discern what those bucket are—and to consolidate applets accordingly.

Within that, I have identified "Settings" functionality and "Management" functionality. For "Settings" I put together this concept—which I do not advocate ever being built (which I put together before learning it would require marrying XFCE, which nobody wants).

For things that are more than "Yes/No/Enable/Disable/Option-3/etc" binary options, "Management" feels like a fitting bucket.

• Qubes Manager (with today's Template Manager functionality folded in)
• Updater
• Backups Manager (today's Restore/Backup tools, combined)
• Policy Manager (GUI yet to create, but it'll need a home once created)</strike.

Where is the value to a user, and who might that user be?

• Surface functionality that is currently buried in disparate applets one must open and have task-mandated curiosity to learn about.
• Create a single tool across which multiple updates can be made w/o mandating extensive testing of each minute applet
• Fewer things to navigate in a dropdown (the many applets) makes everyone's life happier

Describe alternatives you've considered

• More applets.
• Longer dropdowns
• More silo'd functionality that is difficult to discover

Additional context The idea for this came about with the need for a GUI to manage Policies. It felt silly to create Yet Another Applet, so I got the idea for this.

Related, non-duplicate issues Probably.

Early concept sketch to demonstrate the broader container

• Existing applets can be embedded as-is within this UI framework
• A library of standardized UX patterns and UI things can also start to be built, from this—and carried-over into newer functionality.
• Yes, explorations have been done to improve the design of today's Qubes Manager, but to keep this issue focused I am intentionally putting a screenie into this that uses the existing Qubes Manager UI.

[ninavizz]

Note: This is definitely something NOT for 4.1. Yes, I've been on a bit of a tear today, with "omg 4.1 priorities as reflected in issue milestones must be quelled!" lol.

[andrewdavidwong]

Historical context: https://github.com/QubesOS/qubes-issues/issues/2132

The pendulum is swinging back the other way.

[andrewdavidwong]

What's the difference between this issue and #5679?

[ghost]

xfce4-settings-manager provides a basic place for users to go to find all xfce4 related settings. Perhaps we could add qubes tasks to that? The arandr package already seems to be able to add itself to the menus. Usability wise a hub for all settings is useful, but technologically it is much easier to maintain a set of individual tools than a monolith. For now simply adding links to xfce4-settings-manager looks like the simplest path to a more usable hub for qubes related settings. An ideal solution (but would require extensive extension of GUI tools) would involve each competent being its own gui, then having a settings application that can have the competents rendered inside of it rather than as separate windows (like in your wonderful render). Thanks for your continued effort to make Qubes more usable!

[ninavizz]

What's the difference between this issue and #5679?

This issue is specifically to consolidate the custom Qubes tooling for Qubes Manager, Backup Restore, Backup Manager, and Qubes Updater, all into a single UI framework. So—in theory, Qubes Manager could remain "as-is," to fulfil this issue's ask; it would just show-up in a tabbed pane with the other tools also accessible in that pane.

5679 is to redesign the presentation of information and functionality within Qubes Manager itself. Does that make sense @andrewdavidwong? Two totally different projects, but for two end-goals: one, a maturation upon the other.

Yes, I appreciate that it's easier to maintain a bunch of disparate applets. It's an awful user experience for end users, however; especially less technical or non-CLI users, needing a system such as Qubes to mitigate security threats.

@ctrlaltf24 XFCE may be getting moved-away from, at some point. It also requires users to know what's specific to XFCE, vs other projects/vendors. Likewise, it's consolidated pane still is just a launcher for multiple applets. It's the latter, that's more disruptive; the back-and-forth and back-and-forth to find a switch to do one thing. Again, I realize they all do that for ease of maintainability—but it's an awful experience for end users.

[ghost]

I looked at Windows/KDE/GNOME/XFCE to see how they managed their settings. Generally they fell into two camps, either monolithic or applets with some sort of hub. Windows has two monolithic structures, sometimes opening applets depending on the setting. GNOME has one monolithic settings application (that looks much like the one you mocked). KDE has many different applets that can be viewed from within the main KDE settings application (that looks much like the one you mocked). XFCE has a combination of first party applets and third party applets, all accessible in their xfce4-settings-manager. If it is a first party, it will switch to that view, if not it will just open the applet in a new tab.

in the pattern of the xfce environment, integrating with xfce4-settings-manager makes the most sense than making a monolithic settings application. xfce4-settings-manager is not ideal from a usability standpoint, but adding Qubes entries to it would be an improvement. This mainly solves the discovery problem of finding Qubes tools. Below is a screenshot of Qubes related tools added to xfce4-settings-manager. New entries can be added by modifying /etc/xdg/menus/xfce-settings-manager.menu and qube's .desktop files without marrying to XFCE4.

I'm not sure which repo you want these changes in (specifically steps one and two). Technical steps to accomplish the above:

1. Add a new section to /etc/xdg/menus/xfce-settings-manager.menu called Qubes xfce source repo
2. Create another desktop-directory called /usr/share/desktop-directories/qubes-settings.directory in the pattern of /usr/share/desktop-directories/xfce-system.directory
3. Add Settings;X-XFCE-SettingsDialog;X-XFCE-QubesSettings to the Categories section of Qubes .desktop files.

Thanks in part to https://arcolinux.com/how-to-add-shortcuts-to-xfce-settings-manager/

[ninavizz]

The experience of opening a million applets to find one small piece of functionality, is dreadful for users new to Linux (or users who simply want to spend time getting their work done, vs learning about their computer). It is also not common for a user to know which "tool" they want; it is, however, common for a user to know the thing they want to work differently on their computer. The above does not solve for the core discoverability problem of functionality.

While I appreciate it is easier for developers to make and ship small applets, that makes for a dreadful and non-intuitive user experience. More broadly however, to have success at using Qubes, non-technical users need to get their heads around the mental models of what it means to have a compartmentalized system. When functionality is buried in disparate applets, it requires the user to "think" too much, while also leaving-open the door to overlook things too easily—or to fail to "connect the dots" between... say, how policies work and how one should manage their ecosystem of qubes.

If this isn't a priority, it's not a priority. But, the consolidation into a single UI framework will make for a far more intuitive and holistic overall experience. Also hoping to get user feedback on this, in the App Menu testing sessions.