Single-tasking workflow in Linux with DWM

2018-09-03 @Technology

As I have demonstrated with an action-oriented workflow, with less easy options at your reach you are more likely to focus on that priority item.

My goal is to maximize attention on the one screen/viewport containing your work. That involves eliminating the shortcuts/triggers that make switching to some tab/window/buffer particularly easy. Any non-essential visual stimuli that might drift your visual focus elsewhere also deserves the same treatment.

I emphasize the elimination of the easy distractions. Naturally, having total (root access) control of your machine, no amount of tinkering with your firewall, file system permissions or window environment will prohibit you from circumventing your own labyrinth.

Take the case of composing a document. An extreme variant of an action-oriented workflow might entail a single text-buffer occupying the entire screen (in my case the VIM buffer), nothing else to draw your attention, no possibility of escape, no means to de-maximize the window. In the public terminal terminology, this is commonly known as the kiosk mode.

I don’t necessarily insist that your workspace mimic a kiosk. In the course of your work you might encounter the need to reference some external resource, or switch workflows entirely - without employing drastic measures to exit the kiosk. Or you might need to restart your machine or even the window environment.

However, an authentic ‘kiosk’ mode is definitely possible provided you have root control of your system. Meanwhile, I will demonstrate a reasonable compromise.

Contents

DWM window manager and single-tasking

suckless.org configuration philosophy

DWM is a product of suckless.org, a German group that maintains and develops ultra-minimalist tools of lean coding standards, many available in the standard package repositories. The intriguing aspect of their applications is the configuration. All configuration takes place in the C source code, specifically in a config.h header file.

At one point I considered the practice of hard-coding configuration settings a poor practice. Perhaps used temporarily in the course of development, I coudn’t imagine that this be done in any quality production app.

Having considered the suckless.org philosophy, howerver, I’ve come to view the matter differently: not only an idea that’s not necessarily poor, but in certain cases, quiet beneficial.

As stated in their philosophy, storing the configuration in the source carries security and speed benefits. I see logic in that.

Recompiling their utilities is a question of milliseconds to seconds on modern hardware. The slow compilation concerns of the 80’s/90’s are no longer as applicable.

And considering the infrequency of such a recompile, once configured to your preference, I see the lack of external configuration files quiet inline with my pursuit of action-oriented workflows.

Mimicking the ‘kiosk’ mode in DWM

DWM is as light of a window manager as you’ll find. Personally I’ve used the awesome window manager for years, itself a direct inspiration of DWM but based on the Lua interpreted language. Along with Xfce, I’ve considered the two extremely light, but DWM attained new depths (or heights) in that respect.

In the default state, DWM features no menus, no notification bar, nothing but three layout options controlled via shortcut combinations. Additional features require software patches.

This very writeup I type in a DWM session, having stripped the configuration of most but the critical options to simulate a semi-kiosk mode. I eliminated all but one tag (for those unfamiliar, windowing environment tags typically refer to the different virtual desktops one may transition between).

I eliminated all but one layout - the ‘entire-screen’ layout (in contrast to others that might tile or cascade application windows).

I further eliminated shortcuts to resize or switch between windows, and left no means to execute any app but from the already-open terminal. How does this work in practice?

As my X-session initiates DWM, I’m greeted with a blank desktop. Pressing a shortcut combination, a terminal opens and occupies the entire screen.

Any further application opened thence respectively occupies the entire screen and assumes focus, be it another terminal or otherwise. The only way to return to the previous window or terminal is to terminate the active window, via a shortcut (or exit command).

Were I to launch a web browser, I must conduct the interaction and close it before control returns down the stack. The workflow has acquired a single-tasking, full-screen appearance.

Here I provide the relevant sections of config.h, severely stripped down to achieve the above behavior:

static const char *tags[] = { "1"};

static const Layout layouts[] = {
    /* symbol     arrange function */
    { "[M]",      monocle },
};

static Key keys[] = {
    /* modifier                     key        function        argument */
    { MODKEY,                       XK_p,      spawn,          {.v = dmenucmd } },
    { MODKEY|ShiftMask,             XK_Return, spawn,          {.v = termcmd } },
    { MODKEY,                       XK_b,      togglebar,      {0} },
    { MODKEY|ShiftMask,             XK_c,      killclient,     {0} },
    { MODKEY|ShiftMask,             XK_q,      quit,           {0} },
};

static Button buttons[] = {
    /* click                event mask      button          function        argument */
    { ClkLtSymbol,          0,              Button1,        setlayout,      {0} },
    { ClkStatusText,        0,              Button2,        spawn,          {.v = termcmd } },
};

I could have achieved the same with the Awesome Window Manager by also stripping down the configuration and shortcuts.

However, reconfiguring Awesome is a question of simply updating the external configuration file and restarting the environment without even compromising state.

Reconfiguring DWM, however, demands a recompilation and the whole X-session restart - not as trivial or compelling, and thus more likely that I respect the imposed constraints.

W3M, Surf, browser tabs

Having imposed the single-tasking mode at the window-environment level, what about the application-specific distractions such as browser tabs, or multiplexed terminals?

As I’ve previously sustained, tabs are a bad idea for focus. I’ve already transitioned to a W3M text-based web browser workflow with less emphasis on tabs.

For cases demanding a graphical browser, I incorporated a W3M shortcut to directly launch the page in the Surf browser. Also a product of Suckless, Surf is another minimalist browser, entirely key-stroke based: no menus, no tabs.

Screen and the case against multiplexed terminals

With respect to multiplexed terminals, I naturally refer to the Tmux session-based terminal multiplexor, on which I’ve relied for the previous 9 years or so.

Lately, I’ve come to consider stacks of multiplexed and multi-windowed terminals not quiet as beneficial for focus, much of the time spent mindlessly transitioning between different terminals. The setup resembles an evocative hacker’s playground, sure, but ultimately achieves little in terms of single-tasked focused attention.

I’ve worked around these distractions by leveraging the zoom feature, causing the current terminal to occupy the whole screen; or strict self-discipline.

However, I lean towards abandoning the multiplexing feature altogether, and transitioning to Screen. Screen is an equally powerful session terminal manager, but with what I consider crude multiplexing features, enough to refrain from their usage.

Disabling access to external VTM terminals

Linux power users may already be aware of the <ctrl>+<F-key> accessible virtual terminals, accessible even in the course of a locked window session. This enables you to not only escape to another terminal outside X, but initiate multiple parallel X-sessions (window environments).

You can disable the behavior by modifying /etc/X11/xorg.conf as such:

Section "ServerFlags"
    Option "DontVTSwitch" "True"
    Option "DontZap"      "True"
EndSection

Conclusion

The above strategies cater to single-tasking workflows, though may hinder or even devastate system admininstration labor, research-involved tasks, or interaction-oriented roles (such as graphic design) - those requiring at least some easily-attainable degree of multi-tasking.

Fortunately, a DWM session initiates quiet rapidly - almost instantaneously on modern hardware, were you to benefit from it in select cases. You could even select between multiple compiled DWM binaries: one stricter, one more traditional and flexible, etc.

However, as long as you’ve disabled the above mentioned virtual-terminal switching shortcuts, you’ll have no means to invoke parallel DWM (or any X) sessions. This is key towards committing to the current workflow until some point of closure.

Questions, comments? Connect.