Taken from one of the lectures on youtube:
“An operating system is just a bootloader for Emacs”
Taken from one of the lectures on youtube:
“An operating system is just a bootloader for Emacs”
RME has added a Class-Compliant mode to its powerful audio/MIDI interface Fireface UCX. The class compliant mode (CC mode) allows the device to work natively under all operating systems including Linux. Despite the fact that historically, RME offered good Linux support (Hammerfall DSP series of cards), let us not be fooled when it comes to RME’s intentions. The CC mode was not introduced with Linux users in mind. Its primary purpose was to ensure that it plays nicely with iPads. The Linux support is more of a by-product of the USB class compliance mode.
Now although the Fireface UCX is perfectly usable and still very powerful in the CC mode, it does not come close to what the device has to offer with the proprietary RME drivers available on Windows or Mac. One of the biggest things missing in the CC mode is TotalMix, a mixer providing a comprehensive set of effects and a limitless routing capabilities (image below):
On Linux, by contrast, the device mixer boasts as many as one channel to adjust, namely “Speaker Volume”. Sad.
Being in the CC mode, the device is recognised in Slackware 14.1 out of the box:
To conclude, it is indeed great that this powerful device works under Linux. It’s a pity that its capabilities in the CC mode are somewhat limited.
Following my previous post on how to define, save and restore layouts, in this post I’ll show you a way to quickly switch between layouts.
As shown in the last post not only is it possible to load a desired workspace layout, but also you can automatically populate the placeholders with applications of your choice. Imagine you’ve created two layouts: workspace_1-basic.json and workspace_1-generic.json.
You can create two short scripts to load the layouts and populate them with programs. Please note that we need to kill all the existing windows in the workspace. Otherwise, the loaded layout will append itself next to the existing windows on the workspace. It’s not the most graceful way of killing windows but I couldn’t find any other way of doing it. Furthermore, do not forget to add the trailing & to indicate that the job needs to be executed in the background. Otherwise, the first program will block loading any subsequent ones.
We can bind them to keys in i3 main config file:
Please note that the layout feature is still fresh. It hasn’t even reached the stable branch of i3 yet. As far as I know, it’ll be part of version 4.8 of i3 (whenever it’s released). See my previous post on how to install the development branch of i3 that will let utilise this feature.
There are going to be some exciting changes in the next version of i3. Version 4.8 will have a new feature of saving and restoring workspace layouts.
If you’d like to try it now, you can use a development branch of i3 git repository to build a package. Here is a SlackBuild script that can be used to build the ‘next’ version of i3. Please note that you need to specify the version as follows:
Without passing the version, the script will build the ‘master’ branch of i3, which is the latest stable version including all the bug fixes.
Before you can build i3-next, you need to install all the dependencies. Apart from the old ones (dmenu, libev and yajl), there are some new perl modules required. They are not runtime dependencies, but they are needed if you would like to utilise the new layout features.
New layout features
The new layout features allow for a quick way of saving and restoring workspace layouts alongside with all the applications populating the placeholders. Below is a tutorial on how to use this feature.
The following is a layout we will be working on:
First, open and appropriately arrange required programs. In my cases it’s a number of xterm instances running various command line tools. To make it easier for a further identification of a window, I start each of them with a meaningful name, such as:
I have 5 labels, each describing the position of a container: topleft, middleleft, bottomleft, topright, bottomright.
Once you’re happy with the layout, you need to save it in a file. The layout is going to be stored in a json format.
By default, the file is not yet ready to be used. First, you need to edit the file to ensure each window matches the criteria to be swallowed by the right container.
If you open the JSON file containing the layout, each section representing a window will contain a ‘swallows’ subsection that will help us identify each container
There are three things to observe here: by default, the class, instance, and title variables are commented out so we need to remove the comment tags. The title of the ‘middleleft’ window has not been captured. I would like it to be populated by ncmpcpp so I’d need to modify it so the section reads
After the layout is loaded, the middleleft container can be populated by ncmpcpp in xterm with the following command:
The last thing to note is that although sometimes the title variable will get populated (like in the bottomleft section above), it may however need some cleaning up so that it reads:
If any of the variables do not match a window properties, you can always check them with the xprop tool. Now that we have cleaned the JSON file (here you can see the entire file for the example above), we need to create a script that would load the layout and fill the placeholders with programs:
The first command appends the layout to workspace number one and subsequently all the containers get populated with various CLI applications.
You can now bind the script to a key so that everything can be loaded in an instant. I have added the following to my ~/.i3/config:
Alternatively you might want to load a layout on i3 startup. In that case, please add the following line to ~/.i3/config:
You could also execute particular programs on i3 start.
I’ve however chosen not to do it automatically as I do not need a particular layout everytime I start i3. Furthermore, I’ve created a few layouts depending on what I do or need: generic, web-devel, python-devel, etc. Each profile or layout is assigned a different key making it easy to quickly load it with one key.
Thank you, Michael, for adding it to i3.
The release of Slackware 14.1 has brought a number of important changes including a switch from MySQL to MariaDB or the introduction of UEFI support. For i3 users, however, the most relevant change was the update of cairo. At the beginning of the year the changelog of Slackware’s -current branch read:
Lots of X updates in this batch! We were finally able to upgrade to the
latest cairo (including the long-requested XCB backend), as the text
corruption bug that was preventing that was fixed in the upstream X server.
This, as I have mentioned many times, means that we can now install i3 as the upstream wanted it, in its vanilla state. Today the 14.1 branch of Slackbuilds.org has officially been opened to the public including cleaned-up scripts for i3 version 4.6. Last month I contacted Michael, the author of i3, who suggested a few small changes, which have been implemented.
If you’d like to build i3 from its master git branch, have a look at You can still use my scripts for the master branch of i3, feel free to use the following script:
Seeing problems as opportunities is an extremely helpful approach that has yet again proven to work well for me. Recently someone has reported problems building i3wm using my Slackbuild script that uses the i3 master git branch. Not only did it prompt me to revisit the script but also encouraged to get in touch with Michael, i3 developer, who, as usual, was extremely helpful providing me with a number of corrections and helpful comments. Additionally, I liked how another slacker organised doc files and added those modifications as well.
Below you can get a SlackBuild script for the master branch of i3wm for Slackware-current (14.1). It’s not going to build on Slackware 14.0 or older.
Recently I have received a number of emails pointing out that i3 version on Slackbuilds.org is rather out of date. I would like to assure you that I have not abandoned maintaining the i3 SlackBuild. I have refrained from bumping up the version on the Slackbuilds site due to the change introduced in i3 v4.5 (and described in my previous posts) that would necessitate building i3 with PANGO disabled. As this is not in the true Slackware spirit of shipping vanilla software, I thought I’d keep it that way. The good news is that the latest (4.6) version of i3 builds fine on the -current branch of Slackware. That will make it possible to update the i3 version on the SlackBuilds website once Slackware 14.1 has been released, which shouldn’t be before long. In the meantime you can build the latest i3 version from the master branch script (-current: without modifications, 14.0: with PANGO disabled).
This release fixes, among others, a high memory consumption problem in i3 4.5. The issue, as explained by Michael, is a result of a human mistake in the release process. For full details of a bug report, see this. The new release fixes the problem, as well as, introduces a few other changes.
Feel free to use my SlackBuild script to build the latest stable release of i3 including all the bugfixes. The builds for Slackware 14 and the -current branch are available here:
Having come back from my holiday I found a pleasant surprise in the form of a new i3 release which contains a lot of bug fixes and cleanups. For a list of all the changes in the new version, please refer to the release notes.
Furthermore, regardless of the Slackware version you use, I’d like to encourage you to use SlackBuilds (Slackware14, Slackware-current) pulling the master branch of the i3 window manager. See the explanation in my previous posts.
You work on a very important project and have a number of windows scattered over a few workspaces and monitors. Some of them are just opened for visual reference while others need to be regularly re-visited. An obvious solution would be to group windows in a logical way so that it is easy to switch between them. Depending on the number of windows and your working habits, this might not be enough. Fortunately, i3 offers some shortcuts or easy ways of creating such shortcuts. These might not look like life savers at first but, if used efficiently and on a regular basis, over time they can add hours or even days to you precious coding time. I will present a few tips with the best (IMHO) left till the end: the use of vim-like goto marks.
Going Back and Forth
Imagine you are working on one of your workspaces and you just quickly need to check something on workspace 4 so you press $mod+4 to switch to it. Once you have checked it, you don’t have to remember the number of the previous workspace. You just need to press $mod+4 again and you’ll return to whatever workspace you were working on. To enable this functionality, make sure you have the following line in ~/i3/config:
But it gets even better. The following key binding lets you switch back and forth between the last two workspaces that you visited pressing the $mod+z key combination.
Furthermore, you can move windows back and forth with:
You could combine the two actions so that you move a window backwards and forwards and follow it.
Configure focus on keybindings;;dfafdad
Sometimes it would make sense to hard-code focusing on certain windows:
Using the last key binding will bring focus to an instance of Terminal running the weechat irc client. You can identify particular windows using the xprop client property displayer. Sometimes, however, it might not be easy to identify a client and that’s where vim like goto marks come in handy.
Goto marks in i3
Goto marks let you mark a window on the fly so that you can focus on it at a later time. Please bear in mind that they do not modify your config file so they will be lost if you exit i3. They are meant to be session specific or for windows that are difficult to identify. I will present a few ways you can use them to focus on windows.
The first method is by explicitly naming particular windows and calling them by name.
When the focus is on the window that you’d like to mark, you can press $mod+m and type the mark name, for example: ks (short for the terminal window where you edit kernel source). You can name a few windows that you visit regularly giving them other, ideally short labels and the marks will be stored for the duration of the i3 session.
Then you can immediately access (ie. focus on) them from any workspace or display by pressing $mod+Shift+m and typing an appropriate mark name, eg. ks.
An alternative approach would be to use numbers or letters with Emacs-like modes.
Pressing $mod+g you enter the mark_window mode where a new set of keybindings (defined above) applies. Please note that it’s essential that you specify a way of returning to the default mode. Otherwise, you might get stuck as standard i3 keybinding do not work inside modes unless explicitly set. After you’ve entered the “mark_window” mode, you can press, eg. 1 to set a mark on the currently focused window and press Esc or Enter/Return to exit to the default mode. Now whenever you want to jump to window marked as 1, you’d go to the go_to_window mode, press 1 and exit the mode: $mod+g 1 Esc.
All-in-one approach using an i3 mode
The most optimal option, however, could be combining all the above mentioned tips under one mode where you could define your hard coded keybindings, leave an option for adding on-the-fly window labels, as well as use numbers for tagging windows.