i3 4.18
i3wm.org
i3wm.org
It's a curation of several tools combined with i3 that gives a pretty fantastic gnome/i3 experience. Similar to spacemacs and emacs.
Also, is this really only for Ubuntu?
Yes.
>> Or do I have to install it as a completely separate DM?
I'm not sure what you mean. The Ubuntu package provided lets you select this desktop from the login screen ( as opposed to i3, Plasma, or Gnome ). This is essentially a new Desktop Environment, made up of gnome and i3.
>> Also, is this really only for Ubuntu?
Unfortunately yes. I've tried looking at packaging this for Arch Linux, but it looks like quite a bit of dependencies are forked ( i3blocks is now i3xrocks ). Not everything is pushed upstream. Getting this to work on non-ubuntu based distributions looks tricky if you're not familiar with packaging already.
I managed to golf some tiny generic inline bash scripts that fit directly inside my i3 config for screen brightness and keyboard brightness using /sys/class with generic name matching and no hardcoded values. They do require an external sudoers entry for each /sys/class unfortunately but that's because they require root perms by default.
These have served me well across multiple desktops and laptops without needing to customization for each piece of hardware.
I can post if any interest...
$mod+Shift+p exec "xrandr --output HDMI1 --auto --right-of eDP1"
$mod+Shift+o exec "xrandr --output HDMI1 --off"
bindsym $mod+Shift+x move workspace to output HDMI1
You might need X11 python bindings and other dependencies that in general should be available on most distros.
See if it works for you, enjoy:
https://github.com/riccardomc/rcs/blob/master/scripts/.scrip...
bindsym XF86MonBrightnessDown exec "xbacklight -dec 10"
bindsym XF86MonBrightnessUp exec "xbacklight -inc 10"In your i3config for screen and keyboard...
bindsym XF86MonBrightnessDown exec "sys='/sys/class/backlight/*backlight';\
bri=$(cat ${sys}/bri*); max=$(cat ${sys}/max*);\
val=$(($bri - $max / 32)); val=$(($val < 0 ? 0 : $val));\
echo $val | sudo tee ${sys}/bri*;"
bindsym XF86MonBrightnessUp exec "sys='/sys/class/backlight/*backlight';\
bri=$(cat ${sys}/bri*); max=$(cat ${sys}/max*);\
val=$(($bri + $max / 32)); val=$(($val > $max ? $max : $val));\
echo $val | sudo tee ${sys}/bri*;"
bindsym XF86KbdBrightnessDown exec "sys='/sys/class/leds/*backlight';\
bri=$(cat ${sys}/bri*); max=$(cat ${sys}/max*);\
val=$(($bri - $max / 32)); val=$(($val < 0 ? 0 : $val));\
echo $val | sudo tee ${sys}/bri*;"
bindsym XF86KbdBrightnessUp exec "sys='/sys/class/leds/*backlight';\
bri=$(cat ${sys}/bri*); max=$(cat ${sys}/max*);\
val=$(($bri + $max / 32)); val=$(($val > $max ? $max : $val));\
echo $val | sudo tee ${sys}/bri*;"
/usr/bin/tee /sys/class/backlight/*/brightness
/usr/bin/tee /sys/class/leds/*/brightness
The nice thing about scripting /sys/class directly is that other than the permissions it is self contained and you can easily adapt above to any other stuff it presents on your particular piece of hardware.
The value 32 is the number of divisions over the range, so it should be consistent across different hardware, but you may want to adjust it to taste still.
... awaiting more golfing like a sed oneliner :P i wrote this quite a long time ago.
I'm curious - I've done it both ways, scripting /sys/class and using xbacklight. On my X230 I used xbacklight, and it seemed to work fine. How would I tell if it wasn't changing the backlight itself? I'd rather use /sys/class to get it right.
Also, here's my /sys/class code - not sure where I got it, but I probably adapted something I found. I assume it works, but it's been commented out above the xbacklight version for some time. :)
bindsym XF86MonBrightnessDown exec bctl="/sys/class/backlight/intel_backlight/brightness" && echo $((`cat $bctl`-68)) | tee $bctl
bindsym XF86MonBrightnessUp exec bctl="/sys/class/backlight/intel_backlight/brightness" && echo $((`cat $bctl`+68)) | tee $bctlWith the exception of OLED (no idea if laptops use that stuff yet), when the LCD is fully opaque on i.e rgb 0,0,0 the backlight LED will still bleed through - Modern LCDs are much better at blocking out the LED than they used to be so it's not always obvious in a well lit room.
If you reduce the brightness to 0 with xbacklight and then sleep the computer: The display will perceptibly dimm much further as it turns off (since this guarantees the back-light is turned off). If you use sys/class method it's possible to turn the backlight completely off so that there is no perceptible difference when you sleep/poweroff the computer.
On the older LCD panels when poor contrast ratios were common it's very obvious that xbacklight is only affecting pixels. I've never seen this tool affect the actual backlight but maybe it does have that mode?
Your script is essentially using the same method although in theory it's not as portable since the path is exact and it uses a hardcoded interval, you may have to tweak both for different machines. My one uses bash path expansion that is more likely to match other path names, and derives the interval from the max value... I honestly haven't looked at the variety of possible paths for /sys/class/backlight and max values so maybe I was over anticipating when i wrote this.
Also, among all tiling window managers, I think its config is probably the most intuitive to mingle with. Hardly ever breaks (if ever) between upgrades, and default workflow is very intuitive and explicit. Other window managers (eg. Awesome, xmonad) have pre-defined layouts, which (for me at-least) create more confusion than value.
PS> I think I've been using i3 since 2010 something.
I haven't used i3, so I don't know if yabai mirrors the i3 experience, but it's a very nice programmable keyboard-centric tiling wm for macOS.
these looks good, thanks for sharing - have you tried amethyst?
i3 has the benefit of being in an OS that doesn't use a super key for everything.
For Yabai, I mapped caps as HYPER -- which is good for most combinations.
The reason (at least for AwesomeWM, but DWM too) we use pre-defined layouts is because you can (and should) pass your own functions for each tag/workflow. This way you don't have to manage the layouts manually.
Once you add the custom business logic, it becomes very predictable. Plus, AwesomeWM is modular, so if you want i3 style layouts, you can just do it (https://elv13.github.io/client_tiling/dynamite.html , by me). Of course not all users want/have_the_time to optimize their workflow. Those people should probably stick with i3. AwesomeWM is all about customization/workflow_optimization, that's time consuming, but you have a good ROI.
I was noticing that I was only using 1-2 tiles at a time and I could easily emulate that by just side-by-siding windows in KDE.
I think if I ever have the chance to use a Linux machine professionally, especially with multiple monitors, I'll definitely reach for i3 again.
My success with it with KDE was a little mixed, but I also didn't make any effort to resolve the little issues. With MATE though, it works flawlessly with no downsides or really any config needed. It's fantastic.
Here is how I set it up with MATE: https://www.mattgreer.org/articles/mate-and-i3/
Also, got any pictures of the desktop?
Yes setup is fiddly at first but on my daily driver I haven't touched the config file in months.
I'm now on i3 (actually Sway), but when I was still using KDE Plasma, I extensively used the "quick tile" global shortcuts for KWin. They're not all bound by default, but you can set them up in System Settings (Global Shortcuts > KWin). I had it set up so that Win+S maximizes the current window (which by itself is quirky), and then every key around S is for a quick tile. For example, Win+Q moves the current window to the upper left quadrant. Win+D has the window occupy the right half of the screen, and so forth.
The only thing that I do miss from KDE times is the full KDE Connect integration. I have kdeconnectd running through some clever trickery, and the sshfs and MPRIS integrations work fine, but e.g. clipboard sharing doesn't work with Sway yet.
Not particularly[0]. It's more about the workflow and representation of data needed to work. To change this would require fundamentally changing the way this work is done, which I'm not sure is possible to the degree where it would make sense.
All of the applications are capable of being used on a single monitor. Windows can be docked, tabbed, hidden, workspaces arranged and saved, etc. It's just that it's not as efficient to work on a single monitor as it'll require significantly more scrolling, panning, zooming in and out, and switching tabs/windows/applications than having another screen to offload and dedicate windows to with the provided real estate. Once you experience having multiple monitors for these kinds of workflows, it becomes a real bother only having access to one. It sounds superficial, but when that's what a large portion of the job entails every little bit helps.
Even when I had multiple monitors, I combined that with virtual desktops to great affect to help focus what each workspace was used for (one for main 3D, one for compositing, one for texturing, etc). They work really well together. If one wished to stick with a single monitor, then using an ultra-wide would be my best recommendation.
[0] There are some areas, where UI's and viewers are written with 8-bit support only, so a 10-bit secondary reference monitor to use with a dedicated output card is required when working with this kind of material 'properly' (accurately, correctly, without dithering, etc). Even when this isn't required, a second monitor is often used as a dedicated full screen viewer anyways so that an image is viewed at 1:1 in its entirety with no scaling artifacts introduced so the artist knows exactly how an image looks.
True, but peripheral vision is a thing. I have Slack and stuff on a separate monitor, so I can see from the corner of my eye if there are any unreads.
So what you want is already supported. Just don't switch over to monitor B and switch it to a different workspace.
workspace $ws1 output DisplayPort-0
workspace $ws2 output DisplayPort-1
workspace $ws3 output DisplayPort-0
workspace $ws4 output DisplayPort-1
workspace $ws5 output DisplayPort-0
workspace $ws6 output DisplayPort-1
workspace $ws7 output DisplayPort-0
workspace $ws8 output DisplayPort-1
workspace $ws9 output DisplayPort-0
workspace $ws10 output DisplayPort-1 set $monL DP-1.3
set $monR DP-2
set $ws1L "1L"
set $ws2L "2L"
...
set $ws1R "1R"
set $ws2R "2R"
...
workspace $ws1L output $monL
workspace $ws1R output $monR
workspace $ws2L output $monL
workspace $ws2R output $monR
...
bindsym $mod+1 workspace $ws1L
bindsym $mod+2 workspace $ws2L
...My desktop, i only use 1 workspace per monitor. and i3wm is there just for tiling across large monitors.
My laptop, I only have 1 monitor so I basically mimic a multi monitor setup with workspaces, but tile less since the screen is smaller.
[1]: https://swaywm.org/
What does that mean?
Sway is a great project, but I would be careful of using Wayland, as lots of minor issues came up last time I was using it ( death by a thousand papercuts ).
For example, if you rely on years of small x scripts ( xrandr, etc. ), be prepared to rewrite all of them for wayland.
Last time I used Sway/Wayland, I couldn't find a good alternative to redshift. While Gnome has it, I can't seem to just use this feature independently on other DEs.
Again, Sway is fantastic, and I fully support moving off to Wayland. But best case scenario Sway is a drop-in replacement. Most likely there will be some fiddling. Especially if you've been using i3 for years and have built a custom ecosystem around it.
I am thankful that a wayland equivalent already exists though.
I say a niche tool because I've never really understood why someone would prefer a Window Manager that places a lot of constraints than one that lets you controls / customize the windows as you please and is thus "freer".
I guess it can seem useful for, say, multiple terminal windows. But would suck for a scenario where you have to open different kinds of applications like a browser, file manager, video converter, movie player, terminal etc. etc. (just citing all the apps I have open now and am multi-tasking with) where the ability to stack them would prove to be more productive for the user.
That even control freaks like Apple, who like to think only they know what's best for their consumers, doesn't use a tiling only WM in their OS is telling. Even Microsoft switched from a tiling WM from Windows 2.0 on wards and has stuck to it (Source: https://en.wikipedia.org/wiki/Tiling_window_manager ).
Yet they've been steadily adding tiling features since Win7.
Don't believe me? Grab any window in Win10 and drag to any of the corners.
Most of the time it's easier to keep different windows in different workspaces though. My first five workspaces are always
1. Browser
2. Browser
3. Code
4. Messaging apps (in a vertical stack)
5. Terminals
Pressing the number for the workspace where you keep the window you want is way easier on the eyes and brain then hitting alt tab and examining the pop-up panel to see how many more times you have to hit it.
E:
> That even control freaks like Apple, who like to think only they know what's best for their consumers, doesn't use a tiling only WM in their OS is telling.
I don't think so. Like any other pro tool it has a learning curve which without a little time investment renders the tool useless. I think the only telling thing about Apple's choice of window management features is that they shoot for the lowest features possible so that users can learn them all as quickly as possible. On-boarding > user control for Apple.
I think the GUI that Apple ships is successful in so far as all of its features are literally visible. You literally have a mouse and a clickable pad, you always have maximize/minimize buttons. Any more advanced software has "hidden" features in that they hide behind menus and hotkeys. Though everything that is hard about "modern" computational interfaces is that discoverability is shit, see [1]
[1]: https://www.fastcompany.com/3053406/how-apple-is-giving-desi...
I feel the opposite of what you state. To me, a non tiling-window manager burdens me with moving and resizing windows, mostly with my mouse. With i3, its algorithm sizes and places the window ideally 90% of the time, and I fix up the 10% of the time with key commands, never needing my mouse.
My windows being so predictable and so easily maintained with the keyboard enables me to stay in flow much better. I basically never think about my windows, it's just a "solved problem" for me.
It's unfortunate that tiling window managers are really only available on Xorg based OSes. I feel if Windows and OSX had really good tiling window management (the available solutions are nowhere near as good as what something like i3 can do), then tiling window managers would be much more popular IMO.
Have it set up to spawn vim or VSCode instances using shared buffers and it's crazy handy. I can't go back to vimsplits!
That plus gnome's builtin shortcuts to move windows to different monitors and different desktops, and setting alt-tab to "switch windows directly" gives me pretty much everything I need.
Windows don't start tiled, but this doesn't feel like a big drawback. When matplotlib pops up five plot windows I'd rather they stay the aspect ratio they were intended, anyway. But I'll snap my text editors, terminals, and file browser windows to half/quarter of the screen.
It's pretty great, and I get to stay within GNOME which is the 'happy path' for linux desktop use IMHO.
you can replicate whatever setup you had using i3-save-tree which outputs a json file e.g
i3-save-tree > .config/i3/workspace1.json
exec --no-startup-id i3-msg 'workspace $ws1; append_layout ~/.config/i3/workspace1.json'
While I kind of get where you're coming from, contrary to what you describe it's actually more control for me personally. What you call constraint is my preference that I'd otherwise have to handle manually. Sizing is more convenient than what I did before (basically manually adjusting everything to the tiled views, I prefer that both for basic layouts and keybinds or fiddling with the mouse). Plus, at least with i3, you can always bind something to enable floating mode for a particular window if you really feel like it (in practice I rarely do that anymore honestly).
The key to effective use of tiling window management is the use of virtual desktops. The two go hand in hand. That's why Windows and Mac OS don't have it. Windows, btw, did re-introduce a "tiling mode" (or something like it) in their recent OSes. The use case to have two windows next to each other without fiddling with your mouse is just so prominent.
I rarely have more than 2-3 windows per desktop. The browser usually dominates its space completely, and is full-screen, almost always.
EDIT: I know Mac OS has "virtual desktops" now, but in the grand scheme of things, it's a relatively recent addition, and I doubt that many people use it. It's probably more of a power-user feature. But then again, so is tiling window management.
Ctrl + UP or "swipe up with three fingers" gesture on Apple Magic Trackpad will reveal all the active open windows and show a thumbnail of all the active workspaces (virtual desktop). It's much, much faster than alt / cmd + tab.
> The key to effective use of tiling window management is the use of virtual desktops. The two go hand in hand. That's why Windows and Mac OS don't have it.
MacOS certainly has virtual desktops and calls it "Spaces" ( https://support.apple.com/guide/mac-help/work-in-multiple-sp... ).
(But yeah, you are right in that some users may not be using it - I don't use it at all. I prefer to use tabbed windows, only have a single monitor and when the number of open applications or windows overwhelms me, I just close many of them.)
It's not that new. Spaces were added in 10.5 (2007).
Combine that with multiple desktops, which can also be switched between with a couple of keystrokes, and you get an environment that's very easy to "drive" without taking your hands off the keyboard.
MS recently added snap abilities with Windows 10 that lets you split / orient 2 windows and control them with hotkeys. This isn't quite a tiled window manager but it is going out of their way to introduce a lighter form of dealing with a tiled interface.
They also released "FancyZones"[0], which is a window manager (although much different to how i3 works unfortunately). It's still in its infancy and likely has years to go before it can be compared to any popular Linux tiled window manager, but they are dedicating resources to the concept.
Until you've used a tiled window manager, it's hard to see the benefits.
[0]: https://github.com/microsoft/PowerToys/blob/master/src/modul...
Yes but Microsoft also found that a majority of folks want a tabbed terminal interface and icon emojis before being able to select text with a mouse in a terminal.
So I'm not sure how much credit you can give them for knowing what people really want in the end.
Also, I've spent some amount of time teaching old people how to use computers (ie. teaching my dad how to use Windows better so he can day trade). One of the most confusing concepts to him is how windows can just disappear or "get lost". Stacked windows that can be behind other windows or get minimized by pressing the wrong icon by accident is a lot more confusing than having a 2D plane of existence where you can see everything at once because the only way you end up hiding them is by explicitly doing things to move them into different work spaces.
If you are asking a question, do that, but there's no need to trash the idea of a tiling WM just because it doesn't suit your personal needs.
To learn and share obviously. (In fact, thanks to some of the other's who replied to my comment and explained their views, I am considering exploring the features of virtual desktop / spaces more now to see if it suits my workflow.)
As for you looking at my comment negatively, that can't be helped on the internet - we all have different personalities and different styles of communication, and everyone of us will, at some point, earn some supporters or piss of someone with what we are saying.
It's also harder to communicate in such a medium because of the lack of non-verbal cues that otherwise would help us better understand what the other person really means.
For maybe 90% of what I do, I have no need for in-depth control or customization of windows. When I work I use a browser, an email client, a couple of more or less permanent terminals and a bunch of transient terminal windows for short jobs. Sometimes I want a window to be slightly wider, I want to group some windows in a separate workspace or I want to temporarily focus on one window in full screen, but that's it. Most tiling window managers will have keyboard commands for achieving that level of control very easily while kicking every other aspect of window management out of my life.
There are cases where I think floating windows are more useful. Some software uses a lot of small windows to be able to maintain a customizable workspace for a good reason. For that, most tiling window managers will allow some windows to be floating.
> That even control freaks like Apple, who like to think only they know what's best for their consumers, doesn't use a tiling only WM in their OS is telling.
What is it telling of? I have no idea what motivated their choice of window management paradigm, but I guess it's easier, considering a large demographic with different backgrounds, to grasp floating windows intuitively. They afford flexibility for a wide range of applications with a minimal language of control gestures, but it's one-size-fits-all. I've been using computers all my life, though, and will probably continue doing it for long more, so I don't particularly need something to be intuitive from the get-go if it improves my workflow in the long term.
At home and work I configure four virtual desktops: firefox, emacs, terminal, misc. I usually have spotify open or more rarely a file manager in misc.
I can then bounce around in an absolute way (don't need to remember alt-tab or cycle history) using <super>+{1,2,3,4}.
Do only casuals comment on HN now?
The setting to always tile is entirely optional: you can move windows around with mouse/keyboard as much as you want, or snap it in.
Like "pro" apps, every IDE I can think of has their own UI conventions, eschewing their host OS. All I see a tiling WM doing is extending that to the whole OS. Tiling WMs IMHO are great at avoiding the mouse and strapping together your own "IDE" whether that's tailing a log while looking at code next to it, or looking at a result in a browser.
<3 i3
I've noticed when going back to Mint/Cinnamon that even though the terminal is only a click/keypress away, I think about it differently because it feels heavier and slower, the window chrome makes it feel more 'desktoppy' and if I want to summon a bunch of them to do a few different things (or one thing with a few different strands) I'll need to put in some cognitive effort to rearrange them how I like them. It's a bit of an immersion breaker.
For me, the killer feature of i3wm is not how it lets me arrange windows on my screen, but how it lets me switch between them. With OSX, I have to maintain a mental stack of recently-used applications: If I'm in my terminal and I want to get to firefox, I have to hit cmd-tab, or maybe cmd-tab-tab, or maybe cmd-tab-tab-tab. At least once a day, I make an off-by-one error and get stuck in a context-shift loop until I pause, think, and do the needful. With i3wm, I have 10 workspaces, and each is available with a single chord press. I have my own conventions about what's where, and there's no cognitive load associated with switching between text editor and documentation, or whatever.
Along the same lines, I like to keep a roguelike open for quick breaks, but ideally I'd never accidentally switch to a video game. OSX gives you no ability to punt an application from your cmd-tab list except to quit the application. With i3wm, I keep that on workspace 0, and have never accidentally switched over to it.
You may think I'm being precious, but it really does make a huge difference in my ability to stay in the zone.
I saw something in the i3 docs about this feature, but it didn't work on the first try and I didn't dig deeper.
'assign' allows you make so if window opens, it opens on given screen Lower, you can see me switch to given workspace before autostarting apps.
assign [class="Firefox] 3 assign [class="Slack"] 4
But it doesn't work for me
Yes.
> Is it keyboard shortcut efficiencies?
Yes.
> Is it just cool?
That too :)
---
Tiling window managers give lots of possibilities for very efficient screen usage: here's my IDE, my terminal, my browser, and my other browser all easily arranged in a nice way.
Plus, i3 also gives you composable stacked and tabbed layouts, for even more flexibilty.
I run i3 inside Mate (gnome 2 fork). The features I use most are switching between tiled and "tabbed", where you have fullscreen windows that can be navigated between like tabs quickly. I can pull up a browser and terminal or editor side by side, then switch to fullscreen terminal/editor, then back, very quickly.
i3 works in sort of a tree structure, so you can, say, split the root window level into two horizontal frames, then split the left one into three vertical ones, and the right one into three internal horizontal ones (if that's what you want).
I suspect I use the mouse more than most tilers, but I find <mod+Right Click> to resize while the windows stay tiled is quick enough and very accurate.
Then I got addicted to the speed of flipping between windows and not having to fiddle with layout. Now I only have one screen but it is always the first install on a new Linux.
Nice small and configurable window dressing and i3bar were very nice also.
Once you got used to it, you notice other things like the speed and configurability.
But tbh I do think it only makes sense if you do a lot in the terminal, and need to switch often between applications.
> move workspace to output: don’t create duplicate numbered workspace
and didn't even realize it was a bug, always thought it was an issue with my configuration.
Especially on small ("13 ~ "15) laptop screens, where people usually have <= 4 apps per virtual desktop, I think i3 doesn't have much benefit, because there are only a few possible layouts: half-and-half, master-and-stack(│├│ or │┤│) and quarter(田). All of these are well covered by Tile layout (or nv-stack, according to Arch wiki[3]).
On the other hand, I do admit manual layout can be really useful on large screens and ultra-wide ones. There's neither golden nor silver layout that always works well on large area. There are just too many possibilities, and imagination is the only limit in this case.
[1]: https://dwm.suckless.org/ [2]: https://github.com/esjeon/krohnkite [3]: https://wiki.archlinux.org/index.php/Comparison_of_tiling_wi...
However, could someone who used both elaborate on the differences? Would I gain anything from trying to migrate to i3 instead?
At my point of view, only the community size is the difference, but that hasn't bothered me too much as awesome for most part just simply works.
All the pain went away when I found Regolith [0], which I heavily recommend. It's i3 with Ubuntu but it comes with sensible defaults, a nicer theme and shortcuts to all the configs you could need out of the box. It really makes things a lot easier than using just i3, especially when doing a fresh install (it's available both as an installable image and as a package - I've had no issue with either).
Some default shortcuts are different so if you've been using i3 for a while you'll have to iterate a bit over the config to get to a comfortable point, but it's the same config file. I also changed the default terminal back to gnome term, since their default one doesn't have a scrollbar, but again it's pretty easy to do and you only do it once. All in all, really made my life better.
1. Using Windows 10's snapped windows along with various Windows key + arrow key hotkeys[0] for managing windows.
2. Using DexPot[1] for hotkey controlled virtual workspaces (same ALT + N hotkeys as i3)
3. Using Keypirinha[2] for fuzzy finding programs to launch (similar'ish to dmenu for launching apps at least)
Combine that with WSL + tmux + terminal Vim and it's not bad for day to day development. I've been using the above for over a year for full time development and while I miss my i3 set up on my native Linux laptop, it's manageable.
[0]: https://support.microsoft.com/en-nz/help/12445/windows-keybo...
Feel free to check it out and give it a try.
PS, for the enthusiasts: 100% written in Haskell
I used to be a KDE user and I loved the fact that I could stack windows and make the one on top semi-transparent. I'd be using this feature to watch movies while hacking in the terminal. The way you'd set it up is that you'd stack one window on top of another, set it to "always on top" and control its transparency through extra options unlocked in the title bar.
Now, the question is, could i3 do that? In other words, does the "tabbed" mode actually "render" the windows underneath so that I could use an external compositor to set its transparency to whatever I want? Ideally I'd love to have a shortcut for that.
My current setup i3-wm on Manjaro, alacritty with fish is exactly what I need.
I never had any issues with i3. Cannot recommend it enough!
If you're typing with proper form, "hjkl" results in the index finger moving down and the middle finger moving up. So, your most useful finger is used for the most common action, and your second most useful finger for the second most common action. What's probably the third most common action, moving left would be done with your index finger, and right with your ring finger. You'd never have to use your awkward pinky finger for anything.
With "jkl;", you'd be moving down with the middle finger, and up with the ring finger. Your dexterious index finger would be waiting for the moment when you'd want to move left, which is not as often, and you'd be encouraged to use your awkward pinky finger quite often.
This isn't necessarily the case when working with windows, but by now it's a matter of consistency. Although, encouraging to use the pinky finger and not being able to use the index finger for 2 actions still sucks.
[0] https://github.com/i3/i3/commit/6d0071db197031845b5f77febc22...
> To move the focus between the two terminals, you can use the direction keys which you may know from the editor vi. However, in i3, your homerow is used for these keys (in vi, the keys are shifted to the left by one for compatibility with most keyboard layouts). Therefore, $mod+j is left, $mod+k is down, $mod+l is up and $mod+; is right.
I wonder where they got that idea. The keys are "hjkl" simply because they were inscribed with arrows in the machine Bill Joy used when creating vi[1][2]. From [1]:
> Joy used a Lear Siegler ADM-3A terminal... the keys h,j,k,l served double duty as cursor movement keys and were inscribed with arrows, which is why vi uses them in that way.
The StackExchange question has a picture of the keys.
Can you send a PR for https://github.com/i3/i3/blob/30e886b0319ee948863a36a65e5b72... with your correction please?
Or do you think that not having arrows on "hjkl" is the justification of using "jkl;"?
Personally, I can't see a good reason for "jkl;". The rationale that those are the keys where the fingers rest has been brought up here, but here is my response:
https://news.ycombinator.com/item?id=22349868
The thing is that I believe the designers of ADM-3A made a good choice in putting the arrows on "hjkl" as opposed to "jkl;". It's much more ergonomic.
Couldn't think of the right word at the time.
noremap ; l
noremap l k
noremap k j
noremap j h
focus_follows_mouse no
Less of an issue on a tiling window manager, but sometimes I really want to be able to type in a window without bringing it to the foreground.
Also, selecting text should copy and middle click should paste. No one can convince me these things are bad or unnecessary.
The click not only focuses but is also passed on to whatever you clicked on, so it's like it was already focused.
> Less of an issue on a tiling window manager, but sometimes I really want to be able to type in a window without bringing it to the foreground.
I don't understand that. You have to somehow indicate to the system what it is you want to type on.
> Also, selecting text should copy and middle click should paste. No one can convince me these things are bad or unnecessary.
I'm 100% with you on that. Although saying "selecting text should copy" makes it sound like it's being copied when selecting, when it's actually copied when pasting.
You do it by moving the mouse. It makes the mouse more useful because you can now focus things with one less click.
On the other hand, in what circumstance would you want to move your hand to the mouse, move it intentionally over another window without clicking, and _not_ focus it? What would be the point in moving the cursor?
Precisely in the one that brought this into topic. It's nice to not have to be so careful with how the mouse moves. When it gets in the way, I can just flick it off, not worried about my stuff changing focus. It also greatly decreases the annoyance of accidentally touching a touchpad while typing.
I've just tested it and it does centre on the window only if the window is on a different monitor.
https://i3wm.org/docs/userguide.html#_mouse_warping
> By default, when switching focus to a window on a different output (e.g. focusing a window on workspace 3 on output VGA-1, coming from workspace 2 on LVDS-1), the mouse cursor is warped to the center of that window.
> With the mouse_warping option, you can control when the mouse cursor should be warped. none disables warping entirely, whereas output is the default behavior described above.
I agree that would be nice, though I've never really minded; If I'm gonna touch the mouse, I'm gonna touch the mouse.
My problem is that my table isn't perfectly stable, so when I type, my mouse moves on its own by microscopic distances. When I'm in the middle of typing, the results range from mildly annoying to infuriating, depending on how a random application handles given input.
I've just found this video describing a solution (writing a minimal script): <https://www.youtube.com/watch?v=7QeZkq88jTw>
bindsym $mod+h focus left; exec --no-startup-id center-mouse
That said, I thought i3's default behaviour was that it would only focus a window when the mouse entered it, not when the mouse was moving around within a window, so I'm surprised you're having that issue. For me I just got sick of my mouse being "way over there" in the odd situation I need it.
https://en.m.wikipedia.org/wiki/Comparison_of_remote_desktop...
1) Workspaces of workspaces
Let's say I'm working on five projects at the same time. Each project usually has totally different workspace configurations.
For example:
Project1 might have workspaces 1: dev, 2: mail, 3: tail -f access.log
Project2 might have workspaces 1: photoshop, 2: mypaint, 3: shell
Project3 might have workspaces 1: trello, 2: research
...
This is like tmux sessions. I can have multiple sessions, each session has multiple windows and panes. In tmux this works very well but in i3 you can'd do that.
I'm currently emulating this by running five independent i3 copies on five displays :1, :2, :3, :4, :5 and I switch between displays to switch to another project.
2) Static tiling
I3 is a dynamic tiling manager, which means it uses the entire screen. However, once you establish your workflow, you often have windows that take 1/3 of the screen and are 1/3 off the top, etc. and you don't really want them to take the entire screen because it makes you less productive and it feels weird. Also, once you establish your workflow, you don't want the workspace to change or resize. You just know where everything is and don't want a slightest disturbance in your workflow.
This is often hard to do in i3 and you need to use tricks such as vertical and horizontal splits of empty terminals to put the app where you need it to be. And it's extremely easy to mess this up, if you accidentally open a new terminal. Then your app resizes and shifts, and when you close the accidental terminal, it's no longer where it was because of many vertical and horizontal splits.
I found Notion window manager that is static tiling but I haven't tried it. It can also have tabs inside static tiles, which makes it very interesting.
3) Run or raise
Run or raise starts a program if it's not running, focuses it if it's running, and hides it when no longer needed.
For example, pressing alt+n starts and shows a notepad if it's not yet running. If it's running, it focuses the notepad and pressing alt+n again hides it.
I3 doesn't have this feature but it can be emulated via xdotool and scratchpads.
4) Using fzf instead of dmenu
Dmenu is nice but you need to type too much. The solution is to use fzf instead of dmenu.
I'm currently displaying a floating sticky terminal window that runs fzf, gets my input, performs the action, and disappears. It's so much faster than dmenu.
5) Using fzf to switch apps, workspaces, workspaces-of-workspaces
Often, when you're working on project2, you remember you had similar idea/code/notes in project4. You then have to switch to display :4, then switch to correct workspace and find the info.
This could be simplified by using fzf and just instantly switching where you need.
6) Using alt-tab to switch back to previous place you were.
Let's say you switched from appx in project2 on display :2 to appy in project4 on display :4, and now you have to cycle between them. You can't do that right now so the workflow isn't perfect and there's a lot of drag.
Merging gap support isn’t that easy, and our spare time is not unlimited. Serious offers to help very welcome.
Happy bspwm user here.
I wonder if people who like gaps like bezel on their screen too.
For me it's a bit like having a picture on a desk. It uses up space I could have used for working but I like it.
Merging gap support isn’t that easy, and our spare time is not unlimited. Serious offers to help very welcome.
Sometime this year, I'll have to give Sway/Wayland another try on my laptop. I'd love to switch to Wayland, but the past few releases of Sway there was always something I got stuck on I couldn't patch or work around.
To be honest though, there isn't much difference from a day to day perspective between X11 and wayland. A few things are nice (adding and extra screen doesn't reset the video mode) and a few things are worse (recording video). Make the switch when it's the natural choice, don't force it ;-)