But why does it even make sense?
All you accomplish by insisting on creating 30-user.policy instead of modifying the 50- file is to effectively disable the GUI. Sure the GUI will tell you it has been disabled, but months later, will you remember that you deliberately did so, and how? Because the GUI won’t tell you WHICH file is overriding it.
OK, you (Zeno) might remember this…but someone else taking your advice might not.
You can use this thread: What would you like to see improved in Qubes OS?
Or create a new one within General Discussion category.
dom0 → /etc/qubes/policy.d/README
*start taking notes 
I took a look at the readme file in the policy directory. It says it is the directory that contains qrexec files, and to consult Documentation | Qubes OS. From there, it is all just a twisty maze of passages.
I’m sure there are cases where policy files are a better choice/have greater capability, but I’m happy to use the Qubes Global Config tool.
I see there is a nice Qubes Policy Editor tool as well, but I’ll stick with the config tool.
I can’t be sure because I’ve wiped out all my 4.1 stuff, but I suspect that file is unchanged from 4.1…in other words it was written before the 50-* policy files were even invented.
All I have basically done is find a way to automate changes that you could otherwise do in the GUI. (For example enabling/disabling the cacher.) Doing my automation on files numbered 30- would simply render the GUI powerless to do anything, since any changes the GUI makes to the 50- files would be overridden.
Almost everything I do is actually to files numbered 30-.policy (I have a LOT of these in fact) but in these two cases (USB and update proxies) there’s this new 50- series of files and I do not want to either override them or be overridden by them; I’m trying to cooperate with the GUI-based utilities and use the same schema they do.
I don’t recommend simply dumping other unrelated stuff into these files, by any means; only USB and Proxy related stuff. And I recommend extreme care and sticking with the format of the files.
All of that said, there is, I realized, one real reason to use 30-files for these cases, and that’s if you’re trying to test something out. If it doesn’t work, delete your 30- files and you’re back to normal.
BTW there is no reason your 30- file must be named 30-user.policy. I have a few policies in there but in most cases I create a 30-.policy file for related entries; it’s slightly more convenient that way when you’re managing them with salt. I have, in fact, five other files there whose name starts with 30- (And these are all policies that do not even exist on a default install; this is nothing a non-technical user need concern himself with.)
30-user.policy on my system is reserved for backups, opening links in a disposable, and opening files in a disposable (i.e., things the default system can do).
Screenshot of README:
For more clarity: Qubes Architecture Next Steps: The New Qrexec Policy System | Qubes OS and policy.d/README refers to non-existant 30-user file
For 95% if not more of all users, that’s the right approach. That’s why they created that tool in the first place.
I am not quite sure how we ended up talking about this on a “Usability for the non-technical user”
You can quote that until you’re blue in the face.
It won’t change the fact that it’s outdated and as others posted, leads into a maze.
The easy way was to use Qubes menu->Settings->System Settings->keyboard and add a shortcut to xfce4-screenshooter -r.
As a new user, I am not yet in a position to update what I don’t know how to do. I certainly can point out the areas that are no longer accurate. From my experience as a professional developer, the documentation needs the skills of a technical writer.
FWIW, if there was a QA person, they would have already have submitted tickets about all the issues in the documentation. Most like one that reads - “update documentation in all areas affected by changes to 4.2, but especially screen captures”.
@SteveC Usability encompasses the entire user experience of a product. Its about being able to use a product to get a task done. We’ve all bought products that have poorly written or incorrect instructions, and found the experience frustrating. In some cases, so frustrating we gave up and returned it to the store. I know that is what I did with Qubes 3.2.
In my case, being able to use an external mouse as opposed to the track pad of my laptop makes the laptop much more usable. For some users with mobility issues, carpal tunnel, etc. external mouse and or keyboard are not just nice to have but essential.
Sadly, when I initially installed Qubes, I chose poorly. (Raiders of the Lost Ark reference) I am very glad that Qubes allows me to change my mind (+ for usability). It was hard to discover where to make that change, either in the documentation or in this forum due to conflicting answers (- for usability).
I am doggedly working my way through issues. I’ll (re)read the docs, ask questions, try things. And hopefully I can give back to the community, either by documenting what I find, pointing out errors or omissions in the document, or maybe point out options that would make the use of Qubes easier for ALL levels of technical expertise. I’m sure there are plenty of folk that need better security but don’t have technical expertise.
This whole thing with mice and keyboards often makes an enormous difference. Most desktop machines these days require a USB keyboard and mouse; installing sys-usb the wrong way will basically lock you out of your machine. I am one of those who wants a mouse even on a laptop (it’s not a need in my case, but a strong desirement). Fortunately if sys-usb crashes or doesn’t work for whatever reason on the laptop I can run in degraded mode (keyboard + touchpad), long enough to make sure sys-usb doesn’t start up the next time I reboot. (It’s easy enough to do that, if you are in Qubes OS rather than stuck with a password prompt that doesn’t see your keystrokes!)
I’m very glad this is now controllable via a GUI (as are the update proxy settings). Doing things the old way is still supported but it will “break” the GUI. (And that’s great for right after an upgrade to 4.2–if you upgraded in place, the files that controlled it before are controlling it now and your settings don’t get lost. But that doesn’t mean it’s meant to be a permanent solution!) But I don’t think anyone wants to break the GUI long term.
I do a LOT of things on the command line, but when I can’t remember a command [and you’ll have noticed many command lines are arcane, and if you haven’t yet noticed you eventually will notice that a lot of things on a Linux system (not just on QubesOS) are configured in a file with God-and-Google knows what name, sitting in God-and-Google knows what directory], I like to fall back on a GUI. And I like to launch applications via a GUI, too, even if it’s just double clicking on a file or a shortcut. (I’ve set up a zillion desktop shortcuts to start qubes, run an app on a qube, and so forth.) But that’s me. I know of people here who will use a keyboard shortcut for absolutely everything; and others who are utterly dependent on a GUI.
I totally agree. I have used Emacs for decades, and I have muscle memory for lots of common operations. The rest I use the mouse and menu for, or lookup the Emacs command to run. I worked with another developer who swore by the keyboard shortcuts, and knew way more of them than I do.
I’m trying to be pragmatic with Qubes. If it is easy to customize it to make it fit my style of work, I will do it. If it is very hard, and I can work around the lack, I will. Worst case, I can switch over to my Windows 11 or Linux Mint laptops.
BTW, after enabling the mouse, I dug up a wireless mouse and dongle. The wire on the wired mouse was annoying to me. The wireless mouse works well, though I do get some “keyboard denied” warnings - I assume the dongle also supports a wireless keyboard as well.
The most customizable configuration of QubesOS is to enable KDE instead of the xfce desktop.
I came to QubesOS from xubuntu which uses xfce, so the default setup fit me like an old shoe, but the 4.1 menu was really unsuitable and that motivated me to look into KDE (which, I believe used to be the default, a few versions ago).
Here’s info to get you started should you decide to pursue this (and it can be undone):
The update to the XFCE menu in 4.2 made it a lot easier to work with. There are separate sub-menus for accessing specific qubes vs system-wide (dom0) actions, and the qube submenus are divided into 3 tabs for AppVMs, Templates, and Services (sys-*).
Not trying to dissuade you from KDE, I just think this is worth mentioning as it improves “usability for the non-technical user” on a default installation. 
@SteveC I am not ready to change window managers. I’d rather stick with the stock one since:
a) it is stock
b) it is what is shown in the documentation (more or less)
c) an easy solution to my issue was available that didn’t require the larger change
In addition to my personal interest in Qubes, I am also writing for a class I am taking (for fun) where I plan on evaluating the Qubes experience out of the box. I.e. how easy is it to work with, configure, customize, etc. I think a window manager change would be a higher bar for many users, esp. ones coming from Windows.
@skyvine - definitely agree. The less changes a new user has to make to become productive, the higher the usability in my opinion.
That’s entirely true, and I am glad you brought it up.
When I upgraded my laptop to 4.2, switching to KDE was the very last thing I did after a few iterations before I felt like I had automated all my customizations, As such I got re-acquainted with xfce and got to use the new menu. It was a vast improvement over 4.1!
It didn’t do enough for me, because it didn’t make some distinctions (like between templates and disposable templates) that I want made. Also, I’m one of those oddball types with dozens of VMs and I need more granularity.
But it was a HUGE step forward even so.
Trying to get everyone onto KDE whether or not its best for them certainly isn’t my goal, but I certainly do think that some users may find it more usable. So I mentioned it.
Agreed for your purposes KDE wouldn’t be a good thing. In fact, I hesitate to demo Qubes to people, because my system wouldn’t look recognizable as compared to the default installation–I’d be showing them something they won’t get. (Maybe I should install, bone stock, to a thumbdrive/memory stick for “live boot” purposes. In fact, that’s how I demoed it to myself…the first machine I tried to install 4.1 to, the installer and QubesOS itself couldn’t see my disk drives. I ran off a thumb drive long enough to know I wanted this enough to justify buying a new machine to put it on.)
Does the attack surface increase using KDE?
Thanks for replying