Or more practically, using Windows as a window manager for Linux. So this is effectively local linux development on windows. Things like debuggers misbehaving, sessions getting scrambled, synchronization breaking, plugins not working when remote etc always seem to be there (for me at least). I started the project because I use C applications that target a linux environment a lot and although remote development has come a long way, it is still in my opinion pretty awful. If you can't get it working, raise and issue and I'll help if I can. I'll not get into the details here but it's all documented on the github repository (which you are welcome to star). however a workaround for this does exist, which I may write about later. This solution does not seem to play nicely with resume from suspend / hibernate. This is more of a show and tell / introduction to my toolbar project. I won't be doing a hand-holding tutorial (not at this point at least). This particular solution is focused on WSL 2, but will also work on WSL 1.

it's more of a brain dump of what I did, the project that I maintain, and how you can run every Linux UI application in a sensible way alongside windows.

And this is a productivity machine after all. Which means things tend to work out of the box. Not because of Linux, I hasten to emphasize, but because Windows and (occasionally) Mac are the only operating systems that most peripheral vendors care about these days. Although you can usually do all of those things on Linux, it usually involves more effort than I'm willing to invest these days. If it was my choice, I would never touch Windows because it's just not as developer friendly, and I'm a professional developer.īut sometimes you want to run Office. Yes those GUI windows are all Linux apps.

Tiling window manager for windows 10