FloatSoda が大事にしていること

FloatSoda は何を大事にして作られているか

FloatSoda は、SteamVR のオーバーレイ UI を、Flutter のような宣言的 UI として .NET 10 / C# 14 で書けるフレームワークです。大事にしていることは2つあります。Flutter の考え方を写すことと、UI をすべて C# のコードで書けることです。

この2つは、レビューで何を見るか、どんな変更を受け入れるかに直接効きます。先に知っておくと、関わるかどうかを決めやすくなり、PR が差し戻される理由も予想できます。

次は「Flutter の考え方を写す」です。

Flutter の考え方を写す

FloatSoda は、Flutter の Widget・Element・RenderObject という三つのツリーと、ウィジェットの語彙、そこから観測できる挙動を写しています。Flutter 由来の Widget と RenderObject は、明示された理由がない限り、Flutter と観測できる挙動を変えません。「実装しやすい」「こちらの方が自然」だけを理由にした独自仕様は受け入れません。

理由は、FloatSoda を使う人も、その人の代わりにコードを書く LLM も、Flutter の挙動を期待して書くからです。Flutter との違いは、バグでも意図した差異でも、利用者にとっては同じ手間になります。

写さないものもあります。C# や .NET として自然な表現への置き換え(event、init / required、record)は、挙動の差異に数えません。Semantics のように、移植しないと明示した機能もあります。

Flutter との差異を残すときは、今ある差異の台帳(known-divergences.md)に記録します。決定の記録(ADR)の置き場所と番号の付け方は、決まっていません。

三つのツリーが C# でどう写されているかは、1フレームが SteamVR に届くまでで読めます。

次は「UI をすべて C# のコードで書く」です。

UI をすべて C# のコードで書く

FloatSoda の UI は、シーンもプレハブも持たず、すべて C# のコードで決まります。コードに書けない状態(外部のアセットやファイル)を持ち込む変更は、トレードオフを検討してから入れます。

コードだけで UI が決まると、diff、レビュー、grep、LLM による生成がそのまま使えます。Unity の uGUI では、シーンとプレハブが text として扱いにくく、この点が使いにくさの原因でした。

想定している作り手は3種類です。

• LLM にコードを書かせて、自分用のツールを作る VRChatter
• Booth でオーバーレイを売る、Unity に慣れたクリエイター
• uGUI を避けたいエンジニア

1番目の作り手が中心なので、public API の合否基準は「更新後の docs だけを読んだ LLM が、その API を正しく使えるか」で決まります。

次は「この方針が決めている、関わり方の線引き」です。

この方針が決めている、関わり方の線引き

2つの方針から、関わり方の線が引かれます。現段階では、コアに受け入れるのは Flutter の basic.dart 相当のプリミティブ層のウィジェットだけです。Button や Card のような装飾済みの複合ウィジェットは、コアではなく、別パッケージやユーザーランドでの実装を検討してください。コードに書けない状態を持ち込む変更は、前の節のとおり、トレードオフを検討してから判断します。

ウィジェットの受け入れ範囲の正本は、CONTRIBUTING.md の「受け入れ範囲」です。このページには範囲を写していないので、変更を考えるときは CONTRIBUTING.md を開いてください。

次に読むページ

方針を読んだあとの行き先は、目的で分かれます。

• どんな貢献が助かるかを知る: どんな貢献が助かるか
• 手元で動かす: 開発環境を用意する
• 仕組みを知る: 1フレームが SteamVR に届くまで