For anyone who wants to use suckless’ dwm and having it display qube name, windowborder colors, etc.
Here: GitHub - 3o14r473/GUIDE_how-to-install-dwm-in-qubesos: How to install suckless' dwm in QubesOS
For those who want to take a look at the patches:
/patches/qubesdecorations lets dwm display the qubename, color the windowborders of the focused window accordingly, etc.
/patches/qubesrules lets you use label and qubename in dwm’s rulematching.
1 Like
Fans of dwm or other tiling window managers like i3wm and awesome might be interested in qmenu.
1 Like
Any other patch that can improve the experience?
Regarding the QubesOS experience, I recommend the fakefullscreen patch, as mentioned in the guide.
Besides patches, everything else mentioned in the tips and tricks section of the guide drastically improves the dwm-in-Qubes experience.
Some personal recommendations that might be worth a try for some:
I use the dwm rules to assign every qube label its own (dwm-)tag; spawning windows on a specific tag, depending on their qube’s label.
As it is possible to view multiple tags at once and because they can be quickly toggled on and off, it provides me with a very smooth and dynamic workflow.
Example:
/* label qube class instance title tags mask isfloating monitor */
{ 1, NULL, NULL, NULL, NULL, 1 << 0, 0, -1 },
{ 2, NULL, NULL, NULL, NULL, 1 << 1, 0, -1 },
{ 3, NULL, NULL, NULL, NULL, 1 << 2, 0, -1 },
{ 4, NULL, NULL, NULL, NULL, 1 << 3, 0, -1 },
{ 5, NULL, NULL, NULL, NULL, 1 << 4, 0, -1 },
{ 6, NULL, NULL, NULL, NULL, 1 << 5, 0, -1 },
{ 7, NULL, NULL, NULL, NULL, 1 << 6, 0, -1 },
{ 8, NULL, NULL, NULL, NULL, 1 << 7, 0, -1 },
Other than that I would not want to do without qmenu.
Regarding this, although it is not qubes-specific, I highly recommend the center and border patches for dmenu.
qmenu-am --focused is very useful to me, as is qmenu-vm (especially qmenu-vm --focused). Not only does it replace my need for the Qube Manager but I totally rely on it for very unspectacular things like per-qube note-taking. Managing QubesOS can be very time-consuming and I absolutely do not want to use the default tools for that.
I want to add that this is because of my personal preference and that I do not think bad of the default Qubes desktop experience. On the contrary, the Qubes Team has done a wonderful job on improving it just recently. Without downplaying the great contributions of the others involved, I am very happy that ninavizz got involved as, so far, she has made some excellent improvements regarding this.
Of course, for musophobic users like me, dwm+qmenu is just a more fitting solution.
The Qubes Desktop experience is terrible. I have to say that this is not a Qubes specific issue, but more of something for all Linux users. If I was going to design a new Qubes like OS(or a new Linux OS), one of the important things for me would be a good UI (of course after security) with a macOS like UI (I still like WM’s, but 90% of the people find it very easy to use) and better integrations overall with other VMs(to the point is impossible to find out). I know that doing something like this is impossible for the small team at Qubes.
Related to DWM, I decided to not test it since I would like something that needs fewer workarounds to get it working properly(Even on a normal Linux distro, it is a pain to set something at the same level that other WM’s can provide)
With its plethora of desktop environments to choose from, what are you missing in Linux?
If you are looking for a more “feature-rich” experience, maybe kde, i3, or awesome are worth a try.
What are the prospects of dwm getting supported by QubesOS (similar to how i3 is supported) in the near future? I would like to avoid doing that workaround of compiling in a domU and carrying the binaries to the dom0.
I suppose that this will never happen as this is not a workaround per se.
That is because it is necessary to compile dwm from source in order to configure it. Even if the QubesOS team would be willing to add dwm, what dwm should that be exactly? Just plain dwm with the qubesdecorations patch added?
A user would be unable to modify trivial things like colors, font-sizes, rules and everything else.
I understand that this process is very off-putting to many users but I do not know of a better option.
Sidenote
I guess it is possible to use rpmbuild to download the dwm source-code to dom0 but then you have to modify and compile it inside dom0, which is basically the same process as the one shown in the guide, just even worse.
1 Like
Sounds good to me, really 
.
How’s the system stability under dwm? Some users (me included) report system freezes and/or system shutdown/crashes, both under i3wm, and also under other desktop environments.
How’s dwm faring so far under QubesOS 4.1.1?
Using it on 2 machines since release and never had a system freeze or crash even once. Although I would be surprised if such instability is caused by other desktop environments themselves.
1 Like
How do you deal with menus that appear behind their parent window when using floating mode? (example: Firefox’s context menu showing behind Firefox itself)
I have also been trying to figure something out with that.
dwm uses xprop in the rules, and I don’t think xprop can see menus. Therefore, I assume you’d have to write a patch to dwm.c that would give an “always on top” function for context menus.
There’s also some weird behavior when trying to use fullscreen, did you find a workaround for that? (I’ve noticed this in Firefox as well)
You’ll have to be more specific. What is “weird behavior”?
When I try to fullscreen some parts of the browser don’t get redrawn unless I switch workspaces (I’ve to switch workspaces for every visual change) also nothing gets fullscreened. Basically every time I accidentally fullscreen I’ve to reopen the browser.
(I should’ve mentioned I’m using sys-gui-gpu I’ve no idea if this is reproducible in dom0)
I am not sure about that because I do not do gpu passthrough. That does not happen on mine. Although I do sometimes have something similar happen when I wake from sleep.
Are you using the fakefullscreen patch?
Regarding the context menu thing, someone on Reddit suggested (and I have not tried it yet) adding something to the code that creates the context menu window:
XSetWindowAttributes attrs;
attrs.override_redirect = True;
attrs.override_redirect = 1;
XChangeWindowAttributes(dpy, w, CWOverrideRedirect, &attrs);
Yes I am using the fakefullscreen patch, the behavior I tried to explain above seems to be the same as in this bug report.
There’s a workaround mentioned which is to manually change the _NET_WM_STATE to _NET_WM_STATE_FULLSCREEN, in my experience it works inside the Qube but also in the gui domain (in my case sys-gui-gpu):
xprop -f _NET_WM_STATE 32a -set _NET_WM_STATE _NET_WM_STATE_FULLSCREEN
To return to a normal state this command can be used:
xprop -f _NET_WM_STATE 32a -set _NET_WM_STATE _NET_WM_STATE
Regarding the context menu I still haven’t found a workaround I’ve no idea where to apply that code, also I’m positive that code needs to be adapted that’s more of a POC. I think we need to patch transient.c but I’m not sure (I don’t code) I say that because the menus are reported as transient windows when using xprop, you can see that in your end with sleep 3; xprop then selecting the menu.