As evidenced by my recent flurry of support-related posts on the forum, I’m new to using qubes as a “daily driver”. Very appreciative of those who have assisted me with these. Such a great community
I’m now starting to add some custom key bindings and custom scripts to dom0 and have reached a state where much of my regular tasks feel natural
There are still some UX issues that I think are essential but not currently implemented. Right now, these are primarily features of the Qube Manager
I would like feedback on some suggestions I have. Are these features things only I would use? Am I using anti-patterns? Am I missing an already existing equivalent solution? Do I need to not be so needy?
Or, are some of these things planned, or “wontfix” items?
I saw a large thread sort of similar to this here but it’s several years old and very long. Hopefully I don’t rehash anything that was settled there
I don’t want bells and whistles within the Qube Manager. I appreciate and prefer simplicity, generally speaking. And I recognize there are much more critical focus areas for development with more substantial impact on UX and core functionality. But, I’ll mention a few of the basic things that seem useful but conspicuously absent…
Grouping qubes by arbitrary user tags or some other attribute, specifically making the groups collapsible rather than simply sorting them. I have well over 20 qubes and using the simple sort by column feature is very limited when it comes to managing many qubes from a GUI
Having a “notes” tag or attribute that is accessible/visible in the qube manager that can contain simple free text. Perhaps for documenting something unique about the qube where applicable. For now this information goes in a text file. Having an optional column or context menu to view/edit these notes would be great (for me, at the moment…)
Similar to item 1, and I suspect this might exist- a way to mark a VM as dependant upon another. I see this already exists implicitly when there is a netvm relationship- sys-whonix will start when a whonix-workstation or gateway starts for example. Is there a way to set an arbitrary number of qubes as dependent? Sort of like “teams” of qubes. This can quickly become an anti-pattern- “if they depend upon each other, why not have one appvm with docker for each app rather than multiple dependent appvms?”. The example I would use here is the split wallet, where one may want monerod and monero-gui as separate appvms. Monerod uses sys-whonix as its netvm, but there’s no such relationship between monerod and monero-gui- so manually starting the gui requires explicitly/manually starting monerod. Another example would be a samba or NFS qube that provides limited file sharing between a few VMs that, for whatever reason, aren’t appropriate with the weaker separation provided by docker or another namespace-based solution
I’ll reiterate that I’m still very new to qubes. I don’t expect any of these to be ideas with widespread appeal. Maybe the best I can hope for is suggestions about functionally equivalent solutions that don’t burn development time
As someone who had some contributions to to Qubes Manager, I may provide some feedback:
There are 28 open issues on Github labelled as “c: manager/widget”, “t: enhancement” and have the word “Manager” in the title. Some of them might address your needs. It would be nice if you could spare some time to review them to see if they already cover your requirements. Otherwise, new issues could be opened or comments to similar existing ones could be added if needed.
Having said that, those issues alone do not mean that they would materialize. Some of them are old and considerably big projects which need a lot of time and resource. The Qube Manager is relatively old compared to the other GUI tools. It was written in PyQt whereas the new ones are mostly written in PyGTK. Two complete different libraries. The number of developers is scarce.
Sharing ideas with community is very good. Since it allows brainstorming with other users to come up with a suggestion which addresses requirements of many users.
Thank you @apparatus for the reference to the free text issue, that in particular sounds very similar to what I would like
Thank you as well @alimirjamali for the reference to the Github issues in general and the folders issue. I should have stated that I did search for some of the keywords in the issues before posting and saw what you described, which is dozens of issues with no immediately clear indicator of what their status was. Some can be followed, some are barren. Some appear to be dead. This was discouraging. It’s not like projects I typically contribute to or participate in, and understandably so given Qubes is an entire OS, not a library or application. I will recalibrate my expectations a wee amount
Ok, ok, I will stop rambling, just to say that it wasn’t my intention to suggest others spend time reading those issues on my behalf, I was more hoping someone more active or with a longer background in the project would offer a candid summary. Though I could have been clearer about that. Luckily I think I received that anyway
What you have provided is helpful and I think I need to (as you suggested) spend more time following the issues to understand the pace of development and the priorities. I’m still lacking a fundamental understanding of those things (as well as how Qubes is most substantially funded, and to what degree) but I am going to guess I can find more
on the site about that
