Microsoft-ui-xaml: 提案:WinUI3の錆のサポート

作成日 2020年05月20日  ·  14コメント  ·  ソース: microsoft/microsoft-ui-xaml

さびはますます人気が高まっています。 すでにDirectX12を駆動できますが、フルスクリーンモードで、またはエンジニアがエンジニアのために作成したように見えるUIライブラリを介してのみ実行できます。 WinUI3で錆をサポートすることで、モダンで洗練された外観の錆アプリを構築でき、内部で錆のすべての利点を享受できます。 これにより、エンジニアとマーケティングが幸せになります。つまり、この組み合わせが商用アプリで実行可能になります。

feature proposal

最も参考になるコメント

winrt-rsは接続を確立できる可能性がありますが、必要な依存関係を取得し、Hello Worldが機能する明示的なwinui3-rsクレートを使用すると、はるかにアクセスしやすくなります。

全てのコメント14件

言語マッピングはすでに機能しているようです: https ://github.com/microsoft/winrt-rs

winrt-rsは接続を確立できる可能性がありますが、必要な依存関係を取得し、Hello Worldが機能する明示的なwinui3-rsクレートを使用すると、はるかにアクセスしやすくなります。

これは、 winrt-rsが安定していることによって(おそらく)ブロックされます。

参考までに@kennykerr

Rust winrtクレートは、 VS拡張機能NuGetサポートを備えたC ++ / WinRTに匹敵する、言語プロジェクションとパッケージングのサポートを提供します。 これらはすべて、今日Rust / WinRTによって提供されています。 すぐにいくつかのXamlサンプルを追加することが私のリストにあります。 Rustで独自のXamlコントロールの構築をサポートする方法はまだありますが、基本的なXamlアプリを既に構築することができ、完全な型システムのサポートを導入するために猛烈に取り組んでいます。

他に何を探しているのか聞いてみたいです。 これは、Xamlコンパイラが従来処理していた種類のサポートを提供することに関するものだと想像できますが、間違っている可能性があります。

私もこれが起こるのを見たいです。
さびはある理由でますます人気があります。 それは本当に良い言語であり、MicrosoftはWindowsの一部を構築するために錆を使用しているとさえ言っています。
rustを中心に構築されたアプリフレームワークがあると、c ++レベルのパフォーマンスが得られますが、コードがはるかに読みやすくなり、メモリのバグが少なくなります。

@kennykerr 「他の人が探しているものを聞きたいです。」
主な動機は、できるだけ錆びた状態でネイティブに記述されたプロ並みのアプリケーションを使用できるようにすることでした。 どういうわけか、優れた言語設計スキルを持っている人は、優れた芸術的なUIウィジェット設計スキルを持っている人と同じではないようです。 したがって、WIN UI 3の錆びたラッパーは、分裂を埋めることになります。 しかし、トリックを実行する必要があるが実際に実行する例がないライブラリがある場合、参入障壁は高くなります。 テクノロジーを結び付けるHelloWorldの例があると、より多くの人々が実際に飛び込んで、独自の派生物を作りたいと思うようになります。 個人的には、WINUIアプリ内のパネルでWINUI3とDirectX12を使用した錆の例が大好きです。 さびを学び始めたばかりの時も大変そうだったので、取り組み始めませんでした。

Rustでさらに多くのGUI作業を行うことを楽しみにしていました。 WinUIは、試してみる場所のように聞こえます

@kennykerr 「テクノロジーを結び付けるHelloWorldの例があると、より多くの人々が実際に飛び込んで、独自の派生物を作りたいと思うようになります。」

Hello worldは、UIを表示するのに十分です。 ToDoアプリの例は、いくつかの簡単な相互作用と、それらがどのように組み合わされているかを示しています。

.Net MAUIについての発表を覚えていますが、その基盤のどれだけがWinUIにあるのでしょうか。

私にとって、インスピレーションはvgtkと呼ばれるRustGUIフレームワークから来ています。
https://bodil.lol/vgtk/

このフレームワークの構文は、宣言型UIを構築するためのReactのjsx構文に大きく影響を受けており、そのプログラミングモデルは現在人気のあるMVUモデルです。

アプリを宣言するには、次のように記述します

fn view(&self) -> VNode<Model> {
    gtk! {
        <Application::new_unwrap(None, ApplicationFlags::empty())>
            <Window border_width=20 on destroy=|_| Message::Exit>
                <HeaderBar title="inc!" show_close_button=true />
                <Box spacing=10 halign=Align::Center>
                    <Label label=self.counter.to_string() />
                    <Button label="inc!" image="add" always_show_image=true
                            on clicked=|_| Message::Inc />
                </Box>
            </Window>
        </Application>
    }
}

これはjsxに非常に近いですが、WinUIに使用するのに最適なXAMLにさらに近いです。 rustのこの構文は、rustの手続き型マクロ機能によって有効になります。

このタイプのUIフレームワークは最近の傾向であり、WinUIの錆が成功するには、この列車にも乗る必要があるように思われます。 この種の作業は数え切れないほど行われており、MicrosoftがWinUI用に作成するのはおそらく非常に簡単です。 クロスプラットフォームのUIフレームワークにとっても良いチャンスかもしれません。それは、錆びたGUIコミュニティが待ち望んでいたことですが、それはこの問題の範囲外のようです。

また、XAMLには「部分クラス」のサポートが必要です。 したがって、UI要素にコントロールを追加できます。 Rustはこれをサポートしていますか? 手続き型マクロでそれを模倣できますか?

すべてのフィードバックをありがとう! それを続けてください。

@ suleyth -XamlAPIは部分的なクラスを必要としません。 これは、Xamlコンパイラが使用するC#言語の機能です。 C ++と現在のRustの場合、これらの言語にとってより自然な、まったく異なるアプローチを模索しています。 そして、はい、手続き型マクロは、Rustでこれを解決するための優れた方法です。 私たちはそれらをwinrt-rsで広く使用しています。

これに関する更新はありますか?
編集: winuiで錆をサポートするためのロードマップがあれば素晴らしいでしょう

WinUIチームについて話すことはできませんが、Rustのサポートの多くは、Rust / WinRT言語プロジェクション( winrt-rs )から提供されます。 特に、私は現在、RustでCOM型とWinRT型を定義および実装するためのサポートの追加に取り組んでいます。 これは、Xamlを完全に統合するための主要な前提条件です。 準備ができたら、RustでXamlバインディングサポートをより自然に点灯させる方法を検討し始めることができます。

このページは役に立ちましたか?
0 / 5 - 0 評価