Windowsをメイン開発環境として使ってみる試みでbug.nを導入

サブPCとしてSurface Goを使っていることもあって、やっぱりメイン環境がHiDPIじゃないのがきになってきていたので、 4Kモニタを導入してみたのだが、Linuxで使おうとするといろいろ問題がでてきた。

まず、LinuxでのHiDPI設定というのはいまだにこなれてなくて、アプリごとにいろいろな設定をする必要がある。詳しくはArchWikiの該当ページとかを参照。 まぁまだそれは良いとして、いまの自分の環境のように、HiDPIなモニタとそうじゃないモニタが混在しているマルチモニタ環境だと、HiDPI設定をしたアプリを普通のモニタで表示するとめっちゃでっかく表示されてしまったりと、かなりツラいことになる。

HiDPIなモニタで環境を統一してしまえばいいのかもしれないが、個人的にはHiDPIなモニタと、144Hzなど高リフレッシュレートのモニタの組み合せが現状ゲーマーエンジニア的にはベストなデュアルモニタ構成であると思っているので、しばらくはこの構成を維持しそうな気がしている。[1]

そんなわけでLinuxでこのディスプレイ構成は痛みしかなさそうなので、ダメ元でWindowsをメイン環境として試してみることにした。[2]

Surface Goで開発環境は一応整えていて、開発環境として使えはする、というところまでは分かっているのだが、快適な作業環境という意味でかなり重要なのがタイル型のウィンドウマネージャ的なウィンドウ操作ができるかどうか、ということがある。 素のWindowsで開発していてやはり気になるのが、各ウィンドウ位置を調整するのに手間どる、というところだ。

Linuxではawesomeというタイル型WMを愛用していて、これを使うとEmacsをフルスクリーンで使っているところに、シュッとChromeをside-by-side表示したりまたEmacsにもどしたり、ChromeにかわりにTerminalを出したり、ドキュメントビューワをだしたり、といったことが瞬時に行える。 この快適さに慣れてしまうと、マウスでちまちまウィンドウの位置を変える、とかはめんどくさくてやってられない。 Windows 10にはビルドインでWinキーとの組み合せで画面分割ができる仕組みがあってがんばって使ってみたものの、やはりタイル型WMにはほど遠い使い勝手。

Windowsで動くタイル型WMはないものか、と探すとすぐに見つかるのがbug.nというWM。AutoHotKeyでうごいてるらしいことにも驚く。

さっそく少し触ってみると、tagの概念がawesomeと違い(awesome流のほうが好み)、ワークフローを考えなおさないといけないが、なんとかなりそう。

というわけで本導入してみたら、ハマるわハマるわ…。bug.n自体もDPI違いのマルチディスプレイだとすんなりとは動いてくれないのであった………。本末転倒とはまさにこのこと😢

いろいろやってなんとか動かすことができたのが以下の環境:

• 8.4.0という古いバージョンを使う
• Config_verticalBarPos=tray は使わない

です。 Config_verticalBarPos=tray はbug.nのステータスバーをWindowsのタスクバーの上に表示してくれてカッコ良いし、違和感がないので、ほんとうは使いたかったが、どうしてもこれを有効にしたまま上手く動かすことができなかった。

とりあえずこの環境ならなんとかうまくうごいてくれて、ギリギリメイン環境としていけるかなぁ、という感じ。ちょっとbug.nが不安定すぎるのが気になる。とにかくしばらくこの状態で使ってみることにする。

こんな感じ。(これはあんまりタイル型っぽくないが…)

bug.nにしろ、WSLにしろ、なんとなく使えてはいるが、そこはかとなく本物じゃない感というか、不安定感があって、使っていて不安になる。 とはいえこのディスプレイ環境のままLinuxを使い続けるのはもっとつらそうだしな、とう感じで消去法で環境をきめていて、なんだかなーという感じだ。せっかく使うからにはもうちょいがんばってWindowsを使いやすくしていきていとは思っているが、いまのところ最低限使える程度、という感じ。