Make Windows More Productive on Windows
Since the end of the 90's, all versions of Windows had the issue of drowning you in a mess of windows once you started to really work on your PC. Its fine if you use just word and maybe a browser or mails. In that case, alt tab does the job. However, as a developer, you often have half a dozen tools, bash windows, text editors, documentation and different things like music to cancel the world around you. Organizing all these windows efficiently is a bit tricky on Windows. So, two decades ago, I switched to Linux for all my private projects, started to use a virtual desktop grid and never came back to Windows. Until I got employed at a company that, in essence, doesn’t support working on Linux machines.
Now, if you have never seen virtual desktop grids being used efficiently, the whole thing I’m talking about will not make sense. So, here it is (at home):
My usual layout is: center of attention in the center workspace. Bashs are usually on the left workspaces. More IDEs usually on the top and right workspaces. The bottom center is almost always browser and mails. At home, I use the top center for secondary IDE, because I work a lot with multiple languages and need different IDEs. At work, I use top center and right for different communication tools, because I work with people over different communication channels.
Something you might have realized just from looking at the screenshot is that all windows are tiled in a 2x2 grid. Doing this efficiently is very important for me, because I would otherwise run out of screen space too fast and would have to alt tab again. If you want to be efficient as a developer, you should never have to touch your mouse, while using your keyboard to get something done. Equally, you should never have to search for windows with alt tab, because it interrupts your current thought which reduces your productivity which is the actual reason why my setup is so much more productive than anything else I’ve seen in the last two decades.
Another reason is that humans are good at remembering locations. If you need to organize eight bash windows and have to alt tab between them and look at the content to find the correct one, you will loose a lot of time. If you use two workspaces in a 2x2 grid, you simply need to remember the location. Especially, if you have an order for locations in your head that you adhere to most of the time, chances are high that the first bash you look at is also the one you intend to look at. It’s kind of a hash table in your head ;)
Controlls
Now, let us talk about how I organize my windows while working. First of all, the desktops are organized in a 3x3 grid that starts empty and never resizes. This is different from most on-demand virtual desktop approaches— I’ll come to how to get this to work on Windows later. Moving between them is done with ctrl + alt + arrows. This was the default, when compiz was introduced to Gnome, IIRC. But it also makes a lot of sense. You don’t have to really remember your target destkop’s number. You simply use the relative location to go there. This is one move from your main desktop and at most two moves for any other. I tried wrap around to reduce this to always one, but it is actually less productive, because you start loosing track of where you are if moving to the border results in no move at all. Especially, if you have more than three IDEs or IDE windows open at the same time.
Get Dr. Timm Felden’s stories in your inbox
Join Medium for free to get updates from this writer.
Sometimes, you need to take windows with you to compare or copy content. This is done with ctrl + alt + shift + arrows. On Windows, this is also required to clean up windows that moved to wrong desktops (mostly Teams) or got created on the wrong desktops (almost everything except Vivaldi). Also, I use a lot of short-lived bash windows for tasks like grep, git commands and similar. Those often spawn where I am and sometimes get and extended life on a desktop where they belong to. If you can spawn a bash with ctrl + shift + A, it’s just one small move of your left hand and it is much faster than even trying to touch your mouse with the right hand. You can close it again like any other window. And especially using git on command line is much faster than remembering how git integration works with Eclipse / VSCode / CLion / etc. Besides, if you remember all the commands you often need, it is also much faster. Obviously, assuming that you have an organized home directory allowing you to navigate to your projects fast ;)
The last part is window tiling. This entire snap to grid with mouse thing is something that I would disable wherever I can. It is slow and hard to use. Especially on Windows, where it tries to tile other windows into the remaining space which is almost never what you want. Unfortunately, it is also hard to disable. If you already have a desktop grid and a normal-sized monitor, using a 2x2 grid for windows is enough. Usually, I have one to four windows and tile them with ctrl + alt + num. Maximize is 5, half tiling is 4, 2, 6, 8 and quarter tiling is 7, 1, 3, 9. The move of your right hand reflects the resulting location. It just happens. On machines where I have two monitors, I also use ctrl + alt + num 0 to swap between monitors. For me, Eclipse is the only tool that works with two monitors because it is the only IDE that can deal with editor tabs correctly. Others tend to reopen tabs that are already open in other split panes or even reopen them in the wrong instance on the wrong workspace. VSCode is especially horrible in that regard if used in file mode (in contrast to folder/project mode).
This is btw. not about Linux vs. Windows. If you look at recent Gnome versions, it’s mostly as broken as Windows. Also, there is one thing that I took from Windows to Linux: super + L to immediately lock and switch off displays, because screensavers with OLED displays…why? Just switch it off to save power and prevent damage from overusing it with static images if that’s still a thing with recent displays.
Implementation
The implementation on Windows uses AutoHotkey. It is allowed at work for me and requires no maintenance. The only thing I ever did since writing it early 2020 was to update it to AutoHotkey v2 when switching to Windows 11. Back then, I did some performance measurements and, surprisingly, opening bash with AutoHotkey was faster than other options, including Windows Explorer hotkeys. Also, the open terminal command is very easy to implement or adapt if you want something different than git bash on Windows.
Something that is a bit harder is virtual desktop navigation. Here, I used a library that exposes the virtual desktop API to AutoHotkey. The library exposes Windows API as is. Thus, we need to somehow bake the 3x3 grid into it. Windows uses numbers 0–8. So, we need to detect illegal moves:
if(next < 0 || next >= 9 || (1 == Abs(num) && Floor(current/3) != Floor(next/3))){
return
}I tried to make the script more like my code and be smart and write functions. But, it was just plain inefficient. Because, AutoHotkey is a scripting language. It is good at attaching simple actions to hotkeys. It is very bad at configuring your desktop environment or building even simple overview images or something similar. Hence, I also resorted to 9 prebuilt icons as status indicator. On Linux, you have a nice overlay showing you all windows on all desktops and your location. Building something like that was not possible or at least not for me in the few hours I wanted to spend on the project — in the end, it was just an exercise to see what can be done with AutoHotkey. Creating those images with Gimp took just a few minutes. Setting them as systray icon equally. The drawback of the approach is that I somehow failed to find a way to get the correct current desktop on startup of the script. Hence, I added another one indicating the unknown state. It is anyway only used if you get lost, which only happens if Teams thinks it is allowed to rearrange random windows to other desktops and you jump to those windows using your task bar icons.
The only thing left is window tiling. This took a bit of tweaking time until it really worked. The reason for it is that Windows design is apparently completely broken in that regard. There is a confusing mix of desktop and window sizes and they seem to be inconsistently about windows with or without window decoration (border and shadow?!?). Desktop area seems to not really treat taskbar consumption as one might expect. It is also not resized correctly when switching between DPI modes. And now, with Windows 11, the only good thing Windows ever had — the Windows 7 Taskbar — has been removed. Apparently, some ignorant cretins brought it back (see). This is really a must have addon to Windows and we should all thank them for maintaining it. Inspite of those who we pay for making Windows usable trying to prevent them from doing it by moving the start menu to random locations on the screen, but I digress. IIRC, during the AHK v2 migration, I found this WinGetPosEx.ahk that I could update and get into a state where tiled windows wouldn’t randomly be off by one or two pixels. So, it is currently all working as expected.
Try It! Extend It!
You can just download it here. Set virtual desktops to 9, set the script to auto start and never loose time looking for windows again.
