Created windows may not fit cleanly in the requested dimensions and might size themselves larger so that they fit; this change ensures that if this happens, the window is shrunken so that it fits on the screen.
Build binaries for multiple archs; compress assets.
Alpine switched to musl libc, which breaks Go builds.
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:
i3-sensible-terminalis used to select a terminal.
Binaries are here, and are signed with the GPG key 5E0D7ABD6668FDD1 (available from hkp://hkps.pool.sks-keyservers.net).
The program is
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
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
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
$ # 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
# For the default mark: bindsym $mod+n [con_mark="i3quake"] scratchpad show # For the "conky" mark: bindsym $mod+x [con_mark="i3quakeconky"] scratchpad show
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.
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.
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.