#i3quake

Quake mode for applications under the i3 window manager.

i3quake creates, shows, and hides a terminal of your choosing. Common use for these sorts of tools is to bind a hotkey to the command and thereby create a pop-up-on-demand terminal. Features are:

• The terminal instance is persistent, which is a bit more lightweight than creating and destroying terminals; it also preserves your current workstream in that terminal.
• Uses any program you choose. It's been tested with alacritty, roxterm, xterm, gnome-terminal, xfce4-terminal, termite, st, and gvim. By default, i3-sensible-terminal is used to select a terminal.
• Opens the terminal on any edge, with configurable size.
• Single binary executable, with no additional dependencies.
• It's stateless. There's no server process.

#Installation

Binaries are here, and are signed with the GPG key 5E0D7ABD6668FDD1 (available from hkp://hkps.pool.sks-keyservers.net).

The program is go get-table:

go get code.ser1.net/i3quake

Put the executable in your path, and then use it to launch your terminal (or other application). For example, to auto-start the app from i3, put this in the ~/.i3/config:

exec --no-startup-id i3quake -p right -H 0.6 st

Subsequent runs of i3quake will toggle showing the window, but because i3quake uses the i3 mark facility, toggling can be efficiently bound directly in ~/.i3/config:

bindsym $mod+n [con_mark="i3quake"] scratchpad show

You can also perform this same toggle on the command line with i3-msg:

$ i3-msg '[con_mark="i3quake"], scratchpad show'

To bind additional instances (created with the -m marking flag), prepend your mark with "i3quake". For example, if you run i3quake -m MYCONKY conky, you would bind to [con_mark="i3quakeMYCONKY"].

#Examples

$ # open terminal on left, half-screen
$ i3quake -p left -H 0.5
$ # Open gvim on the right, marked as "gvim"
$ i3quake -p right -H 0.5 -m gvim gvim
$ # Open Conky on the left in "own-window" mode:
$ i3quake -p left -H 0.5 -m conky -- conky -o
$ # Run nvim in an st window from the top
$ i3quake -p top -H 0.75 -m nvim -- st -t nvim -w nvim nvim +Project

The marked examples can be used to bind multiple utility programs to different keys that are popped-up on demand. For these "custom marked" applications, the mark is i3quake<MARK>, so if you're binding this to a keysym in the config, for the above example you'd add this to your ~/.i3/config file:

# For the default mark:
bindsym $mod+n [con_mark="i3quake"] scratchpad show
# For the "conky" mark:
bindsym $mod+x [con_mark="i3quakeconky"] scratchpad show

#How

i3quake helps by setting up the windows with the information i3 needs to manage them the way you want. You can do all of this on the command line using i3-msg; i3quake just makes this easy for you. After that, the fastest and most efficient way of toggling is to bind an i3 command directly to a keysym; all other methods (including calling i3quake) do exactly the same thing, but with more overhead.

What i3quake is doing is taking your command-line instructions about placement and what to run, launches the application, and sets up the i3 rules for the resulting window. If you run it again, it'll go ahead and use the IPC to toggle the window; however, as mentioned above, this can be more efficiently done by binding the rule to a keysym in the i3 config file.

#Credit

The Python version that I started with was i3-quake. That, itself, was inspired by i3-quickterm. If we're going all the way back, the idea was popularized by the video game Quake, by ID software.

This version uses i3ipc-go; it's the only third-party dependency, and it was forked off ndemarinis's fork of mdirkse's original project. Both of those projects are a bit out of date and were missing support for i3's marking feature.

#Licenses

BSD 3 Clauses

#Supplemental design thoughts

After I wrote the program, I realized that it might not be entirely necessary -- or, at least, the part that I thought was useful, wasn't. Here's why.

It turns out that all of the useful work i3quake does is in the set-up of the window: figuring out dimensions, setting up the mark, telling i3 about the scratchpad-ness of the window, that sort of thing. Once it's done, the toggling is easily performed by i3-msg:

i3-msg '[con_mark="i3quake"], scratchpad show'

After set-up, the only thing i3quake does is to make the same IPC call that this command would. And, although I dearly love Go, i3-msg is pure C and is certainly lighter than i3quake. So my instructions changed from using i3quake for the toggling to what they are now.

The initial window set-up still benefits from being a program. It could all be shell scripted, but dealing with math gets a little wonky in bash, and the concurrency requirement of the program set-up still benefits from Go's easy concurrency model.