About

Durden is a free (3-clause BSD) desktop environment for Arcan, thus it requires a working arcan installation, optionally set-up with compatible launch targets etc. See the Arcan repository and wiki for those details.

For detailed feature and use descriptions, please see the Durden-Web. The individual markdown pages are also accessible in the gh-pages branch of the durden repository.

Authors and Contact

Development is discussed on the IRC channel #arcan on the Freenode network (chat.freenode.org)

2015-2019, Björn Ståhl

Licensing

Durden is Licensed in the 3-clause BSD format that can be found in the licensing file.

The included terminal font, Hack-Bold is (c) Chris Simpkins and licensed under the Apache-2.0 license.

The included UI font, designosaur, is provided free (cc-by 3.0 attribution) by Archy Studio, http://www.archystudio.com

The included fallback font, Emoji-One, is provided free (cc-by 4.0 attribution) by http://emojione.com

Hacking

See the HACKING.md file for information on where/how to extend and modify.

Installation

Durden requires a working installation of arcan so please refer to that project for low level details, which also may cover system keymap (the facilities provided in durden are higher level overrides).

The arcan documentation also covers specifics on how to get X, wayland and other clients to work.

Other than that, you need to link or copy the durden subdirectory of this repository to were arcan looks for applications, or use an absolute path, like:

arcan $HOME/durden/durden

See also the starting section below, as well as the configuration sections further below.

Starting

distr/durden is a support script that can be run to try and automatically set everything up and start. It also takes care of relaunch/recover if the program terminated abnormally.

If you have a system that uses the "XDG" set of directories, the script will build the directory tree in XDG_DATA_HOME/arcan, otherwise it will use $HOME/.arcan. To help debug issues, you can create a 'logs' folder in that directory and both engine output, Lua crash dumps and frameserver execution will be stored there.

Configuration (runtime)

Most changes, from visuals to window management behavior and input device actions, can be done from within durden and the UI itself using the menu HUD. By default, this is accessed from META1+G for (global) and META1+T for current window (target).

All actions in durden are mapped into a huge virtual filesystem tree. Keybindings, UI buttons etc. are all simply paths within this filesystem.

These are covered in much more detail on the webpage, but the ones you might want to take extra note of is:

/global/input/bind/custom
	/global/system/shutdown/yes
	/global/open/terminal
	/global/input/keyboard/maps/bind_sym
	/global/input/keyboard/maps/bind_utf8

Another thing to note is that at startup, after a crash or keyboard plug event, a fallback helper is activated. This triggers after a number of keypresses that does not activate a valid keybinding. It will then query for re-binding key functions, (meta keys, global menu, menu navigation) as a means for recovering from a broken or unknown keyboard.

You can also reach most paths with a mouse by right- clicking on the active workspace indicator on the statusbar.

Configuration (manual)

There are four ways of configuring durden without using the UI:

1. The arcan_db tool

(See the manpage for more uses of this tool.)

This works offline (without durden running) and only after first successful run. All current settings are stored in a database. This can be viewed, and changed, like this:

 arcan_db show_appl durden
	 arcan_db add_appl_kv durden my_key

Or clear all settings and revert to defaults on the next run:

 arcan_db drop_appl durden

This is also used to control which programs (targets) and sets of arguments (configuration) durden is allowed to run. This restriction is a safety/security measure. Something like:

arcan_db add_target test BINARY /usr/bin/test arg1
	arcan_db add_config test default arg2 arg3

Would be added to /global/open/target/test

2. Files

The default settings used on an empty database is found in:

durden/config.lua

You can also control what is being run at startup in:

durden/autorun.lua

The first time durden is run, the following script will be run:

durden/firstrun.lua

Advanced input device configuration is in durden/devmaps for the various categories of devices.

3. Controls

Everything can be accessed and controlled (while running) using a domain socket. This is enabled through the (global/settings/system/control=name) path.

If enabled, it will appear in durden/ipc/name. You can use the socat tool to interact with it and control everything as if using input in the UI directly.

The commands accepted by this socket is any of (ls, readdir, eval, read, write, exec) to navigate the menu tree, as well as a 'monitor' command which lets you monitor subsystem activity.

There is also a 'MONITOR' command that lets you monitor one or several subsystems.

There is also a tool in arcan that can be built and run, arcan_cfgfs, which allows the control socket to be mounted and treated like a filesystem.

Troubleshooting

There are many moving parts that can go wrong, the display server aspects when it comes to managing GPUs, displays, clients and input devices - as well as client behaviors, the window management policies and the features themselves.

On top of this, there are a number of special cases, like VT switching, crash- recovery, display hot-plug, soft-reset and 'suspend-exec until program return' scenarios that all massage these different subsystems in ways that are hard to test automatically and for every configuration.

If durden itself crashes, the recovery can be so fast that you won't notice, but the notification widget (if enabled) on the HUD will likely provide you with a crash log.

If you suspect a client of behaving badly, you can start it with the environment ARCAN_SHMIF_DEBUG=1 to get a trace of what goes on, and there are multiple tools in the arcan source repository for live-inspecting the state of clients.

You can also ask a client to provide a debug view for you, if it supports that feature, by going to /target/video/advanced/debug_window - calling it multiple times may provide multiple levels of debug output.

Then there are logging facilities for all the frameservers, durden itself (if run through the launcher script) and .lua snapshots on soft-crashes. These are all enabled by creating a 'logs' directory inside your .arcan folder (on non-xdg systems, that would be $HOME/.arcan) and restart durden.