既存のソリューションの中では、「ベスト」なのはRectangle Proだと思うけど、無料じゃないから、あんまりカウントされないかも。それに気づいて、ウィンドウを分割する機能はあんまりいらないなって思った。特定の座標にウィンドウを投げるためのキー割り当てがあればいいなと思ったから、Hammerspoon（無料）をインストールして、自分用にLuaでスクリーン分のコードを書いた。これは俺の2つの隣接する1440pモニターと個人的な好みに合わせて書いてるけど、コードはすごく分かりやすいから、自分でカスタムソリューションを作るのに慣れてるなら、これ結構いいし、無料だよ。

• https://www.hammerspoon.org/
• https://gist.github.com/joedrago/bfc54f4083b070fe998d519cc6c...

PowerToys好きだけど、1.17GBもスペース取るのはちょっとやりすぎだよね。これ、違法にすべきだわ。

Swish⁽¹⁾は、複数のウィンドウを一度にリサイズするために仕切りをドラッグできるアプリだよ。BentoBox⁽²⁾はFancy Zonesからインスパイアを受けてる。Lasso⁽³⁾はカスタムレイアウトのグリッドベースのウィンドウマネージャーだね。MacsyZones⁽⁴⁾もあって、隣接する複数のウィンドウをリサイズできるみたいだけど、使ったことはないな（オープンソースで、作者を支援するためにお金を払うオプションがあるみたい）。⁽¹⁾ https://highlyopinionated.co/swish/ ⁽²⁾ https://bentoboxapp.com/ ⁽³⁾ https://www.thelasso.app/ ⁽⁴⁾ https://macsyzones.com/

同じことを考えたけど、そんなやつにはなりたくなかった。

そうだよね、ユーザーがアプリに意図したクリックイベントが成功する可能性が高くなるっていうのもあるし、ウィンドウマネージャに奪われることが少なくなるよね。

先月KDE Plasmaに切り替えたけど、角が四角いウィンドウをまた持てるようになって嬉しい！

GNOME大好き！最近のFedoraでの実装が特に好き。Macに戻ると、なんでSpotlightとMission Controlが別の機能なのか不思議に思う。

同意！ウィンドウ管理に関しては、Windowsにもいいところがあると思う。macOSに戻るたびに、ウィンドウが右半分や左半分にスナップする機能とか、Winキーで開いているアプリを全部見る機能とか、アプリ全体をフルスクリーンにしない最大化ボタンとかが恋しくなる。

そうそう、Linuxを使い始めたときに気づいたことの一つで、なんで他のOSはこれを真似しないんだろうって思ったんだよね。

最近仕事用に新しいMacを手に入れたんだけど、Hyprlandからの移行が大変だった。でも、少しずつ慣れてきてる気がする。AerospaceとKarabiner-Elementsのおかげでかなり進んだ。自分の使い方に合わせてワークスペースを動かすためにいくつかスクリプトを書かなきゃいけなかったけど、全体的にはLinuxのセットアップに近い感じになった。でも、super+右クリックでリサイズできるようにしたいな（ctrl+cmd+左クリックでウィンドウを動かすのは便利だった）。

ウィンドウ移動についてだけど、UIをウィンドウのタイトルバーに置くのが流行ったせいで、つかむものがなくなったって反応だと思う。別に気にしないけど、マウスに専用の「つかむ」ボタンがあればいいなって思う。両手使ってウィンドウを管理するのが面倒なんだよね。

これ使ってるよ。メンテされてないから、設定で支援制御へのアクセスを手動で有効にする必要があるけど、それ以外はまだまだ動いてるよ: https://github.com/jmgao/metamove これ、Fluxboxスタイルのウィンドウマネージャーから来た人にはピッタリだよ。設定のUIもあるけど、これで設定を自動化してるだけ: https://github.com/justjake/Dotfiles/blob/3d359f961b009478ef... 26にアップデートしてから数週間、角の掴みエリアがひどいって気づかなかったのは、角を使おうとしなかったからだな。

macOSでは、Control+Commandキーを押しながらこのコマンドを使うとウィンドウのドラッグが有効になるよ: defaults write -g NSWindowShouldDragOnGesture -bool true これを「三本指ドラッグ」と一緒に使ってるけど、ウィンドウの境界でのサイズ変更はあまり問題になってないな。

もしかしたら、マージプロセスでの見落としかも？例えば、diffがRCにだけ適用されて、リリースブランチにはされなかったとか？よくわからんけど。

AIが変更を元に戻しちゃって、誰もちゃんとコードレビューしなくなったから、そのままプロダクションに行っちゃったんだよね。

何か技術的な詳細があるかも。例えば、2つのウィンドウがあって、1つのウィンドウの右下隅がもう1つのウィンドウの右上隅にほぼ触れている状態を想像してみて。バウンディングボックスは重なってるけど、グラフィックは重なってない。正確じゃない「偽の四角」の角だと、バウンディングボックスをチェックするだけでどのウィンドウをリサイズするか分かってたのに、今は実際のグラフィック（もしくはマスク）をチェックしなきゃいけない。問題だとは言ってないけど、そういうことが起こる可能性はあるよね。単純なバグ、例えばクラッシュやメモリの破損、未処理の例外、いつものやつかもしれないけど、時間内に修正できなかったから、バグのあるコードを放置するよりは元に戻した方がマシだったんだと思う。

macOSは複数の画面にまたがるウィンドウに関して変なところがあるよね。それが許容できないレベルになってると思う。例えば、動きやスナップが不整合になることがあるし。画面が繋がってなくて三角形の配置になってる僕のセットアップでは、しばらくの間、ちょっと狂ってた。

おそらく（自然な考え方として）：彼らは公開テストをして、反応が良くなかったから、もっと良くできるまで保留にしたんだと思う。

これって、Appleのシステム内で一見簡単そうなことを実現するのがどれだけ難しいかを示してると思う。個人的には、このバグが表面化した後、なぜこんなに早く対応が決まったのか、他の長年放置されてるバグよりもそっちの方が気になるな。

設定でこれをオフにできるよ。どこだったか正確には忘れたけど。実際、1〜2ヶ月後にはできない方がいいなって思ったんだ、ハハ。

数ピクセル伸ばすのは簡単？スーパープラス矢印でウィンドウを動かす方が、モニターの境界にぴったりスナップするから、こんな問題は起きないよ。最近はウィンドウを「手で」ドラッグすることはほとんどないね！

モバイルSafariはタッチのヒットテストがひどいよ。コントロールの近くをタッチすると、誤ってそのコントロールにタップがスナップしちゃう場所がたくさんあって、使い勝手が悪くなることもある。理想的には、CSS内でタップゾーンを制御する方法があるべきだと思う。責任を持っていたページでその問題を修正する必要があったとき、HTML要素を追加する必要があって、全然理想的じゃなかった。確か、onclickハンドラーも明示的に追加しなきゃいけなかった気がする（onclickハンドラーを登録すると、Safariのタッチ動作が密かに変更されるっていう、厄介な隠れた副作用がある）。iOS26のSafariではタップを奪う新たな問題もあって、うんざりだよ。