1) Multiplexers are a hack -- there are various problems with them, such as passing control codes through safely, keyboard shortcuts, performance, etc
2) Tiling WMs -- these can work (in fact I use a tiling WM myself) however, the nice thing about having tiling (and tab management) built into the terminal is that you can manage terminal windows and other windows differently on the same screen. For example, on small screens I like to have most GUI windows such s browser, etc. maximized, but I like to have terminal windows side-by-side, this is hard to manage if you want to have them on the same screen. With tiling built into the terminal, managing terminal windows is in a separate "namespace" from all other types of windows
I need to interact with my computer for it to do stuff, I think you somehow exagerated here.
Exluding that incoherent requirement, I'd have two choices:
1. Run the command in a terminal and hit super+f 2. Run the command in a terminal, super+right, super+w (I can switch back and for to <-> from the terminal).
Bonus point of using i3 is that I can optionally have any external program become part of my grid or add/remove exiting terminals to/from different mixed layouts (or workspaces). With multiplexers you're screwed and can't do that.
Note: I do use tmux on all my sessions, but it's mostly for "tab" support, or attaching/detaching (even from different workstations).
Then, there's a third option in addition to the two you mentioned: spend two minutes (if that) doing the one-time configuration of having the wm reserve a tag for your browser (and perhaps other GUI apps that you anticipate frequently needing/wanting to run full-screen). In awesome, you'd do that by adding an entry to your global rules table like this one (in rc.lua):
{ rule = {
instance = "firefox"
},
properties = {
screen = "HDMI1",
tag = "3"
}
}
You can also use awesome-client(1) to send Lua code to a running awesome instance for execution within the wm's context. This could be tossed into a shell script (and parameterized as you see fit) for convenience, if desired:
$ awesome-client <<EOF
require("awful").spawn("firefox", {
screen = mouse.screen,
tag = "3",
switchtotag = true
})
EOF
As for me, I tend to only use tmux under X11 if I'm worried about losing an ssh connection and therefore (without tmux, of course) the ssh session. However, I have DEC vt520 glass TTY that connects via RS-232 serial cable to a couple of servers (one OpenBSD, the other FreeBSD) and, while the terminal is pretty damn featureful, it has limited scrollback and awkward copy/paste functionality. So, on that terminal I use tmux quite a bit (although it seems to be rather chatty and during periods of heavy pty traffic can sometimes wind up spitting a garbage glyph on the screen here and there, but I think I may just need to increase the baud rate (despite already being set to ~56 Kbaud! cha-tty!)). The vt520 also only supports 2 sessions at once directly (and I can't even figure out how to get the OS to recognize the second one -_-), so tmux's multiplexing capability is also greatly appreciated when I'm basking in the amber glow.
Configuration is done through ~/.Xdefaults.
That's just my opinion but it's probably mirrored.
I've seen just about every terminal implement its own version of tiling, and I just have to ask: Why? Doesn't this just increase the line count and surface area without offering anything that doesn't already work just fine as a tool maintained by someone else?