Visual Studio Codeにフローティング・ウィンドウを夢見る人たち

Visual Studio Codeアドベントカレンダー 14日目に参加しています。

githubのリポジトリで、2016年8月から2018年12月現在にわたり、350件を超えるコメントがつけられているissueがあります。

Allow for floating windows #10121

なにがやりたいか

本家IDEのVisual Studioには、タブをマウスで引っぱっていって、独立したウィンドウにできる機能があるのです。
これは使い慣れるとたしかに便利なもので、僕もよく利用します。
Chromeなどのブラウザでも同じことができますね。

このissueは、VSCodeでこれをやらせてくれ!というものです。

代替策

issue内の議論で何度も出てくる代替案として、vscode自体をもうひとつ別ウィンドウ起動し、同じファイルを開くという方法があります。

手順としては、

  • Ctrl+Shift+N で新しいウィンドウを開き、元のウィンドウのタブから新しいウィンドウへドラッグ&ドロップして同じファイルを開く

または

  • Ctrl+K O で、新しいウィンドウでアクティブファイルを開く

となります。

また今年の5月には、コマンドパレットに「新しいウィンドウでワークスペースを複製(Duplicate Workspace in New Window)」という機能が追加されました

これはこれで代替策としては悪くないと思いますが、あまりにも何度も同じことが提案されるため、先日ついに 「Please stop suggesting “Duplicate workspace”.」 とまで書いてる人がいました。

なぜ実装されないのか

技術的な問題

開発コアメンバーであるbpasero氏が早い段階で以下のコメントをしています。

mlewand commented on 16 Mar 2017

@bpasero by technical limitation do you say that it’s a Electron limitation? Or is it more about VSCode one project <-> one window design?

(抄訳)技術的な制約っていうのは、Electronの制約?それともVSCodeプロジェクトの単一ウィンドウデザインの問題?

bpasero commented on 16 Mar 2017

@mlewand depends, if I could open a lightweight window that shares the same JavaScript context and build some UI in it, that would certainly help. Otherwise we would end up opening a heavy browser window with own context that contains only the UI pieces we want to show, which seems like the wrong direction.

(抄訳)同じJavaScriptコンテクストを共有する軽量なウィンドウを開いて、その中でUIを作れるならいいんだけど、それができないなら、重いブラウザウィンドウに新しいコンテクストとUIを持たせて開く必要がある。それはちょっと違うよね。

昨年の11月にはもう少し詳しいコメントも。

bpasero commented on 19 Nov 2017

There is a technical reason why this feature is not making a lot of progress: We are using the Electron framework as cross platform UI framework which is based on Chrome underneath. Chrome has a model where each window get’s its own isolated context, e.g. each window has its own process and its own JavaScript context. I would not be possible to share the same context between multiple windows.

Now imagine you you have an editor where you type in and you want to drag it out to produce a new window, you would expect that operation to be very fast and lightweight. But instead, it would require us to create a whole new instance of VS Code with separate extension host even in order to have the editor in a standalone window (this would be comparable to doing File > New Window and opening that file in the window).

I only see this feature possible when we find a way to create windows that share the same memory to the “main” window so that this operation is lightweight. Imho it would not work to have each of the floating windows be fully isolated as they are now.

(抄訳)この機能の進捗がない技術的な理由がある。我々はクロスプラットフォームUIフレームワークとしてElectronを使用しており、これのベースにはChromeの基本部(訳注:Chromiumのこと?)が使用されている。Chromeは各ウィンドウが独立したコンテクストを持つモデルになっている(例えば各ウィンドウはそれぞれにプロセスとJavaScriptコンテクストを持つ)。同じコンテクストをマルチウィンドウ間で共有することはできないと思う。

想像してくれ、タイプしているエディタをドラッグアウトして新規ウィンドウを作ろうとするとき、とても高速で軽量な操作を期待するだろう。だが実際には、VSCode全体の新規インスタンスを拡張機能ホストとともに生成する必要がある(これは File > New Windowで新しいウィンドウからファイルを開くのと同じだろう)

この機能は、メインウィンドウと同じメモリを共有するウィンドウを生成する方法を見つけた場合にのみ、軽量な操作として可能となるだろう。私見では、それは各フローティングウィンドウが完全に分離して動くようなものにはならないはずだ。

これらに対し、段階的なサポートを提案する意見や、以下のようなライブラリを使用しての解決を提案するコメントもあります。

https://github.com/electron-utils/electron-dockable
https://github.com/azain/electron-window-manager
https://github.com/illBeRoy/ElectronScriptWindow

しかしいずれにしても、コアな部分に関わる改修になると思われるため、簡単な話ではなさそうです。

思想的な問題?

コントリビュータの1人であるKrzysztof-Cieslak氏は以下のようにコメントしています。

Krzysztof-Cieslak commented on 27 Oct 2017

Typical dev commenting on this issue: “All other IDEs with bad UI designed in 90s forced me to buy multiple screens to be productive at all, so this new IDE shouldn’t try to fix problem differently but replicate same bad UI and support my multiple screens”.

I really hope this won’t be implemented, focusing on a single window, streamlined, editing focused UX is a strong advantage of VSCode, not disadvantage.

(抄訳)開発者の多くはこのように言っている:「90年代にデザインされたダメなUIをもつすべてのIDEは、生産的であるためにマルチスクリーンを購入することを強制した。この新しいIDEは、この問題を修正することで同じダメUIを複製しマルチスクリーンをサポートすべきではない。」

私はこれが実装されないことを切に願う。単一ウィンドウにフォーカスし、合理化されたUXはVSCodeの強力な利点であり、欠点ではない。

しかしこのコメントにも多くのdownvoteや反論コメントがついており、合意の難しさが感じられる議論になっています。

OSSはみんなのもの?

興味深く思ったのは、いつになったら実装されるんだと不平をいう人々に対する「文句いってないで必要な機能を実装してプルリクだせばいいだろ」というコメントに対し、rozzzly氏がつけたコメント

That would require the VSCode team to publicly discuss a plan for implementing this highly requested functionality. It’s too huge of an issue for any one individual to create some massive PR implementing the even most basic functionality—after all, every file dealing with references to the window or process space would require updates if not being thrown out and rewritten. Do you honestly think the vscode team would merge something that changes their product at such a fundamental level when they’re not directing it? I wouldn’t. The community cannot contribute until such a plan is openly discussed.

ざっくり要約すると、VSCodeチームがこうしようと指し示したわけでもない、基盤レベルの変更を含む巨大なPRを投げつけて、マージされると思ってるのか?と。
コミュニティは、計画がオープンに議論されるまでは貢献できないのだと。

そういわれると確かにそのとおりかもしれませんね。

contribute

「+1」とか「いいね」とかだけ書いたコメントは議論のノイズになるとして嫌がられているのでやめましょう。

というか、本当につい先日ですが、いいかげん疲れるからコメントを閉じてくれとリクエストがあり、現在はコメントがコラボレータのみに制限されています。

賛同の意を示したい場合は、先頭のトピックに対して👍をクリックしましょう。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする