Home
The dusk tiling window manager has its roots in dwm and the main difference relate to using workspaces instead of tags.
The aim of dusk is to seamlessly combine the very best that dwm has to offer in a complete package where everything is expected to work out of the box.
If trying to integrate patches is not your thing and/or is giving you mental health issues then you may want to give dusk a try.
If you have a patch in mind then it is highly likely that said patch or equivalent functionality is included.
dusk goes far beyond mere patches though when it comes to features.
There are way too many to list them all, but here are some features where dusk differentiates itself from dwm (and perhaps a few other tiling window managers):
- it uses workspaces instead of tags where the workspace can be freely moved between monitors
- workspaces can be pinned to designated monitors if so desired
- flexible dynamic layouts
- seamless restarts (applications stay on their designated workspaces and positions rather than being jumbled up on the first workspace)
- comprehensive multi-monitor support (e.g. special features for portrait vs landscape monitors)
- intuitive mouse support (e.g. rearrange or resize tiled windows using the mouse)
- floating windows can snap to other floating windows
- highly configurable bar(s)
- extensive EWMH support (which ultimately gives applications and external tools more control)
- feature rich scratchpads that can be assigned on demand
- asynchronous status updates with full click support (each status block is updated individually)
For a more comprehensive list refer to the Features page.
There are some things that are out of scope for this project. Here are a few ideas or topics that there are no plans to integrate for the time being:
- manual tiling - while technically not that complicated the general workflow of dynamic tiling is just so much faster and ideally the end user should not have to think about where to place the next window. If manual tiling is your thing then perhaps refer to herbstluftwm or i3.
- polybar - no additional support or integration for external bars such as polybar or lemonbar is planned
- dwmblocks, slstatus, xsetroot, etc. - all these status updater programs for dwm rely on setting the X root name to update the status which is not supported here - instead each status block / segment is updated individually and asynchronously from other blocks via the external dusk client
- plain text configuration file - while possible this would make things a lot more complicated and ultimately give the user less configuration options, so re-compilation will still be necessary to apply configuration changes
- Wayland support
If dusk gave you a feeling of loneliness, distress, depression, anxiety or mental fatigue then you may want to seek help in one of these support groups:
dusk is an evolution of dawn which again was derived from dwm-flexipatch.
I like think of dwm as a puzzle video game, with DLCs provided via patches. At some point I had played it to death and finished most of the DLCs so I wanted some new challenges.
Having spent so much time working on the implementation, and maintenance, of dwm-flexipatch there were some underlying issues with dwm that became more apparent over time and started to get really annoying.
Because of this I felt the urge to make some more drastic changes, but I couldn't just start making changes to dwm-flexipatch as that would go against the idea and purpose of that project (and arguably that was taken too far already with the barmodules implementation). So I needed a new dawn and that ended up being the name of my build as I wanted something that sounded similar to dwm, was easy to pronounce, but also had some meaning.
dawn ended up being a refinement of previous works introducing client flags which simplified rules handling and functionality that could be turned on or off during runtime.
There was something that nagged me though and that had to do with tags. I love the concept of tags and how they are intended to be used to create a combined view of the windows you want shown at any time. Then there is the pertag patch which allows the user to have a different layout, etc., on a per tag basis. In a way it creates the illusion that each tag is a separate workspace, and kind of gives something one might refer to as a "best of both worlds" given that you can still combine tags. But in the end the pertag patch taints the purity and concepts of tags.
Implementing actual workspaces, where each workspace has their own client stack, is something that I was very interested in and curious about. I had attempted this two times in the past, only to give up due to the sheer complexity and amount of work needed to pull something like that off. When you have more than four thousand compilation errors to address before you can even test your changes then that can start to become dissuading.
It was a festering idea that was hard to let go of and an itch that needed to be scratched, so fuelled with a craving for a new challenge I decided to have another go at it. I had more clear strategies in place, like separating the workspace from the monitor and keeping tags as-is. The first working version actually had nine workspaces plus nine tags per workspace. Interesting enough as an idea, but way too confusing for even veteran users. I later refactored the tags out.
When it came to the name going from dawn to dusk was a fairly obvious choice.
The main difference between dawn and dusk is that dawn uses tags while dusk uses workspaces.
dusk is actively being maintained whereas dawn is not. It remains as a public archive for those particularly interested.