WPF(.NET, WinUI) GUIプログラミング Part33 YouTube動画>3本

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512

WPF(Windows Presentation Foundation)について語るスレ。

前スレ
WPF(.NET, WinUI) GUIプログラミング Part32
http://2chb.net/r/tech/1694210576/

関連スレ
Windows 10 UWPアプリ開発Part 3
http://2chb.net/r/tech/1627556967/

コードを貼る場合は以下のサイトの利用をお勧め。
https://ideone.com/

---

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

WPFはオワコン

被っていけー！と叫ぶとできる。　

.NET 9の新機能を眺めてたらHybridWebViewなる新規コントロールがあって仕様を読んでみたらなんと
MSの.NET版(.NET Frameworkではない)Tauri実装と呼べる代物でクソワロタ
MSもやっとフロントエンドはWebで勝負着いてることを認識したよーやな
これはかなり期待できるわはよ触って見たいが変更多そうやからとりあえずRCか正式リリースしてからやな

Webviewの中は何をやろうが関知しないから
勝手に好きなライブラリーで書けや！って事？
笑

MSが主要なViewライブラリーとの
js<->c#のブリッジ用意してくれんのなら
それはそれで有用だな

WebView2をクロスプラットフォームにするって言ってたのに
音沙汰無いと思ったら新しいコントロール作ったんか。動けばなんでも良いけど。。。

Electronはともかく、TauriやWailsみたいな最近のフレームワークは
ファイルシステムやウィンドウの制御みたいな、
主要なネイティブ機能をすぐにフロント側で使えるようにあらかじめSDKで用意してくれてたり
Wailsはバックエンド側で定義した関数の型をフロント側にエクスポートして使えたり
かなり便利になってきてるから、その辺MSがやる気あるのか、コミュニティにぶん投げるのか

まあMS自らが今まで自分が作ってきたコントロールに一つずつ引導を渡すようなことにはなるけど笑

でもGoやRustよりはネイティブ層をC#で書きたいって層はいるだろうから期待はしてます

js側からネイティブダイアログとか呼び出せるApi用意してくれんのならスバラシイぞ！(*бωб)

てかデスクトップアプリのTeamsもwebview２実装してんだから一般公開するたけだよね->MS

webview2でもc#のクラスそのまま公開できるんだから簡単なラッパークラス作るだけじゃん

そのレベルでは無くて、Windowsの主要なAPIがSDKとしてHybridWebViewの初期化時にロードされて起動してくる感じ。なのでネイティブのWindows出すとかもろもろJSのコードだけで完結する事を想定。

今んとこ、SendRawMessageメソッドが生えてるだけに見えるけど、週末にでも触ってみる。
VS立ち上げるの久々だ笑

.NET 9の新機能にその機能がないのでおかしいと思って調べたら
HybridWebViewは名前空間がMicrosoft.Maui.Controlsのコントロールの話だった

今のところMauiの話でHybridと言うのはそういう話では？

そやから.NET(.NET Franeworkではない)て親切書いてやってんのにこのスレほんまにレベル低い奴ばっかやな・・・
MAUIの意味はMulti-Platform App UI(.NET MAUI)やぞ
そもそもマルチプラットフォームでWebとデスクトップでフロントやバックエンドのロジック共有させたいからHybridなんやが
話が通じなさ過ぎて頭くらくらするわ

簡単に質問するけどあなたは頭がおかしいのですか？

あなたは.NET Frameworkが何か多分勘違いしてると思います

もうこのスレで質問するんじゃねーよマウント取られた情弱が逆恨みしてレスバでスレが汚れるから他所でやれ

間違いに気が付いてもらえて良かった

まあ特に話すことのないオワコン技術の老人会スレなんだから
喧嘩でもなんでも好きにすればとしか

C#版Tauriって、別に現行のWebView2でも出来るんじゃないの？

Maui（Multi-Platform App UIやぞ！(略)）の新規webviewにwindows sdkのネイティブAPI呼び出しを期待するのは
根本的に何か間違ってると気が付いてくれたのだろうか？

>>19
Windows以外でうごかないやん
(以下ループ)

OSの上にOSのライブラリが乗っててその上にC#が乗っててその上にC#ライブラリが乗っててその上に各種OSのGUIを利用する層が乗ってて
その上にMAUIが載っててその上にwebviewが乗ってる
そこから何かtauriみたいな層のAPIを介してnative APIを叩く

このジェンガかパイプラインかミルフィーユのどこか一部が壊れてたら全部動かない
間の各層の責任者も違うので修正されるかも不明

早期の破滅しか見えないんですけど

そんなこと今更言われても・・・
機械語で書くわけじゃないんだからフレームワークの抽象化なんてそんなもんでしょ
すでにMAUIなんて破滅しかかってるんだし
動きゃラッキーくらいのオモチャとしか思ってないわ

単純なapache + CGIが正解か

別に破綻していないし問題なく使える
ただここはWPFスレであってMAUI(Xmarin)は関係ない

>>22
間違ってる

Webアプリで実装するというのは思考停止だと思う

何でもXamlの方が思考停止

Multi-Platform App UIやぞ！

ここはXAMLに捕らわれた者のスレなんだ
Reactスレ盛り上げろ

MS経営陣にまともなアーキテクトがいないのでずっと迷走してる
現場は失敗が目に見えるようなのをガンガン指示されてるんだろ

その結果真面目だが真剣ではない（昔よく使われたあれ）状態が続いてる

どてっぱらに大穴が開いた船でもう沈没するのはわかってるけど上からの指示で水を掻きだしてる
仕事だからまじめにやってるけど船を助けようとするレベルの真剣さではないわな

現場の人間としてはどうせこんなバカなプロジェクトはダメになるから勉強のために自分の作りたいコントロールを作る
報告のあった不具合のデバッグなんてめんどくさいのは後回し
さぼりはせず真面目に仕事はしてるけど何とか全体の完成度を高めてまともな業務に使えるようにしようと言う真剣さはない
嫌なことはチームリーダー任せ

外から見るとこういう状況

中の人 乙!

最近の.NET関連でちょっとググると
キータかなんかでMSの中の人が書いた、全然いいね付いてない記事しか引っ掛からなくて
可哀想だなとは思う
(もちろん記事があれば良い方)

>>34
マイクロソフトの公式ドキュメントを見てないのか？

URLと内容が紐づくものだけを見てしまうのは情報の探し方が間違っている。

やりたい事でググってアフィ記事すら出てこないのはエコシステムとして終わってるだろう
それを探し方が悪いとかどんだけおめでたいのか

公式マニュアルの内容をページ単位で公開していたら管理できなくなるわ

記事がみつからないということは自分の手段が間違えてるのではと推測できるわけで
その判断は概ね正しい

あぼーん

>>40
既にやってるよ

あぼーん

>>42
もうやってんだよな

いつのまにかVSCodeの拡張機能にAvalonia for VSCode Communityできたいたのね
まぁ入れてもコンパイルできなかったんですが…

VSCodeは開発環境構築が大変すぎる
コミュニティやドキュメントが整ってないマイナーフレームワークだと
ちょっと触ってみるかでどツボにハマるからVSのありがたみを実感する

eclipseのことか

PropertyChanged.FodyとCaliburn.Microの組合せが楽できて素晴しい
WinUI 3(+CommunityToolkit.Mvvm)も試してみたが.NETのままでいいやという結論になった
別に見た目を変えるだけならModernWPFもWPF UIもあるしな

windowsform経験者からwpf学んでくには、どんな教材が良いですかね。
とりあえず、udemyが気になってはいますが。

Copilotが今時の流れだよググるよりTabエンター
WPFのような枯れてる技術なら新しい話題が少ないのでAIで解決した方が速い

1から学ぼうって時には向いてないでしょ

それは逆
未経験のフレームワークを使って開発するなら新規案件で1からやるより既存物の追加開発から入る方がハードル低いだろ？
最初の一歩をAIに頼って足場を作ることで、最初のハードルは大幅に下がる

アンカを付けて会話してくれ

>>51
逆の人がいる！

意味不明なスクリプトは応用が効かないよw

AIは理解してるんだからAIに応用させればいいのよ人間が理解したいならそれもAIに聞けばいい

くずコードがデフォになってもだな...

残念ながら、今のAIが生成するコードは大半の業務系コーダーよりよほど高品質だ

wpfくらい枯れてるとAIも生成しやすいだろうね
Webフロントエンド最前線みたいなのだと
API変わってて動きそうで動かないみたいなトラップが増えたり平気でメンテされてないライブラリガンガンぶっこんできおる・・・

こないだ炎上してたZennの技術選定の記事は既に判断材料にAIが生成しやすいかが含まれてて興味深かったな

>>57
よほど低品質なコードを書く人たちに囲まれてるんだね

ネットから拾ってるだけだけどなw

難しい内容は、ChatGPTでは解決にはならないことが多い。

ネットに転がって無いものは答えられません

AIは乱暴にいうと平均計算してるだけ

>>55
AIはそれっぽく作るのが上手いだけで理解なんかしてない

統計的に頻度が高い=それらしい回答が上手なだけだしな

中国語の部屋的な？

流石にAIに関して今時その認識はやばいよ
職人堅気も結構だけど、10年後に路頭に迷わないように祈っておくことだな

>>67
お前が馬鹿なだけだぞ

まあ知恵袋ではAIのやってるのは平均や統計という結論になってるからそう思う土方が増えても仕方がない

>>64
ほんそれ
AIは小泉セクシーと同じタイプ

外注の粒度が劇的に縮小して作業者レベルに降りてきたってだけ
明快な指示を出せない人は適切にアウトソースできず（自分より割安なリソースを活かしきれず）、やがて淘汰される

プログラミングの文法は理解しているから俺より役に立つのは確かだ

今のLLMは流行り始めた頃に比べてコンテキストウインドウが大幅に拡大しているから、
指示の出し方よりもコンテキストとして適切な背景知識を十分に与えてあげることが重要になってる
既に人間より頭良いから、むしろ必要十分なコンテキストがあれば指示は雑で曖昧なものでもよくて、適切に意図を汲んで見事に仕事してくれる
もうすぐコンテキストの考慮も不要になって人間不要になるんだろうな

>>69
意味を関連で辿るタイプのAIはまだPCクラスじゃ無理だからなぁ

それが指示でないと言うのならもはや何も言うまい...

「10年後に路頭」

10年も余裕あるなら焦る必要ないだろ

>>72
平気でバグ仕込んでくるぞ
油断できない

バグありのコード書くのは人間に外注したって同じだろ
個人的に1番AIが便利に使えてるのは、既に完成しているコードのライブラリを差し替えたりライブラリ不使用に書き換えたりする、ゴールが明確で固定されてるが、それまでの道筋を変える、とにかく面倒な作業の肩代わり。これが1番得意。
あとはjsonやcsvの使い捨て変換スクリプト書かせるとか。変換前のデータと欲しい最終出力のサンプル突っ込むだけで何とかしてくれる

>>78
>既に完成しているコードのライブラリを差し替えたり
>ライブラリ不使用に書き換えたりする、
>ゴールが明確で固定されてるが、それまでの道筋を変える

GPLロンダリングですね判りますω

WPFどころかC#すらわかってないJavaScript初心者さんでもコパイロットがあれば
あっという間にハローワールドまでできるようになるじゃないか
依存関係プロパティもビヘイビアもあっさり解決さ

ビヘイビアは使わなくなった

言語としての最先端だよなあC#は
なんでエンジニアたちは他のゴミ言語なんか使ってんだろ

あくまでJava系(クラスベースOOP+静的型+C系文法)の中での完成系だからね。
まあJava系としてKotlinとどちらが上かは意見の分かれるところではあるが。
C#はどれだけ魔改造しようと今更TypeScriptのようなstructual subtypingベースの言語にはなれないし、
Rustのような厳格なメモリ管理をする言語にもなれないし、
Haskellのような純粋関数型言語になるのも不可能だ。
それらとJava系のどちらがパラダイムとして優れているかは分野や用途次第であり、銀の弾丸はない。

長年C#でJava勢と張り合って孤軍奮闘してけたけど
そのJavaも衰えて自分もTypescriptでUI書くようになって永くなり
今じゃTypescriptが凄すぎでC#でUI書きたいとはとても思えんようになったからね

C#をこれから学ぼうと思ってるんだけど、C#の強みってどういうところ？
自分はJavaもC#も経験がない (C++, Python は分かる) からまだ分かってない
C++, Pythonでもクラスは使うけど、C#やJavaの方がよりOOPな言語だと聞く
どういう所に違いがあるのか、それがいまいち分かってなくて

スレチだけど回答

言語自体の強みは薄い
最近の言語に慣れた人にはやぼったいと感じるだろう
タイピング量は多いし一画面に表示するロジックも少ない

強みはMSがバックアップしていると言うこと

>>85
無料で最強IDEが使えるのと1つ覚えるだけでなんでも作れるところ

Windowsデスクトップはもちろん、Mac, LinuxデスクトップもAvanonia使えば作れる
ゲームはUnity、Webは.NET Core、Blazor
モバイルも一応作れる

VScodeの事？

Visual Studioだろ

個人の場合はね
仕事でだとまず有料になるな

C#の一番の強みは、OS、フレームワーク、IDE、DB、等々全てMSが用意したものを使えばよくて、
雑多な周辺技術に惑わされて時間を無駄にしなくて済むこと
…だったんだけど、最近ではもはやC#の役割としてMSが本気で投資してるのってAzure上でのWeb開発だけになっちゃって、
もはや以前の万能言語の姿は見る影もない状況なんだよね
せっかく幅広いプラットフォームで使えるようになったのに、結局特定のプラットフォームに縛られた言語を脱せずに斜陽期を迎えてしまった

いるよね、こういう極論言い出すやつ

C#の用途はWindowsアプリとUnityだよ
他にもできることはたくさんあるけど他の言語に負けないのはこの2つ

Javaの糞性はメンテナンス工程で発覚する物が多いからなぁ

いつからC#は万能言語になったんだ？
少なくと複雑なUI実装にはまったく向かない

複雑なUIってのがCADとかDAWを超えているならWinAPIから作れや(^^)v

複雑なUIもC#は他を圧倒してるよ
UnityよりすごいUI作成ツールって他にないだろ

HTML

paint.netがwin32APIを直呼びしている時点でお察し

paint.netはGPUアクセラレーション使うから仕方がないでは
最新のVer.5.0ではレガシーなC++/CLIのコードをC#に置き換えてるそうだけど

非常に何とも言い難いね
自分もC# C++ハイブリッドでやってるけど非常にめんどくさい
でも速度的にメリットがあるので続けるしかない

一般的なコードで等価なコードが等価なバイナリになればいいけど無理だな

安全寄りの設計思想のC#が無防備なC++に近づくのは限界があるわな
とは言え、最近の.NETは高速化に力入れてて.NET Frameworkと比べると結構速くなった

C#もSpan<T>とかSIMD叩けるようになったりして久しいし.Netのバージョンを指定できる環境ならそれなりに高速動作するのでは？

WinUI3がAOT実装したのに話題にならないね
ちょっとした高速化以上に今まで悩まされた難読化が標準になったのにさ

進撃の巨人はオワコン

winUI３のdatagridでitemsourceに指定してあるObservableCollectionを変更しても画面が更新されない…
セルを更新したときに下のセルが空欄なら同値で埋めたいんだけどObservableCollectionの値は更新されてても画面が変わらないのはどうすればいいんですか？

>>106
ObservableCollection<T>のTにもINotifyPropertyChangedの実装が必要

複雑なUIを妙なスクリプトで対処するなよ
改修大変なんだわ

WPFはCG以外の各種コントロールもDirect3Dで描いてんの?

CGの定義はともかく、今のWindowsはWPFとは無関係にほとんど全てをDirect3Dで描画している
WPFは更にその上で無駄な抽象化レイヤを幾重にも重ねてDirect3DやCPUで描画しているので極めて非効率

WPFはDirect3D9のラッパー
そしてこれがWPFがWindows以外の.NETで提供されない理由

むかしsilverLightがあったじゃん
あれはどーーなの？

xamlはスクリプト言語で、C#に変換さるるんじゃなかったっけ？

されない。等価なバイナリデータに変換された上で、C++で書かれたランタイムがそれをレンダリングする。
ただしXAMLの最古のレガシー実装であるWPFについてはXAML処理系はC++ではなくC#で実装されており、パフォーマンス上のボトルネックとなっていた。

silverLightは息してない
即死

PRキャラの光ちゃんを助けて

>>111
silverLightは >>111 に対する話し

>CGの定義はともかく、今のWindowsはWPFとは無関係にほとんど全てをDirect3Dで描画している
WinFormsも?
テキストボックスもDirect3Dなんだ。なんか面白いな。

逆にWindowsでパフォーマンスの良いGUIフレームワークとなると何が候補になるの？

React

WebView2やElectronでReactを使うのが最良だろうね。メモリ消費量は多めだが複雑なGUIを極めて高速に描画できる。
WinUI系は迷走しまくってるからお勧めできない。

Reactが高速w

webベースは却下

Tcl/Tk

>>123
なぜ？

10年後に動くとは思えない

WPFはね

VB6.0もWinformsもWPFも公式にしろ非公式にしろ10年後も動いてると思うたぶん
ソースがあればビルドもできると思うたぶん

でもElectron上のアプリが10年後も動いてるかと言ったら…
そもそも10年後にビルド環境を用意できるかどうかとなると極めて怪しい

そりゃ思い込みだな
ReactとElectronのリリースは11年前、最も成功したElectronアプリであるVSCodeもなんと9年前だ
SPA系のモダンWebも実は既に十分に枯れた技術なんだよ

WPFでSkia使えばめちゃくちゃ早いが。

>>129
いや言ってる意味がわからないならいい

>>129
11年前のコードがそのまま動くとでも？

たまにVC++6.0使っとるが。

VB6.0のように動かすだけならできるだろ
何が極めて怪しいんだ

あと10年経つと文字小さすぎて読めないとかボタン小さすぎて押せないとか言われてると思われる
ViewBoxなんてカレンダーコントロールにしか使ってなかったが、対処療法には使える

VB6.0が動くの正確な意味って解像度とか作成時の状態を踏襲した上でって意味だろうに
なんでそれと同じ条件で語らないんだか

>>134
普通に無理やろ
VB6はruntimeが脆弱性対応で更新されてもそのまま動くし既存のOSが生きてる限りサポートされることが約束されてる

Reactのホスト環境はそうはいかない
ホスト環境やReact自身の更新に追随して変更していかないと使えない

環境を凍結して動かすだけならハードに問題ない限り動かせるけどそういう話じゃないだろ？

もういいよ react の話は

>>137
Reactのホストって何よ
基本クライアント側だけで動く機能だぞ

>>139
JavaScriptがホスト環境無しには動かない言語なのは知ってる？

ElectronはChromiumを丸ごとバンドルするんだから全部塩漬けにするなら10年後でも普通に動くだろう
セキュリティパッチ云々はまあ.NET Framework の方ならわかるが、
5以降ならクライアントアプリは全部バンドル塩漬け前提になってしまってて、
後生大事にセキュリティ更新だけ当て続けるような運用はもはや不可能なんで、
状況は大して変わらんよ

JavaScript界隈は数十年前のDelphiのEXEやランタイム糞でか問題を現在進行形でまだやってるんだよな
ブラウザ側に金玉握られてたらエンジンごと抱え込むしかないよなあ
ほんと頭悪いわ

htaが神過ぎたな

>>142
.NETも今はCLRから何から全部抱え込むのが基本よ

AvalonEditが高速で気に入った
1メガ位のテキストをTextBoxに放り込んだら重くて大変だったけど快適になったわTextBox使えないわ

今からWPFを勉強する際におすすめの参考書やWeb資料ってある？

ないよ

WPFはすでに終わった技術で行き止まりみたいなものでMSもそこを広げていこうとはしてない
新たに入ってこようとする人間もあまりいないので書籍がない
説明資料もない
素の状態では使いづらいのでライブラリを使うけどそのせいで人がばらけてる
それもずっと研究段階で絶対こうしたほうがいいと言う統一した使い方がない
過去のweb資料も時代遅れになっている

他の言語したことあるならネットの情報だけで学べるやろ

WPFと言ってもWinFormsとかわらんし。
XAMLはテキトーにサンプル作ればその内わかる。
(最初はポトペタでもいいと思ってる)

データバインドはWinFormsにはないけどバインドする必要もないし。

https://qiita.com/inf102
qiitaにはそれなりにある。

MVVMパターンやデータバインディングにこだわりすぎるとハマる

データバインディング、テンプレート等とWPFのMVVMは分けて考えるべき

初学者には絶対無理だけど

非MVVMのWPFが自分的にはサイコー。
50-60人～　の大規模での開発なければMVVMの恩恵はない。

mとvmの境界が分からない
IPropertyChangedがあればvmになるの？
Commandの中身はvmじゃなくてmに書くべき？

難しく考える必要はない。
VMの仕事はMの状態をビューに反映させることと、Mに対して何らかのコマンドを送出すること、それだけ。
コマンドってのは例えば梱包済み商品の発送処理を開始せよ、みたいなやつね。
発送処理開始ボタンが押されるとVM上のイベントハンドラが実行される。
なお、MVVMではこのイベントハンドラをコマンドハンドラなどと呼ぶことがあるが、上記のコマンドと紛らわしいからここではイベントハンドラと呼ぼう。
そして、イベントハンドラは関連するパラメータと共に発送処理クラス(これがMに相当)の処理実行メソッドを呼ぶ。これがコマンドの送出だ。
そしてVMはメソッドの戻り値等を介して「発送処理中」ステータスに更新された受注情報のリストを受け取り、その内容を自らのプロパティに反映する。
結果として、画面上の受注情報のステータスが更新されることになる。
泥臭い話と思うかもしれないが、君の憧れるMVVMやドメイン駆動といったアプリケーションアーキテクチャのキラキラワードの実態は本来こういうものだ。

別にMVVMを全部コードで書いてもよい
これからわかることは...

WinUI3 でバリデーションエラーをTextBox に表示するのってどうやるの？
INotifyDataErrorInfo はあるし
VisualState にもそれっぽいのあるからできると思うんだけど。。

「ViewModelはViewのための橋渡しをするだけで、他のロジックはModelが持つ」と理解したんだけど、例えば以下のような感じ？

数値カウンターアプリを作る場合にCounterState みたいなモデルを用意して、「現在値」というプロパティと、インクリメント/デクリメントするためのメソッドを実装する
ViewModelはそれを画面の表示やボタン動作に紐付けるために、「現在の値」というプロパティと、ボタン押下時のコマンド (内部的にモデルのインクリメント/デクリメントメソッドを呼ぶ) を定義する

……といった具合の実装をMとVMとで行うと理解したんどけど、合ってる？

役割は違うけど、VMとMとで同じプロパティを書く冗長さがある感がする
INotifyPropertyChangedみたいなWPF特有の知識をModelに持たせない、という考えは納得できる

こういう不毛な話を20年続けてる

ましで

>>153
変更イベントでTextをintに変換とかいちいちしてるの？

>>158
それで正しい
面倒ならCounterStateを完全にイミュータブルにして、そのインスタンスを直接プロパティで公開してしまえばいい
それならCounterStateがINotifyPropertyChangedを実装する必要はなくなる
その方がReactなんかのモダンWebアーキテクチャに近い今時の構造になるが、WPFの場合は更新時にモデル全体を差し替えるようなことをすると更新範囲が広くなっちゃうからパフォーマンスは犠牲になる

PropertyChanged.Fodyも[ObservableProperty]も使ってないって情報古すぎる
今時手書きはないよ

質問者が問題視しているのはプロパティの重複とWPF特有の要件をMに持ち込むことだから、
それらのツールは何ら本質的な解決にはならないでしょう

xamlってWidth＝{Binding Path＝vm.Width×0.9f}
みたいな形でバインディングプロパティを加工出来ないのがつらいよな
Converterあるけどあれだと0.9fとか0.5fとかいろいろなサイズに対応するために複数のコンバーター作らないといけないし

WYSIWYGなGUIビルダーが前提の時代遅れな設計だから仕方ない
Reactなら普通に式書けるが、ああいう手書き前提のアーキテクチャではビジュアルデザイナを実装するのが困難だ
業界がまだRADの幻想に囚われていた時代の遺物よ

>>165
ConverterParameter

今からデスクトップアプリは何で開発すればよいの？結局、未だにWPF？

Tauri

WebベースならElectron、Tauri、WebView2あたり
Webが嫌なら、もはやWin向けではMS謹製となった React Nativeだな

>>168
簡単な奴ならWinUI3でいいけど業務アプリとかガチめのやつはWPFが安定

>>167
ありがとう
こんな機能あったんだね

>>172
あとConverterにプロパティを書いておくと、x:Keyと一緒に指定できるよ

Web系ならGo製のWailsという選択肢もある
Tauriよりもビルドがだいぶ早い (RustはC++と同様にビルドが長くなりがち)

ただしElectron等はWeb系のフロントエンドの知識 (TypeScriptだったり、フレームワークやCSSだったり) が必要だから、C#に慣れてるならWPFになると思う
自分は試したことないけど、Avaloniaも評判は良さそうに思える

Webベースで作る時に、見た目をWindows風にするスタイルシートってある？

>>175
Webならなんだって出来る
https://paradoxepoch.github.io/win11-css/

>>175
こっちだったね
https://github.com/Laaouatni/w11CSS

それこそReact Native使えば？
UWPだからWindows風どころか正真正銘WindowsネイティブUIよ

>>177
開発止まっとる

Webなら格好いUIつくれんのに
Windowsの古めかしい方に寄せるのは何故？

>>180
客に「違和感がある」とか文句付けられないようにするため

Windowsアプリなんだから格好いい悪いじゃなくて他のWindowsアプリと揃えなきゃだめだろう
まあネイティブとWebViewだとテキストボックスの挙動すら違うんだけどな

windowsのアプリとかみんなバラバラじゃん、OS周り以外は

ダサくて使わないけどfluentUI
https://react.fluentui.dev/

そろそろスマホでもアプリの時代が終わりつつある
些細なことでアプリを入れたくないと言う心情は理解出来る

スマホに100以上アプリ入れてどこに何があるのかもわからないし要らない通知ばかりされる

アプリはもうすぐ死ぬ

サービスは主要なインフラアプリに統合されて
ツールはツールで残る

Material UI: https://mui.com/
Ant Design: https://ant.design/

react nativeってopenGLとかopenCV使える？

>>183
リアクトのfluentUIダサいよな
WindowsのfluentUIはそこそこかっこいいんだが
単純にアクリルがあるかないかの違いかもだが

Blazor HybridでFull C#がいい
TS/JSのエコシステムを組み入れる必要がないから
MSスタックで長くやってきた会社には向いてるはず

いくらMSどっぷりといえど、HTML/CSS使えるのにJSできないというのは考えにくいでしょ
そもそもMSってなんだかんだJS大好きだしなあ

そもそもGUIってのはアプリごとに操作を覚え直さなくていいようにパーツを統一するところから始まってるわけで
WindowsもXPぐらいまではかなりのレベルで統一されてたはずなんだ…

Webアプリが主原因だけどWPFアプリの見た目がWin32とちょっと違ったのも一因だよな…

>>191
そりゃないね
VSCが馬鹿でかいボタン集めて作られてもかなわんからな

VSCode含め、最近では不特定多数向けのGUIアプリって基本的にMacで開発されているものが多いから、
Windowsの作法なんてそもそも開発者の眼中にないんだよ
Macはむしろ伝統的にWin以上にOS側でUXを統一する思想が強かったわけだけど、Apple陣営としては開発者の取り込みのためにはWeb開発者に迎合せざるを得なかった
そして結果的に当のApple陣営の存在がアプリの独自UX化を強力に助長してしまったというのは皮肉な話だ

Avaloniaってどうなの
Blazor Hybridとどっちがいい？

個別のアプリと言うもの自体が死にかけてるからなんでもいいんじゃないかな
今がピークで本当にマルチなGUIはドンドン必要なくなってくると思うよ

ここってWPFかWinFormsしか使えないジジイたちが時代についていけずアレがいいのか？コレがいいのか？と右往左往するスレだよな

>>193
言うてMacOSは今でもOS標準アプリは一貫した作法のままだしな
標準アクセサリですらまるでバラバラなWindowsは格が違う

>>196
色々な技術が乱立していて自分で主体的に取捨選択しなきゃいけないのは決して今に始まったことじゃないんだけどな
お仕着せのMSスタックに身を預けることしかしてこなかったジジイたちが、ここにきて遂にMSに梯子を外されてしまい右往左往している構図

梯子外しって何のこと？
今も現役だし、サポート終了の話が出てるわけでもないぞ
新機能が追加されるようなことは無いだろうけど

MS的にはUWP→WinUI3を追いなさいと言うことだけど
それもネイティブアプリ自体が死にかかってるので微妙

ネイティブアプリ作る案件は
あってもモバイルだけだかんな

UWPは将来性危険なので避けたいな

>>184 >>201
ネイティブアプリから、Webアプリに変わってきているということ？

>>203
トレンド的にはそう
とはいっても、一般ユーザーの目に入りにくいだけでデスクトップアプリの開発は今も普通にあると思う
エンタープライズ系だったり、CADや解析ソフトだったり、計測器の制御だったり

んでその一般向けのモバイルアプリ開発ももう多分徐々に下火になってくる
この前どこかの市で1億3000万かけてモバイルアプリ作ったけどインストールしたのは400人ってニュースがあった

特定の案件以外はweb+ＬｉｎｅやＸですませばいいんではないかと…そういう流れになるはず


一般人はスマホに入れてるアプリは50ぐらいらしいけどそれでもうアップアップ
各種スーパーやドラッグストアに行くたびにアプリ入れてたら10個ぐらい入れてる
コンビニはまた別
それ以外にもレストランやファミレスとか回転ずしとかのアプリが合ってアホがどんだけ囲い込みしたいんだよと思うわ

ああいう会員アプリの目的は囲い込みではなく顧客の識別と購買情報なので、入れておいてくれるだけでいいんだよ
Webだとセッション切れたらITリテラシーの低い一般人は高確率でパスワード忘れて再ログイン不可になる

>>206
アナタのITリテラシーも疑問符ですよ

>>203
業務系のシステムとか10年以上前から全部Webだよ
ネイティブアプリをリッチーアプリと言っていた時代はまだWebと棲み分け出来てたけど今やもう昔話だ

業務のシステムをネイティブで作る意味なんてもうないもんな
スマホやタブレットに後から対応なんて考えず最初からWebでいい

残るのはツールぐらいかな

ネイティブアプリの存在意義はWebじゃ厳しいからだったけど
もうそのケースがほとんど無くて
逆にインターネット上のアプリやリソースとシームレスに連携出来なかったりで嫌がられる時代よいま

>>196
なんだReactだのVeuだので争ってるWeb系と一緒かw

デスクトップも結局RestAPIやりとりすれば何ら問題ないんだけどね

いやいや生粋のデスクトッパーにRESTは要注意だぞ
あいつらクライアントへのプッシュのためにクライアント側がHTTPサーバーを兼ねる設計とか、とんでもないことやるからな

1億3000万のアプリがクソしょぼいと言う…中抜きか？

>>212
Web上にアプリが無いので各種のバラメータをブラウザー経由で受け取れないし
そもそもシングルサインオンしてないので認証とおってなかったり
連携の時の遷移先はWebアプリなわけで大変だし、遷移先のアプリから返却値受け取れないわで大変よ

人類はHTTP以外の通信プロトコルの経験を失ってしまった

ロストテクナナシーのスレへ

>>215
別にブラウザ経由で受け取る必要なくね？
Jsonでのやり取りで充分じゃね？
シングルサインオンもPOSTの時JSONにアカウント情報載せてやればサーバー側でチェックできるだろ

実際クライアント側へのプッシュ通知って結構面倒だけどね

MSが最後まで梯子を外さずに残すGUIフレームワークってVB6になると思う
そうなるのが何年後かはわからないが

ComCtrl32よ、永遠なれ！

>>220
ActiveXコントロールは2025年10月までと発表されているぞ？

>>218
そのSSOのアカウント情報をそもそもクライアント側でどうやって取得するのかって話
DBユーザーのuser/passやDBのテーブルに格納されたuser/passじゃなくて、Google、Okta、ADのような外部のIdPで認証するのは流石のデスクトッパーでも知ってるよな？
IdP側でM2M用のキーを発行する手もあるが、セキュリティリスクが高いし運用的にスケールしない

Webブラウザの方が偽装しやすいこともわかんねえんだろうなw

偽装って具体的にどんな攻撃を想定してる？

>>225
多要素認証が必要になる理由を考えたことがないのか？

>>222
30年も使ったから
そろそろ賞味期限が切れたのでは

>>225
WebブラウザはOSやハードウェアの情報を正確に取得できない
セキュリティ上の問題

httpで外部からリモートアクセスできないように対策をし続けていまに至る

Webブラウザからアクセスしているように偽装するのは簡単

>>227
そうじゃなくて古いもので作られている業務システムが多いから。

Macみたいにシェアが低ければ簡単に切れるが。

昔から海賊版だらけのデスクトップアプリはセキュリティ問題ないのか

https://blogs.embarcadero.com/ja/native-windows-is-back-to-center-stage-ja/
MFCまさかの復活か!?

笑

RAD Studioか
Delphiは好きだけども…

俺には2021年の記事に見える

今年が2024年だということもわからなくなった高齢者なんだろう

意外とデスクトップアプリでもWebView+Blazorで開発してるアプリあるなぁ
DevToysってやつ見た目WinUIそっくりでもWebView使ってBlazorでUI構築してるみたいだ
https://github.com/DevToys-app/DevToys
https://apps.microsoft.com/detail/9nbn8w1ds547?rtc=1&hl=ja-jp&gl=JP

Win32だとコモンコントロールを使わなくても同じような枠線を引くAPIがあって
ちゃんと作ってればOSのバージョンアップに伴って見た目もある程度自動で連動できてたのに
最近はOSのテーマに追いつくのはアプリの責任になっててひどくない？

この時代、ゴミみたいな単価でそれなりに見栄えのするデザイン作れるデザイナはいくらでもいるし、
それを寸分違わず実装するのも(WPFはともかく)今時のテックスタックなら大した工数じゃないからねえ
悲惨なUIにならないようにOSがお膳立てしてあげないといけなかった時代は、(業務ドカタ開発を除けば)終わったんだよ

wpfのテンプレート無効にしてまでカスタムしてる変態もいるんだぜ

日本人は同じ見た目でないと怒り狂う変なやつが多いしな。

主語がでかい

XPのガキっぽいのはヒデーなと思ったけど
8や10の視認性の悪さを体験すると評価が変わった

昭和賛美はジジイの始まり

2000が最強
Meはゴミ

NT4でOSとしては完成してたね
VB6.0もコレを対象にしてて、いまだに一部業界で稼動中
これらに比べたらWPFはゴミ

MVVM作ってみた

めんどくさいな

あんな作法に惑わされ過ぎ
工数が嵩むばかりで何のメリットも無い

ユーザーが入力した値の検証や表示用に変換が必要な場合には向いてる

そんなんMVVMじゃなくても出来るし
一度作ったらそれっきりなんだから
意味が無いんだよ

MVVM便利だけどな
やっぱ層が分離されてるって気持ちいいよ

俺はMVVMSを提唱してるけど
Mはもう構造体だけにしてSでMを加工しVMに情報を与える
SはサービスのSね

TextMateSharpっていうTexMateという一般で広く使われてる規格からシンタックスハイライトを作成するライブラリを使ってWinUIのRichTextBlockにシンタックスハイライトを実装するライブラリ作ったんだがこれってライブラリ化とかした方が良いかな？
プログラムは単純にTextMateSharpのデモをパクってRichTextBlockに合うように呼び出しを変えただけなんだけど
ふつうにGitHubなんかにサンプルとして投稿する感じがいいのかな？

>>251
なんか、
やりたくで作ってるだけじゃなく、
必要になって作ってるわ

MVVMの

Prisｍだかは無しで

>>253
Prismみたいなフレームワーク使わないとめんどくさいだろうなぁ
個人的によく使ってるのはMVVMToolkitだわ
CommunityToolkit.MVVMのNugetで使えるようになる
確かWPFでも使えたはず

vue.jsとかのMVVM知ってると
WPFのはあまりに馬鹿らしくて泣けてくるぜ

>>255
すまんVue.jsやったことないんだけどどのへんがWPFがクソなの？

全部って感じ...
他はMVVMにかかる手間なんて一切無い

ので話題にも上がらない感じ

>>257
いやわからん

そも、VisualStudioって、MVCモデル用だれ？

>>258
糞って事

>>260
例えば Vue.js の MVVM でここが優れてる！
ってのはどんなのがある？

>>261
全部

ただ Vue.js 言いたかっただけなんじゃないの？

なにも生産性の無い話題だったな

MVVMToolkitはマジで記述クソ簡単になるからオススメ
一応Microsoft既製っぽい(実際はコミュニティで作ってる)しパフォーマンスもPrismより良いらしい

>>265
ほう
使ってみますわ

内部の仕組みとかは気にしなくてええの？
不安だわ

>>266
Prismとか、
使ってええもんかどうか…

なんかこのスレにはwebやれよの人が住んでいる

>>267
Prismは必要以上に肥大化して複雑になっちゃったから手を出さない方が良いと思う

CommunityToolkit.MVVMは後発なだけあってシンプルで分かりやすくて良いよ
これがもっと早くにリリースされてればWPFのMVVM嫌いをここまで量産しなかったかもしれない

>>266
ソースジェネレーターってやつを使って実装を簡単にしてる
詳しくはこれを参考にされたし
https://qiita.com/MAUIHighSchool/items/ed6a90b81cb849a9148e

機能を詳しく説明してる記事はこちら
https://qiita.com/kk-river/items/d974b02f6c4010433a9e

>>269
あー
初心者だから大変だわ

とりあえずToolkitでさっきから作り始めたわ

>>270
とりあえずToolkitでさっきから作り始めたわ

何も無しで自力作ったWPFアプリケーションをToolkitに移植してるけど、
仕組みがよくわからんわ…

>>272
まあ、
自分で書くソースコードは短くなるな…

>>272
普通こういうのはプロパティの値が変わってもUIに反映されないんだけどINotifyChangedって言うプロパティの値が変わったら自動的にUIに反映させる実装を裏の方でしてるだけ
MVVMToolkit使わないならわざわざその処理を手書きで記入しないといけないところをMVVMToolkitは裏で自動で実装してくれるわけ

その裏で実装されてるのが
>>270この記事の終わりの方にあるアナライザーのところに勝手に作られるコードってわけ

>>274
そうだね

INotifyChangedとか書いてたわ
だいぶ短くはなった

>>257
>他はMVVMにかかる手間なんて一切無い
>
>ので話題にも上がらない感じ

WPFについても同じように思っている人はいると思う。一切無いとまで言い切ることはしないが。
自分はそれほど困ってないが、ちょくちょくWPFをディスりに突撃してくる変な人がいるなあ、という感想。

>>277
>>WPFをディスりに突撃してくる変な人

以前WPFに人生投資してた人でお節介ながら警告してくれてんじゃないの？自分もそうだけど

で自分はWPFに関してはMVVMだけなら単純なバインディング機能とコードビハインドだけでもっと簡単にサクッと書けんじゃないのと思ってる

諸悪の根元はMicrosoft Expression Blend系機能に代表的されアンチコードビハインドの原理主義

MicrosoftがMVVMの為に言語を歪めてコンパイラで特別扱いする勇気があれば、最初からもっと簡潔に書けていただろう
なぜ素のC#で書かせたのか

>>278
そんなのは過去ログやWEBの評判みりゃ分かることだし、要らぬお世話だよ
何度も長々と同じ話してて、邪魔にしかなってない
それに今は以前と比べてかなり簡単に作れるようになってる

>>279

自動プロパティにget set init 以外に　bind set付けるだけなのになあ…

考え方が根本的に間違ってんな

VSエクスプレスでコミュニティツールキットMVVM Ver.8以降を使う方法ってありますか？

てか、何でコードビハインドがダメなのか

テスタビリティが低いから
GUIフレームワーク込みじゃないとテストできなくて自動テストとの相性が悪い

双方向バインド、テスタビリティ、宣言的UIがMVVM三種の神器

どれも必要ないならMVVMは無用の長物

流行りなだけで単純なアプリ作るだけなら不用だしなぁ

ViewとModelで、
独立して開発できるって認識で合ってる？

まあ、本格的に企業で開発してみないと実感がないな…

モダンUIフレームワーク視点から捉えたMVVMの現在地↓

「SwiftUIでMVVMを採用するのは止めよう」と思い至った理由
https://qiita.com/karamage/items/8a9c76caff187d3eb838

>>289
Modelを全部ObservableにすればVMは不要である
と読めた

何年か前にそれを見たような気がするけど呪文が多くて別物だと思った

GUI部分は宣言的にコード書くのは楽なんだよな
書いた通りにしか動かないから

書いて無いのに動くプログラム。怖すぎ。
コックリさんか、小人さんが補完するのけ？

>>289
本質はただの言葉遊びにしか見えんね
VMを別の言葉で言ってるだけ

なんか余計なコード書かなきゃならあかん事が増えて
かえって工数が嵩んでるって思うわ

意味不明瞭な変な用語を使いたがるキチガイどものいつもの会話

XAML+双方向バインディング
VS
コンポーネントベース+単方向データフロー

それぞれ切っても切り離せない関係にあると思うが、MVVM云々よりこっちの方が古今の開発体験の差になってるように思う

XAMLは単一方向フローでもいけるだろ
当時はXAMLのパフォーマンス改善の方策の一つだったぞ

winui3ではx:BindとBindingで違うね
Bindは静的バインディングでモードを1回だけ、単方向、双方向で変えられる
毎回指定しなきゃいけないの面倒だけどね
Bindingは動的バインディング

マテリアルデザインの5.1って動きます？
4.9までは動いてたんだけども、見つからなくなっちゃった
App.XamlでMaterialDesign3.Defaults.xamlに変更したりしたけども、見つからない
動かすだけなら4.9に戻せばいいだけなんだろうけども

動くよ
App.XamlでSecondaryに書き換えるとこもある

MS自体、小規模ならMVVMは使う必要ないと言ってる。

大規模もよ
時間の無駄の倍々ゲームになる

>>301
どこで言ってるの？

C#の入門レベルの本だといまだに「WinFormでアプリを作ってみよう」という例が書いてある印象はあるよね

「UWPでアプリを作ってみよう」よりかは需要のある知識

入門ならWinFormsでええやろ

高DPIも対応したしwinformsは手軽にGUI作れるフレームワークとして今後も有力だと思う

https://github.com/dotnet/winforms/pull/11857
dark modeもやってくるしなw

>>305
たしかにw

WPFのHiDPI対応は何も考えなくてもできるけど、
WinFormsのHiDPI対応は難しすぎる

WPFに比べてWinFormsは敷居が低い。ま、x:name使えば大差ないけどな。

>>311
MVVMとかやんなきゃ
変わんねーーだろ

やだナニコレ・・・素敵なんだが
https://x.com/AvaloniaUI/status/1849818682077458915

これが最新のMacOSで動くというのがシュールすぎるｗ

めちゃくちゃ懐かしいw

こういうのでいいんだよこういうので

>>316
良くないだろw

そいやvscodeのavaloniaの動くようになっていた
VisualStudioでやればいいんだけどさ

AvaloniaStudioとかいうVisualStudio風味のIDEがGitHubにあるな

WinUI3のコントロールの中にWindowsTerminal組み込んで見たの図




こいつにディレクトリのツリービューとか追加してダブルクリックでそのアイテムのパスをコピペするようにしたりコンソールアプリのパスを登録したリストビュー作ってその中からアプリを選んだらそのパスがコピペされたりとかになればコンソールもだいぶ使いやすくなるぞ

そんなもん適当なコマンドランチャー使えばいいでしょ

>>321
コマンドランチャーってコマンド引数入力できるの？

VzEditorのファイラー便利だったな

コンソールの親ウィンドウを設定しただけに見える
ネタなら前にあったLINE風のコンソールのが面白いね

>>324
そうそう、Process. Startしてウィンドウハンドルを取得
DllimportでSetParentしただけ

ただWindowsTerminalの設定をそのまま引き継げるしタブも使えるしなかなか便利だ
ツリービューからパス選ぶのもいったんクリップボードにパスを文字列で入れてsendinputでCtrl+Vを入力してるだけ
超お手軽で色々応用が効くといったもの
個人的にターミナル使う時わざわざエクスプローラー起動して～右クリックでパスコピーして～ってやってたからこういうのあれば個人的に助かるってやつを作ってみた

「ターミナルで開く」

最新のc#で作るならどれ？wpf？

windowsだけならWPF
クロスプラットフォームはAvalonia

Blazor

UWPやMAUIって現状どうなん？
C#でのGUI開発だとWPFの方が名前が挙がるけど、これは単に移行が進んでないだけ (可能なら移行したいとは思ってる) なのか、WPFの方が安定してるなどメリットがあるのか

UWPは今後も無いな
WinUI3やMAUIは完成度がね…

React
はいもうこの話は結論付いている
MicrosoftですらReactを使っている

「C# で作るなら」って書いてあるのが読めないの？

仮にWeb系技術だとしてもなぜReactだけ？

で、
業務アプリケーションは何使われてるの？

業務なら普通にWebよ
と言うと、外部機器の制御などでデスクトップアプリの必須な分野もある、といった反論があるだろうが、
そういう分野の連中って結局何やってもWinFormsから移行しないからMSはもう投資してないよ

いまどきの業務アプリなんて生成AIでノーコードなんじゃないの
逆にC#の出る幕なんてあるの

>>338
はやく生成AIで業務アプリ作って公開してくれよ

>>339
アシスタントにAIは普通なってきましたよ
因みにC#でもアシストしてくれると思います

>>340
話がずれすぎ
生成AIでノーコードで業務アプリ作れることを証明しろって話

SilverLightでもええで～♪

>>337
Webやってないのは進歩しない人間と言いたい十年一日のような議論

個人開発ならまだしも、プロジェクト毎の技術選定において「決定権」を持つのは開発組織の上位層であって、多くの技術者ができることはいわゆる「提案」に留まる

日本で下手に提案したら責任もとらされるからね

ワールドワイドウェブなのにWebブラウザの仕組みの話になっているのは知識がなさすぎる。

いまはWebアプリケーションはSPAだらけで、Webブラウザの基本的なプロトコルでもはや実装していない。

JavaScriptは基本的な機能じゃないからね

SPAはHTTPで通信しないのか？

>>348
初回アクセス時にjsのソースをローカルにロードしたら以降は全部ローカルで動作する（なのでサーバーアクセスも不要）

初回アクセス時にローカルストレジにキャッシュも出来るので、そうすると起動時のサーバーアクセスすら完全に不要になる

こうなるとWebアプリじゃなくて実質クライアントアプリだね

データをローカルストレージに書けるようになったらそうだね

随分まえからあったような

オンラインとオフラインで動作を変えてる
オンライン接続されたたローカルで作ったデータを鯖に送ってアップデートする

それが最低限の挙動

>>352
軽く言ってるけど、データの整合性とかはどうやって担保してんの？

状況に合わせて適宜ルール決めるだけ

>>354
そのルール作りが大変だろうが。下手なルールだと不整合がバンバン起こる。
それにそんなんが可能な業務も限定的だろが。

>>355
恐らく個人的なアプリではないのかな？

何にでもケチをつけないと気が済まないんだなとしか…実際に実装されてるし一般に売られている本などでも実装手順は書かれている
大変だろうが。で終わる話ではないんだけど

そもそもがオフラインの状況自体がかなり限定的で
その状態でどの機能を有効にするかを取捨選択するのかは顧客と話し合って仕様決定する
それが仕事の人がいるので決まった仕様に沿って実装するだけなんだよ…

「だけ」と軽く流して具体性に欠ける回答だから突っ込みが入って当然だろう
こういうのは何でもケチをつけるには当たらないと思う

具体的に説明しようとしたら、こんなところの数行のやりとりで終わらせられるような話では無かろうよ
で、ここはそれに適切な場なのか？

何にでもケチをつけないと気が済まないんだなとしか…

オフラインでしか使えない状況でも使いたい場合もあるでしょう
山奥の家で保険の更新とかだと電波なんか届かないでしょう
大規通信模障害でわざわざアポ取ったのに当日キャンセルなんてしないだろう

そういう時にはオフラインで操作して後で更新するだけで終わりだよ

複雑な在庫を奪い合ったり相互に関係するリレーションを破壊するには向いていないがそんな業務を避けるだけで
オフラインで業務報告や日報入力など普通に使えないツールは困るだろ

状況に合わせて適宜ルール決めるだけ
本当にこれだけだろう

仕様を決める人間と
決められた仕様に沿って実装する人間とでは
物事の見え方が違うという典型例だね

両方やってればもう少し物事を多面的に見れる

ちょっと違うけどイメージしやすい実例を挙げるとしたら Git とかになる？
fetch だけオンラインでしとけばオフラインでもコミットなどはできる。
オンラインになったときにプッシュする。
データが不整合（コンフリクト）になったときどうするかは、
要件に応じて設計

OneDrive とか Dropbox とかも

横からだけど、その例はちょっとズレてるんじゃないかな
そのような汎用的なツールは誰にでも受け入れられるように極力勝手な前提を設けずに小手先のテクニックで頑張る方向
一方で、業務アプリのように特定のユースケースを前提とするなら、汎用的なコンフリクト解決の仕組みとか要らないの
衝突した場合には、ある特定のデータ項目に関しては常に端末側のものを採用したい、といった要件は個別に話聞けば普通に出てくる
仕様決める人はそういうのをクソ真面目に話聞いて仕様に落とし込んでるわけだね
基本的に客は馬鹿なので、必ずしもそういうアプローチが汎用的なアプローチよりも優れている訳ではないのだが、
ともかく上の「仕様を決める」というのはそういうことを言っているのだと思う

>>363
書けば書くほど素人臭がキツくなるな
「Gitと同じように作るだけじゃないの？」とかリアルで言ってそう

なんかごめん

フェッチはコピーするという意味だと知らないんだろ

WinUI3の画面にWindowsTerminal埋め込んだったwww
https://qiita.com/C-Sharp_is_GOD/items/d02a2da67690342eb18f


WindowsTerminal標準の設定も使えるしタブ機能も使える

君しつこいよ

ChatGPTの公式デスクトップアプリがMac版はネイティブなのにWinではElectronになったのには、当初WinUI試したけどあまりにもクソだった
→実際Winアプリって最近のメジャーどころはMS製含めだいたいWebベースなんだからもうWebでいいじゃんという判断があったそうだ
あまりにもライブラリが未整備だし誰も使ってなくてエンジニアの確保も困難とのこと
一方MacはUIフレームワークの乱立&放置が繰り返されたWinと比較してネイティブアプリ用のUIフレームワーク何使えばいいか極めて明確だし、大部分のコードをiOSと共通化できたそうだ
WPF以降の迷走によって崩壊したWinのUI開発エコシステムの惨状を象徴する良い事例だな

だからWebでいいって大昔に結論でてる

バックエンドと高頻度にデータをやり取りするとか、
バックエンドでリアルタイムに生成した画像を大きく表示するようなアプリだと
Electronはレスポンス悪くなるんじゃないの？

ぜんぜん

Webはそういうユースケースに最適化されてるからむしろWPFなんかより遥かにレスポンスいいんだよなあ

じゃあ、逆にElectronはどんなタイプのアプリには向いてないの？

一般的には、メモリ消費量の少なさや起動の早さが重要な小物には向かないとされる(WPF比では微妙だが…)
ChatGPTなんかまさにそうで、Win版がElectronアプリであることはかなり非難されてるね

>>376
wasmの利用で死角が無くなった

一般的には、メモリ消費量の少なさや起動の早さが重要な小物には向かないとされる(WPF比では微妙だが…)
ChatGPTなんかまさにそうで、Win版がElectronアプリであることはかなり非難されてるね

ネイティブであってもXAMLレンダリングしてるならElectronでHTMLレンダリングしてるのと内部でやってることあんま変わんなくね？ってのが

AIアプリなんてネットワーク越しでAPI叩いてるだけじゃないの？ローカルクライアント側のパフォーマンス差なんて
AIのレスポンスに比べればたかが知れてる気がするけど

処理速度的にはその通りというかむしろ極限まで最適化されてる分HTMLの方が大抵速いのだが、
ブラウザを丸ごと同梱するのは本来必要な機能に対して膨大な無駄があるからどうしてもメモリ食うし起動にも時間がかかる

webアプリをクロスプラットフォームに移植する上でelectronだと楽だから使われてるだけで
最初からwin用のネイティブアプリ作りたい用途ならWPFの方が向いてる

それは思い込みだと思うよ
WPFの開発者なんて確保できない

ChatGPTのアプリってWeb版と何も変わらないじゃん、ショートカットがあるくらい？
それを例に出すのは流石に頭悪いと思う

Edgeで任意のサイトのアプリ化する機能とやってることは変わらん

Webアプリがクロスプラットフォームの肩書きを得るために楽なのがElectronだから一応用意してるだけ、ブラウザでアプリ化するのと対して変わらん

web開発者は低価格でいつでもいくらでも提供されるので成果物が同じ機能ならコスパが良いのは
web技術を流用したほうになる

単にChatGPTがアプリの特性を考えてElectronを採用しただけ
その開発者でもないのにそれを引き合いに出して他技術を貶めるのは流石に頭が悪い

ChatGPTはバックエンド側が価値があるわけでフロントエンド側なんて別にどうでもいいわけ

ネイティブアプリが向いてるのはアプリ側がメインで処理を行うもの

動画プレイヤー
ターミナル
IDE
PDFリーダー

こういった類のものを一から作る上でElectronやJSを採用する意味はない

アプリの特性を考えて適切な技術を選択してるに過ぎない

そういうものはおいそれと一から作られないと言う事実を無視してる
需要がない
WPFは死んでる
役割を終えた
winUI3もそんな感じだ

そういうのはC++の守備範囲だ

俺WPFでアプリ作ってgithub star 1000以上あるけど？使われてるんだが？

クロスプラットフォームならAvaloniaでもいいよね
JetBrainsがdotpeekやdottraceでAvalonia使ってるけど？

C++なんで全員使いたいわけでもないし、C#でネイティブ作る需要は普通にある

お前は何も生み出さず他人の受け売りしかできないゴミだね

どんどん小学生のようなレベルに落ちていくな
俺のお父さんは社長だぞーみたいなレベル
論理のかけらもない

上から順にスレを見返していけばいいのに

内容で反論できずに無意味レスw

C++じゃなくてもC#で作られてますよね？って事実を指摘して涙目敗走w

＞　俺WPFでアプリ作ってgithub star 1000以上あるけど？使われてるんだが？
これが痛々しいと言うことに気が付かないんだから本当に鈍感だろう

Avaloniaの話を出したりする時点でじり貧なのがよくわかる

このスレの流れの元になったレスから見直せばそういう話にはならない
ライトウェイトなジャンルでもWPFが使われないのは生産性の問題だろう
そこをなぜ無視するのか

ChatGPTで使われてないだとかはどうでもいい
他技術を貶める他人の受け売りしかできないゴミは
何も価値を生み出したことがないお前みたいなゴミが多い

何か生み出してかいってみたらどうなの

そもそもネイティブアプリの需要が低いってのがそもそもあるんだけどね、金稼げないし、割られるだけなんでね

他人にゴミゴミ言って突っかかってくる人間が一番問題あるんだと思うけどな
生産性がない

WPFが使われてないんだー、Electronの方が使われてんぞ！

うんそうだね、だから何？
ビジネスをする上でElectronが適した場面が多く、WPFが適してない場面が少ないだけなのでは？

逆に適してる場面で採用すれば生産性は高いのでは？

Avaloniaを持ち出したのもWPFとほぼ同じで学習コストが低いから

クロスプラットフォーム採用する上で、自分が慣れてる技術を選択することが重要なわけで

ごみごみ言うのは辞めたのか？書いてよかった

教育って大事だな

それにドンドン自分の書いた主張の内容をなぞって書いてくれるようになった
自分の主張が受け入れられて相手の思想を上書きしていると実感できる

使われてる使われてないとかどうでもいい
なんでそんなことを気にする必要があるの？

自分が作りたいものに適してていいものだと思えばそれでいいんじゃないの？

なぜかここで持ち上がるweb

君はわかりやすくて良い

>>387
いやいやMac版のChatGPTのアプリってVSCodeなど他のアプリと連携したりするんだぞ
今後オートパイロット機能などよりシステムと密接に統合されていく方向なのは明らかで、
ネイティブアプリの方がシステムへのアクセスのしやすさにおいて有利なのは目に見えてる
まあWinについては完全にCopilotと競合するから、やりすぎると大株主のMSから怒られる可能性が高く、やる気がしないという面もあるかもね

OpenAIにとってはWebのChatGPTのUIをほぼそのまま流用できる安い手段としてElectonが採用されただけだろう
Electronで実現不可の事はやらんだろうし最初からWPFが出てくる幕なんて無いのでは

だとしたらMacよりも金をかける価値がないってことになるぞ
Claudeのuse computerみたいにスクショベースでの連携ならElectronでも全然問題ないだろうけど、
Mac版ChatGPTの他アプリ連携ってOSのアクセシビリティAPIを使ってUIに深く踏み込んでるんだよね
仮に同じことをWindowsでやるとしたらUI AutomationとWin32みたいな世界だから、まあOpenAIは雇わないだろうねその辺得意なドカタPGは

WinUI3とMAUIって別物？
いまいちこの2つの関係がよく分かってない

WinUI3は次世代のwindowsネイティブSDK

MAUIは事実上xamarinの後継でマルチプラットフォーム用のSDKで実際のコンポーネントなどは
既存の各プラットフォームのSDKを使ってる
で、windowsではWinUI3を使うことになる

>>406
サンクス、理解できた

AppleとOpenAIが提携したから何かやるつもりでネイティブにしてるんじゃないんか

MS「…　いや…なんでも…」

MS的にはCopilotで自前で自由にして良い権利を得てたのかも知れんけど、結果は散々だな
今のMSにエンドユーザー向けの気の利いたサービスを開発できる能力があるとは思えん

MS365 Copilotは酷いよなあ
基本的な応答の品質からしてChatGPTと同じモデル使ってるとは俄かに信じられんレベルだしOffice連携も冗談みたいなゴミ
唯一役に立つのはTeamsの要約くらいだな
近年のMSのエンタープライズ向けプロダクトの例に漏れず情シスという名のブルシットワーカー達が経営陣に「やりました」と言うためだけに作られていて、
全くユーザーの方を向いていないしプロダクトとしての思想が何も感じられない
ただ機能表に丸を記入させるためだけに開発されている

最初から脳内で結論が決まっている人達…

WPFのフレームワーク周りがよく分かってないので聞きたい
調べると CommunityToolki.MVVM, ReactiveUi, ReactiveProperty, Prism などが見つかるけど、これらはどれか一つを選んで使うようなもの？

どれもMVVMのためと聞くけど、これらは同じ目的を持った異なる設計思想のライブラリという感じなのか、それとも異なる用途のもの (組み合わせて使える) なのか
スレ民のおすすめ、好みなどもあれば教えてもらえると嬉しい

>>413

俺は Prism 使ってるけど、どれでもいいと思う
MVVM Toolkit は INotifyPropertyChanged の実装とかで code generator 使えるのが売り
Prism は機能が豊富なのが売りでダイアログやナビゲーション機能(Pageの代替) とか他にはないのが多い、ただしライセンスが特殊

.NET9 & C# 13 preview だと fieldプロパティ使えるから code generator 使わないでもシンプルにかけるんだよね
こっちの方が当然コンパイルも速いし、View から直接Modelにジャンプできるのが便利
.NET10 & C# 14 では この書き方が標準になるはず

```
# INotifyPropertyChanged
public class Model : BindableBase
{
public string Name { get; set => Set(ref field, value); }
}

# ICommand (lazy初期化)
public DelegateCommand HogeCommand => field ??= new(() =>
{
MessageBox.Show("hoge");
});

```
フレームワークは DI使えればなんでもいいかな

Webではフレームワークというとフレームワークが主でアプリケーションコードをその上に乗っけるようなものだが、
ああいうのを念頭に置くならWPFのはフレームワークというより単なるサンプルやツールの寄せ集めと言った方が近い
基本的に必要なものを適当に掻い摘んで使うもの、何ならソースコードをコピペしてきて自作してもいい

短かく簡単にしたいっていうならPropertyChanged.FodyとCaliburn.Microの組み合わせが頭おかしいレベルに省略できる。
>>414 の例によると、Set()も要らないしDelegateCommandも書かずに動作する。
だから問題なのはMVVMをどうするかではなくXAMLをどうするかに始終。

C#はシンタックスシュガーお化けなのにXAMLはこれっぽっちも短縮系がないのは何でなんかね
何もかもがクソ冗長で嫌になってくる

View側で何でもできるとそれはそれでスパゲッティになる
React がその例

Viewにロジックを極力書かないのがWPFの流儀なんでそれに従うしかない

なんじゃそりゃ

>>418
本当のスパゲッティソースを見たことがないんだな
山岡さんの気持ちがわかったような気がする

コード量はXAMLの方が何倍も多いよ
糞フレームワークのおかげで

XAMLが大成功して広く使われてたら今頃はとっくに virtual DOM & one-way data flow アーキテクチャに移行していただろうし、
C#にもJSXのようにXAMLをインラインで書けるようにする拡張が入っていただろう
そうするほどの存在感をXAMLは示せなかったというだけのこと

XAMLにC#書けるんだからそれで我慢しなよ

ReactからWPF使って快適になったんだけどこれは俺だけ？

流行ってるからいい技術って思ってんだろうけど単にWebの方が拝金主義者にとって都合がいいだけに過ぎない

WPFじゃ簡単な画面しか作れないよ

派手なコントロール作ればいいんじゃね？
スタイルのカスタムとか無視してゴリゴリ画像とか貼りまくればいい

>>424
どこがどのように快適になったのかを具体的に教えて

>>427
UIとロジックが分離してるおかげで標準コントロールをそのまま使うだけでよい
このことから生成AIとの相性が抜群

テーマはサードパーティのを入れるだけで勝手にモダンな見た目になる

>>425
デスクトップアプリはマシンリソース使えるアプリ使えたりするし
UIなんかより動作するアプリ側に価値があるものを提供できる
それができればUIなんぞどうでもいい

>>428
UIとロジックの分離なんてReactでも当然に実現されてる
テーマは適当なCSSフレームワーク使えば余裕
まあまともに使ってないんだろうな

>>429
全然分離実現されてないから、使ってないのはお前だろ

ReactはViewしか存在しない、react hooks とかいうゴミを導入したことでさらにスパゲティが悪化した
テーマもCSSフレームワークを使えばそれに強く依存することになる、それが問題だといっている
State管理もいろいろ乱立し終わってる
WPFだとViewとロジックが分離されているし、標準コントロールにテーマを適用する形になるからほとんど改修は必要ない、これが大きなメリット

フロントエンドはAngularの方が良いな
よく使われている=いいもの ではないのよ。

そんなことはどうでもいいからtextboxにプレースホルダぐらいは実装してくれよ…

WPF推してるやつの時代錯誤感やベェなw
ここまでとは思わんかった

おじいちゃんだからそっとしておいてあげて

既製品でよければExtended WPF ToolkitにWatermarkTextBoxがあるだろ
自作してもいいのよ

>>425
手間暇かければ出来ないってことはないだろう
割に合うかは別として

>>435
逆立ちしてもCSSに勝つのは無理だよ

>>436
CSSと比べるつもりは無いんだけど
WPFでは不可能な複雑な画面ってどんなのさ

>>437
webのデザインシステム見たこと無いのか？

手間暇かかってやってられないならともかく、作れないってのは分らんな
もしかしてカスタムコントロールやビヘイビア等の力業無しのXAML縛り前提の話なのかな

>>432
わざわざ推してないもののスレに来てるお前の方がやべぇよ
webが好きなら一生webをやってろ、俺はそれに価値を感じていないだけ
価値のあるwebアプリってのを見たことがない、価値があるのはそこに提供されるコンテンツや
ChatGPTのようなバックエンドサービスであって react だのそういった技術に価値を感じたことはない

生産性度外視してWPFだって出来るもんって言ってもなあ

XAMLなんて控えめに言ってもバッドノウハウの塊だろ
GridやStackの各種パネルがくんずほぐれつしてる他人の書いたXAMLなんか読めねえよ
さらにそこにリソースやテンプレートが乗っかってきたらもう死にたくなる

スレで繰り返されるweb

いい加減CSS最高君に構うからいけないんだと気づこうぜ

>>441
全てViewに固めてるReactの方が読めないわ
何useStateだとかuseEffectって？
JSXの中で三項演算子やら複雑なロジックが書いてあって意味わかんねーよ

大体XAMLなんてデータ表示してるだけでロジックがないんだから読む必要なんてない

読む必要があるのはロジック

XAMLに文句言ってる奴はqtやらWinformsでGUI作ったことがないんだろうな
ReactだのWeb技術を持ち出すのがその証拠

少なくともWindowsアプリ開発において開発生産性でWPFより右に出るものはないでしょ

とはいえ今時のWindowsアプリって、不特定多数向けの新規開発はMS謹製のもの含め大半がWebベースになってるからねえ
生産性は慣れやスキルセットの問題もあるから単純にどっちが上というものではないが、事実として時代は変わってしまった

令和のコボラー

やべー
最近のアプリなんて何ひとつ使っていなかったわ……

マイクロソフト自身もVS CodeなどはWeb系の技術で作ってるからな
Windows限定ならWPFはそれなりに有力だけど、世の中のニーズがマルチプラットフォームアプリやWebサービスに向かってる以上はWeb技術は避けられないと思う

React hookが嫌いとかはたぶん慣れの問題で、逆の立場 (React分かるけどWPFは未経験という人) から見たら同じようにWPF難しい、ってなるだけかと思う

>>449
WPFは最初は難しいが慣れると快適で生産性が高いと感じる、実際に自分がそうだった
Reactは最初は簡単だが、慣れるとクソに感じてくる。React Hooksも同様。
Angular の方が断然いい

人気だからよいものとは限らない

React Hooksとか超コードみじかいんだが...
変な状態管理のコードでもつかったからだろ
MVVMみたいな糞選択がすれば、糞な結果になるのはReactも同じって事よ

MSはOutlookをWebView2に移行したね
WPFの最大の敵はこんなところにいるアンチ達ではなくマイクロソフトなのだ

Web苦手おじさん発狂中

ところでクロスプラットフォームなら名前の出たQtのQMLは超いいよ
Windowsではネイティブコントロールを使ってくれないので違和感があるのが欠点だけども

>>452
どこ情報？

>>455
https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/overview-new-outlook#architecture
> The new Outlook for Windows, built upon modern service architecture, is inspired by the Outlook web experience. It operates within a streamlined Native Windows Integration Component and utilizes WebView2.

なおReactを使用している模様
https://www.neowin.net/news/microsoft-plans-to-unify-outlook-across-platforms-using-web-technologies/

>>452
単にアプリの要件に合わせて適切な技術を選択しているだけなのでは？
Outlookはwinネイティブの機能は何一つ使わないだろうからクロスプラットフォームにする上でWebを使いまわせるメリットが大きいんだろう

Windows11の電卓は？動画プレイヤーは？

>>451
コードの短さ＝保守性の良さ、高生産性と思ってる時点でレベルが知れるね

Reactなんてone wayアーキテクチャが大規模において使い物にならないからいろんなstate管理のパターンが乱立してるんだけどね

state管理の難解さは人間の方に問題がある気もするけど
状態の組み合わせ爆発で人間の脳では追いきれない
バグがあって当たり前

>>457
その例はちょっと苦しいなw
PCでの動画再生なんて今時ほとんどWebだし、電卓、、まああなたが開発しているのが電卓なんだったら何も言うまい

two way推しとは...笑

WPFデザインのメリットって何？
WindowsFormでも行けるよね？

>>461
one wayなFlowアーキテクチャで十分ならなぜState管理のライブラリが乱立してるの？
Angularはそうでもないけど

>>463
WPFのMVVMライブラリがなんで乱立してんの？を自問自答してみれば自ずとわかるのでは？w

>>457
>Outlookはwinネイティブの機能は何一つ使わないだろうから
これマジで言ってるの？

>>463
WPFしかやってないと、
Reactとかアカデミックな技術論の盛んさに腰を抜かすだろうね

Geminiの回答

UIのViewModelにおけるデータフローがTwo-wayからOne-wayにシフトした主な理由は、
* 複雑性の軽減: One-wayはデータの流れが単方向で、状態管理がシンプルになり、バグの発生を抑制できる。
* テストの容易性: 各コンポーネントを独立してテストでき、テストケースの作成が容易になる。
* 大規模アプリケーションへの適応性: スケーラビリティが高く、コンポーネントの再利用が容易になる。
* リアクティブプログラミングとの親和性: データの変化をリアルタイムに反映させやすく、非同期処理をサポートする。
これらのメリットから、現代のフロントエンド開発ではOne-wayが主流となっています。
より詳しい説明が必要な場合は、お気軽にご質問ください。

>>463
angularはフルスタックフレームワークだね
意味分かるかな？

ちなみに一般的な認識ではreactはライブラリー

Webだって競争の結果、今に至っただけなんだよなぁ
One-WayのMVVMフレームワークが良ければVueだってあるわけじゃん？
最近触ってないから、最近のVerでどんな実装が主流なのか知らないけど

❌OneWay->○TwoWay

one-way dataflowって要は
ビューはモデルの状態を反映するのが仕事
ビューはモデルに指示を出すのが仕事
状態の更新はモデルの仕事
というだけのことで、MVVMでもまともな作り方してたら基本的にそうなってるはずなんだけどな
ただ、2-way bindingしちゃうとモデルの状態を反映していたはずのVMのプロパティがビューの状態変化によって汚染されてしまう
それを考慮して適切に同期をとらなきゃいけないのは複雑だから2-way bindingはやめようということだね
しかしその辺は実装上のテクニカルな問題であって、本質的には前述の役割分担が適切に行えてさえいれば大きな違いはないのだが、
この残念な人は責務の分離が正しく理解できてなくてVMに状態更新のロジックを書いちゃってるんだろうね

両方触ったうえでReact糞WPF快適と言ってるんだがｗ
お前ら口だけのクズと違ってWPFで割と高度なアプリ作って1000スター持ってるからね
悔しかったらそれぐらいの実績上げてみろよ

わざわざ嫌いなもののスレにきてWPF下げてReact持ち上げる癖にReactでもWPFでも大したアプリ作ったことないんだろ
IT土方にも適用できず発狂しちゃったんだろうね

技術的な良し悪しとは違うけど、今からWPFを学ぼうとすると情報を探しづらい (古い情報が多い) のがつらい感じはする
人気再上昇みたいな未来は見えづらい

このスレ見てるとWPFを学ぶ気が失せる
特にCSS使えないってのはかなり致命的だった
MS奴隷しか使わないフレームワークなんだって事が判ったよありがとう

何と戦ってるんだ？

ReactというかFlutterでもSwiftUIでもなんでも良いんだけど、最近のFlux/コンポーネントベースのフレームワークはガチで使いまわせるが
WPFのユーザーコントロールは結局既存のコントロールの拡張を遠回しに実装するだけで
複数のアプリで使いまわせた試しがほとんどない
見た目を分離することと生産性の向上は全く関連性はない

>>477
じゃあCustom Control作るか、標準コントロールにtheme適用すれば？
そもそも見た目を分離するってのはユーザーコントロールの話じゃないからね
ViewとViewModelを分離することも言ってる

例えばある処理中に Spinner を実装する場合は、Reactだと Viewに状態を含むロジックをすべて書くことになっているから
非常にテストがしづらいしスパゲティになるんだけど
WPFだと プロパティとAsyncCommand を定義するだけでViewModel上でSpinnerが完結するから
完全に見た目とロジックが分離していることになる

よってViewModelだけテストすればよいし、Viewはただ表示するだけのシンプルなものになる

MVVMを叩いている馬鹿は、WinformsやらQtやらでそれなりのGUIを作ったこともなければReactやらでまともにテストを書いたことがないんだろう