WPF(.NET, WinUI) GUIプログラミング Part27
レス数が1000を超えています。これ以上書き込みはできません。
WPF(Windows Presentation Framework)について語るスレ。
前スレ
WPF(.NET, WinUI) GUIプログラミング Part26
https://mevius.5ch.net/test/read.cgi/tech/1624176258/
関連スレ
Windows 10 UWPアプリ開発Part 3
https://mevius.5ch.net/test/read.cgi/tech/1627556967/
コードを貼る場合は以下のサイトの利用をお勧め。
https://ideone.com/ 今の所Windows App SDKに画面デザイナーは無いみたいだね。
Xamlライブプレビューのみ。
まあプレビューあれば十分か。 Ctrl+Sしなくても即反映されるし、マルチディスプレイなら特に困らないよね WPFで動画のプレイヤにするのにシークバーなど使いやすいものありますか？ デフォルトで入ってるやつか…
WPFMediaKitのMediaUriElementを使っていたのだが急に動かなくなったのよね WebViewだろうね
WPFを使う意味があるかはともかく >>11
結局VLCにしたんだけどMediaUriElementで出来ていたパラメータのbindingが出来なくて結構変更することになった
なんで使いやすいプレイヤ知ってたら教えて貰おうかと WPF-MediaKitもVlc.DotNetも古くてLibVLCSharpが推奨なのでは、知らんけど
https://code.videolan.org/mfkl/libvlcsharp-samples >>13
ほー使ったことないな
今度なんかあったら試してみる drawingContext.DrawLine(new Pen(Brushes.Black), 1), new Point(0, 0), new Point(0, 100));
drawingContext.DrawRectangleBrushes.Blacknull, new Rect(0, 0, 1, 100));
この二つって全く同じ個所に縦線引かれると思ったらDrawLineの方が左に1づれるんだけど仕様？ DrawLineとDrawRectangleの差じゃなくてBrushとPenの差か
DrawLineのBrush版があればなぁ それはwindows系であるRectangleの仕様
Rectangleの場合、下、右は含まれない >>18
いや、DrawRectangle同士でも
DrawRectangle(Brushes.Black, null, new Rect(0, 0, 1, 100));
DrawRectangle(null, new Pen(Brushes.Red, 1), new Rect(0, 0, 0, 100));
こうするとそもそもxの起点位置が違うんよ
下の赤線の方が1つ左にズレて-1位置に描かれる 今のwinui、バインド関連のバグ多くない？
せっかくなら新しいの覚えながらやりたいと思ってwinuiで作ってたけど、使用に耐えるものを作れそうにない
UI部分wpfに差し替えようかな
素人がプレビュー版なんて使うんじゃなかったわ 自分じゃどうにも改善できねえ >>20
そうなんだごめんよ
>>21
でも、WPFにすると見た目がダサくならんか??
WPFにすると見た目がダサくなるが安定
WinUI3にすると見た目がおしゃれだが、ちょっと不安定 まぁ、WinUIとか定期的に更新してくれるからバグ報告すりゃそのうち直る可能性高いけど、ユーザー少ないからバグを自分で踏んで報告する羽目になる.. >>22
modernWpfUI使えば大体似た見た目にはできるから、もういいかなって 21です（23も俺）
過去にWinFormで作ったソフトをWinUIで再構築しようとしてたんだけど、新しいことやってみたい気持ちだけでWinUI使ってた
正直今背伸びしてまで使うメリットが自分には見えないんだよなー
WinForm→WinUIも
WinForm→WPFも
ユーザー目線だとそんな変わんないんじゃねって思う（WPFはUIのライブラリ使って現代風の見た目にすれば） ごめん21,24,25が俺ね
どうでもいいことで連投すまん >>24
俺もmodernwpf 使ってたけど、win11スタイルはまだだし
NavigationViewとか階層メニューまだっぽいし
やっぱ、個人じゃきついよなーとか WPF+ModernWPF
と
WinUI
で似たアプリ２つ同時に作りながらやってるわ
最終的にWinUI一本に絞ると思うけど > ユーザー目線だとそんな変わんないんじゃねって思う（WPFはUIのライブラリ使って現代風の見た目にすれば）
たぶん、そうだと思うけど(とりあえず、ライトとダークあれば)
俺はそこだけは変にこだわってるから
ちょうど数時間前もWPF+ModernWPFで、CommandBarじゃなくてWPFのToolbar使いたくてでもModernWPFでToolbarはスタイリングされないから頭抱えてた
まぁ、自分でスタイリングする能力ないんで.. >>30
あー、もうそんなの出てたんだね
そういえばgithubのバグ報告のページで「1.0.0でも起こるけどまだ直ってないんか？」みたいなコメントしてた人いたわ 見たときはなんのことだと思ったけど
だめっぽいけど一応試してみるかー >>25
>WinForm→WPFも
>ユーザー目線だとそんな変わんないんじゃ
開発者目線だとWPFのが作るのが楽（MVVM、非MVVM関係なく）だからWPF使ってる。
受け入れられやすいようにWinFormっぽい見た目に変えてる。 悲報、WinUI3、ウィンドウのHeight, Widthプロパティ無し
ウィンドウサイズに依存したWinFormみたいな糞アプリを作れなくなるからこれはこれでいいのかも。
いやでも初期サイズぐらいは設定したい。ウィンドウサイズ固定はできなくていいけど。 前回のウィンドウ位置・サイズ・位置を記憶しておいてほしいって要望は結構あるからなー。
PInvokeでなんとかなるんだろうか。 >>33
いちおうサイズや最大最小ボタンの無効化とかを設定できるAPIがある
実際俺が作りかけてるソフトでも初期ウインドウサイズだけ変えてるけど問題なく使えてる
今ちょっと名前は忘れたんだけど、API紹介してるマイクロソフトのページを見ながら実装したと記憶してるので、探せばでてくると思うよ
正直標準でついててほしいけどなあ 俺が使ったのは>>36のと違うやつだけど、36のほうが使いやすそう winui 0.8で作ったやつそういやはじめてnull許容参照型有効にしてみたんだけど、コンパイルエラーでなく警告しかでないの?
null非許容参照型にnullf代入できちまうわ 違うかも、元々警告だった気がする。
エラーだと影響でかすぎるから。 実質WinUI 3(Windiows App SDK 1.0)がバージョン1だから。
まだストアアプリ臭が抜けてなくて、デスクトップアプリとして見ると
「は？こんなこともできないの？」ってレベル。 使えるうんぬんより、マイクロソフトがストアで商売したがってるイメージ
また変なの考案するより鍵屋した方が手っ取り早いのに てかもうMS自身が自社フレームワーク諦めてElectronとか利用してんじゃん 新Teamsからはelectron脱却してWebView2行くんでは？ でも、一部のクロスプラットホームアプリだけだろ??
電卓に始まってペイントやらフォトビューワとかもろもろはelectronとか使ってないだろ?? もうos周りのアプリだけだろうね
一般のアプリは、
Webかスマホかに二分される時代だし まぁ、xamarin(maui)はMicrosoftも諦めてて、microsoftの他の部門であえてこれらを使わないと思うが MAUI(＝Xamarin)使うぐらいなら普通はFlutter使うわな VisualTreeHelperというのがありますが、
勉強する価値があるかないか、そしてその理由を教えて下さい。
Visual StudioのXAMLエディターでツリーが見れるようになったので、
今は無用の長物でしょうか？ アプリって言うと
昔はデスクトップアプリを指してたんだけど、
今じゃスマホのアプリの事だもんな
さらにwindows11で
アンドロイドアプリがPCで動くようになると、
もう価値がなくなるんでは無かろうか？ Microsoftがスマホでも勝者になってる世界線にいたら、今はみんなxaml使ってたのだろうか ガクブル >>60
Androidも画面定義はXMLだから似たようなもんだよ android系では去年からもうflutterでコードベースの宣言的UIやってるし、android/kotlinでもjetpack compose使い始めたし、今年に入ってからxml一切触ってねぇわ 他は進化してるのに、今年正式にリリースされるUIフレームワークでもまだxaml??
絶望だろ
cometは実用になってるのか知らんが
つか、avalonia UIとUnoPlatformとか、Microsoftがしっかり方向性示さなかったからみんなで戦力分散してみんなで自滅してるよな.. UIをXMLで記述するのは筋は良いよ。
ただツール側が大変。
だからXML止めたところは単なる妥協。 逆だよ。XMLの方がツールは作りやすい。
でも頑張って高機能なツールを用意するより、手書きの負荷を下げてツールは最低限プレビューするだけの方が、
開発者にとってもツール側にとっても楽であることに業界が気付き始めた CSSのほうが次元が違うぐらい凄いぞ
XAMLじゃマシなUIは作れん
画像はるしか方法がない
そするとアニメーション出来ないけど... XAMLはWYSIWYGなツールで編集することを大前提として設計されている上、GUIフレームワークのオブジェクトモデルの設計にも引っ張られるから、
処理系として出力だけしか考慮しなくていいCSSと比較するとどうしても記述性や表現力の面では劣る コードで書く宣言的UI方が100倍楽
普通にコードを書く延長線上でいけるし、if文使って切り替えたり、for文でループ回したり簡単に自由自在
xamlでやろうとするとコードビハインドもできるがMVVMぎちぎちに要求されるからうざいわ
ValueConverterやらTriggerやらVisualStateManagerやら色んな概念でてきていったりきたり MSがツール作るの得意すぎたせいで、みんなWYSIWYGなツールを使ってUIを作ることが当然で開発効率も良いと思い込まされてきたんだよ
ここにいるのはその最後の残党で、彼らは既にXAMLを手書きした方が早いと気付いているにも関わらず、
未だにツールの都合に合わせて面倒なXMLを記述しなければならないという矛盾には気付いていないんだ
もうちょっとだから優しい目で見守ってやってくれ WinFormはポトペタに頼るけどWPFはWISYWIGといっても確認用くらいしか使わんなあ
慣れればXAMLべた書きでほぼ思い通りのレイアウトできるし >if文使って切り替えたり、for文でループ回したり簡単に自由自在
それ宣言的って言わんw >>74
バインディング脳だとそう思うよね
Reactとかやってみればわかるけど、データの流れが単方向になっているならちゃんと宣言的なんだよなあこれが >データの流れが単方向になっているならちゃんと宣言的なんだよなあこれが
「宣言的」の定義が捻じ曲がってる気がする 今時の宣言的は違うだろ
画面更新において宣言的に書けるから宣言的なんだよ for文、if文とか入ろうが、それらはある一瞬のUIを記述してるから宣言的なんだよ
if文、for文で、前のUIの状態を変更してる訳じゃないんだよ >>76
宣言的UI、でググってみ
君の思ってるfor使ったら宣言的じゃないとかいうのは表面的なコーディングスタイルの問題でしかなくて、気に入らないならLINQ使うとかやりようはいくらでもある
UIでいう「宣言的」ってのは、画面がどうあるべきかというのを宣言したら自動的にそのようになるってこと
それがWPFではXAMLであり、React等ではコードによって生成された仮想DOMであるというわけだ 宣言的UI この状態のときはこんな画面になるということ記述していくスタイル
if文とかfor文とか使う、使わないとか重要じゃない
というかif文,for文とかその他類似のもの使わないと宣言的UIで画面更新できん ifとかforとかがSGMLの中に出てくるのって美しくないから個人的には好かん
JSPとか最悪だったし xamlも同じ
xamlでこの状態のときにこういうUIになるってxmlで記述してるよね
更にこれが進化して
この状態のときにこういうUIになるってifやforなどのプログラムコードで記述してるのが最新の宣言的UI
馴染みのプログラムコードで書けるから楽
制御構文をもたないxmlのようなものでUIを記述するのが宣言的UIというのは昔の話? XAMLでWYSIWYG使うって君WPF使ったことないでしょ UI部にif文書くか？
ロジックが入ると面倒だから、渡されたpropsをそのまま代入しない？ >>66
IDEの開発元がXMLよりコードでUI書く形式の方がIDE作るのが楽だと言ってるんだが。
コードよりXMLの方が画面イメージが直感的に分かりやすいが、そのメリットはIDE開発側が楽するために捨てたいんだよ。 >>86
WPF+MVVMの場合、宣言的なUI定義を記述する方法に関しては>>81のようなスタイルよりも宣言的といえる。コードと違い一切手続きを書いてなくて、バインディングを使った完全に静的な記述のみだからね。
じゃあ何が問題かというと、バインディングの代償としてVとVMとの結合が強くなっているために、実質的にビューが固有の状態を持ってしまっているのに近い状況になるケースが多いことだ。
たとえば>>81のボタンの例で言うと、MVVMでMの状態Aに基づいてボタンを動的に追加したいがMを直接バインドできない場合、
VMの持つコレクションを見て既にアイテムがない場合のみアイテムを追加するようなコードを書くことになる。これは明らかに宣言的ではないよね。
WPF+MVVMなら例えば変更が入るたびに毎回VMをMに基づいて新しく作ってDataContextを設定し直すようにすれば完全に宣言的にできるわけだけど、
これをやると変更の必要のないボタンまで毎回作り直しが走ってしまい、実用的ではない。
それを>>81ではフレームワーク側が自動的に差分を取って賢く画面に反映してくれるというわけ。 >>81
・declarative（宣言的）なコード
状態 A なので、ボタンを 3 つ表示する。
・imperative（命令的）なコード
状態 A なので、ボタンを 3 つ表示する必要がある。
ただし、すでに中央のボタンを表示しているので、その左右にひとつずつボタンを追加する。
まじで意味わからんw >>91
>>90にも書いたけど、Mを入力としてVMを返す関数を考え、Mの更新の度に毎回VMを作り直してDataContextにセットし直すことを想像するといい
そうすることでビュー固有の状態に依存する命令的なコードを排除できる >>92
要するに
> 差分を取って賢く画面に反映
を誰がやるかって話なの？ WinFormのデザイナーが吐いたコードが宣言的の良い見本 >>91
そういう時は最初から作っておいてVisibilityで制御すんじゃないの
もうあるから追加〜とか普通やらんだろ ほとんどのことはContentControl使えば動的に変更できると思う >>90
つまり>>78,82は間違ってるって意見ね このスレ、WPF、XAML知らないで語っちゃう人が居座ってるからなw
昔から知識増えてないし。 >>90
>VMの持つコレクションを見て
WPF＋MVVMだと、VMがコレクション持たないと思うんだわ なにかを批判する人がその批判対象のことをよくわかってないってのはよくある話。
そもそも使わんだろうしな。 静的な記述というからStaticResourceの話かと思ったら、そんなことはなかった >>101
親VMが子VMのコレクションを持つことは普通にあるよ
それをItemsControlに渡す
ObservableCollectionを使って自前でやってもいいけど、ReactivePropertyのToReadOnlyReactiveCollectionを使うと楽
https://blog.okazuki.jp/entry/2015/02/15/231155 Reactive Extensionsは使ってもいいけどReactivePropertyの使用は禁止します >>101
どこを見てそう思ったのか逆に気になる。 え、駄目なんですか
じゃあPropertyChanged.Fodyにします 昔はお客さんが「リッチなUIで操作性も最高のクライアントが欲しい」からと、
“デスクトップアプリ”だったんだけど、
今じゃ「デスクトップアプリなので、Webみたいな凝ったUIは作れません！ 汗」だからなー−
WPFじゃグラフ系の機能つくると地獄みるし、
（ひたすら要件を潰しまくるとかして... 笑）
時代は変わるよなー− HTMLというかCSSは常に進化し続けているけどPC向けのUIコンポーネントは迷走して結局20年前と大して変わってないからな
最近のPC向けソフトがElectronばかりになってしまうのも仕方がない Webとデスクトップアプリの間で、作れるUIのクォリティに決定的と言えるほどの差は技術的にはまだ無いと思う
未だにデスクトップアプリばかり作ってるようなベンダーは、技術的に進歩のないくだらん仕事ばかりやってきたせいでスキルがないだけだよ >今じゃ「デスクトップアプリなので、Webみたいな凝ったUIは作れません！ 汗」だからなー−
webの方が凝った表現ができるUIって例えばどんなんだろ？ > WPFじゃグラフ系の機能つくると地獄みるし、
> （ひたすら要件を潰しまくるとかして... 笑）
> 時代は変わるよなー
有料コンポ買えば解決する話じゃなくて? 昔は
リッチーアプリケーション ＝ デスクトップアプリ
だった。今はその言葉もあんまり聞かなくなったけど
>>115
https://observablehq.com/@d3/gallery
https://threejs.org/
https://resources.jointjs.com/
とか
とにかくググれば凄いのが星の数だけでてくる
>>116
有償コンポーネントは大したものないよ。
唯一データグリッド位かなー−
これだけ有償を選択してる
それ以外の入力コントロールは全部オープンソース OR 自作 >>119
それってデスクトップならそのまま描くだけじゃん。あとはそのライブラリ自体が高機能なだけだが。
それとも「webなら高機能なライブラリが使える」ってのが言いたいことなんだろうか。 技術的な事ってより、ライブラリが少ないって話しか
仕事でやるならいざとなるならDevExpressとかSyncfusionから買うのも手だし
グラフ系はJavaScriptに負けるな
データグリッド系は有料で優秀なのあるからな >>120
>>「webなら高機能なライブラリが使える」
まさにその意味だね
あと思想が優れたものが多い
作者の地頭の良さを感じるし＆オープンソース！
とにかくリッチものが多くて全容を把握するのが不可能 有料でいいならWPFでリボンやらツールバーやらドッキングやらいっぱいあるし困ることはないだろう webのguiいいね・・・
でもなんか移行できない古い人間なんだ・・・ Microsoftがやるべきだったのは、xamarinとか買収よりも、大手のコンポ買収して無料にしてくれてた方が100倍よかったんじゃね
それやると他の有料コンポ死ぬけど >>119
そんなにレアなコンポーネントでもないじゃん。
blend持っててデザイン部があったら適当に作ってくれる領域では…？ >>126
Blendで適当に？できるならやってみろよw
そりゃ静的な画面でそれらのサンプルと似たような見た目のものを作るだけならBlendで簡単にできるだろうけど、そういうことじゃないのは流石にわかるだろ？ >>127
やってるけど内製アプリ専用で外には出さないよ
それが目玉の一つになってるのパッケージ売ってるし
デスクトップとWebの市場構成が違うからね >>127
うん、お仕事で実際にやってたよ。
俺は開発部だから作って貰う側。
電子カルテ作ってたんだけど、グラフ部分とかはちょっと特殊な表示があったから自分たちで作ったものの、まあバッチリ出たよ。 パッケージ開発ならいくらでも手間かけられるんだからそりゃできるだろうな
WinFormsでもできるだろう 手間というか工数、予算=金だよね
Webは低予算が多いから無料で高品質？なライブラリを拝借できないとキツいんじゃないかな それはビジネスモデルの違いでしょ
WebもSaaSみたいなスケールするビジネスなら工数は青天井だよ >>133
WinFormsよりは楽かなぁ。
デザイナーとエンジニアが分業、という絵空事が若干可能になった。
バインディングとダミーデータ返すdll渡したら、それにデザインつけてくれるんよ。
これが10年以上前に余裕でできてたんよ。 所詮絵空事。
デザインがわかるエンジニアなら重宝されるだろうが、
デザインしか出来ないデザイナーなんて穀潰し雇う馬鹿はいない。 デザインが出来るエンジニアなんか要らんよ。
そんなの出来るって言ってるだけだから。
ちゃんとデザイナー入れた方が良いよ、マジで。 動的なグラフの可視化をWPFでスクラッチで実装できるデザイナは、デザインができるエンジニアどころか並の業務系ITエンジニアよりよほど上だろ 一般的な専業のデザイナって汎用のデザインツール使って画面のモックアップとアセットを作るとこまでが仕事だぞ？
それを元にして実際にマークアップやスクリプトを書くのはあくまでエンジニアの役目
ID:BNGPGqInの所属する会社でいうデザイナは世間の感覚とはかなりズレてる >>142
そうかねぇ、なら言い直すわ。
380円のデザイナーではなくて数千円円以上するまともなデザイナー使えばいいよ。
安かろう悪かろうなんよ、君の買い方。 windows版のvisual studioってwpf製って聞くけどmac版のvisual studio2022って何製? Macは今回NativeUI化したとの話をどっかで読んだよ。 そっか、つかOfficeならわかるがVisual StudioまでMacで動かそうとしてたんだな
そんなことやってる暇あったらwinuiやmauiに人員投入しろって感じ WinUIもMAUIもなーんか期待できないよなぁ。スマホやUWPとはちゃんと決別してほしいが。 超低機能なのに超重量級と噂のWindows11GUIは何製ですか？？ >>153
1台入れてみたけどWin10より軽いよ。
ただ、macみたいに低機能UIになったから生産性ガタ落ち。 WindowsのGUIが何製とかすごい質問だな
タスクバーはWinForms製かもしれないとかそういうこと考えてるんだろうか >>156
はい、考えてます
10のスタートメニューは途中からUWP製になって未だに旧Edgeコンポ使ってますよね >>157
UWP製などにはなっていないよ
UWPと見た目が似てるc++ライブラリを使ってる Windows10の電卓がソース公開されたので見てみたらC++ CLI のUWPというマニアックな作りで面白かったな windowsのスタートメニューやタスクトレイなどを含めたGUI機能は
explorerが担っている
explorerはwindowsのGUIシェルでUWP製などではない >>161
だからそこに書いてある通りでほぼすべてexplorerでやってて内部的にタイルだけUWPにホストされてるんだろ？ Windows8の電卓が全画面でﾄﾞﾝ!飛び出してきて狂乱発狂した思い出 三角関数とかちゃんとテイラー展開使って計算してて勉強になる WPFなんだけど☆や△記号がちゃんと太字になるフォントってない？
MSゴシック系以外で知ってたら教えてもらいたい >>167
BIZ UDゴシック
※ただしこのフォントは環境によってアンダーバーが薄く表示される windows app sdk 1.0 preview 2!! windows app sdk 3.0に期待。
.NET Coreも3から使い物になるようになった。 ようし、3から使い物になるってじゃあPreview 3に期待すりゃいいのか
って、ひょっとしたら次正式リリースになっちゃったり もっさもっさのWPFも自前で描画するとめちゃくちゃ軽くなるな
ちょっとトリッキーなデザインのコントール作る場合はこっちのが返ってコーディング楽だわ progress表示も重要だよな、総件数のカウントとか二度手間で遅くなるだけなのに
エンドユーザー視点ではそういうところが評価される >>175
後学のためにどんな感じのことをしたのか教えてほしいっす OnRenderをオーバーライドして自分で描画処理書くだけの話じゃないの？ >>177>>178
いや、OnRenderオーバーライドする方式ではなくDrawingVisualでDataGridに代わるテーブルとか作っただけ
自前描画でボーダーを描く際にVisualEdgeMode = EdgeMode.Aliased;してアンチエイリアス切らないと線が滲むとかVisualTextRenderingMode = TextRenderingMode.ClearType;しないと文字が汚くなるとか色々罠があって大変だが WPFって回転させたり台形になったりするけど
あんなん誰が使ってんだ？ >>179
ほえー、すごいねえ
DrawingVisualは画像表示でちょこっと使った覚えがあるけど確かに大変だった
ありがとね >>180
センスのない人が使いそう。
ボタンをクリックしたらボタンが360度回転するとか。 >>180
左と右の矢印とかで、リソース同じにして回転使ってるわ スマホみたいな縦画面にしろ
ただしこのモニタには回転機能はない
とか言われたときに使う スーファミ初期ゲーみたいにとりあえずタイトルを回す アニメーションに使う場合はフェードイン/アウトといって透明度とセットにする
すっと現われるテキストとかクルっと回りながら消えてサムネイル入れ替えたり Flutterはじめました。
Android Studio相変わらず糞重いな。 ListBox/ListViewのスクロールの位置を記憶するのにまごつくよな
またUIオートメーションからIScrollProviderを取得する方式になってしまった
管理できるライブラリかビヘイビアないのかな >>188
俺もFlutter始めてるぞ
vscode使いなよ VSCodeは普段使ってるけど、MS以外の開発環境にも慣れておく修行 WinUI 3よりVisual Studio 2022の方が興味あるわな 2022、はよ出せや、(#ﾟДﾟ) 凸ｺﾞﾙｧ!!
何十億年待たせるねん？ まあ１１月８日リリース予定だから、何もなければ今のRCがリネームされるだけだわな winui3くそ遅い??
listviewでスクロールさせると、描画の様子がひどいぐらいはっきりわかるんだが
スクロールさせてスクロール停止させる
上から下に順にアイテムが描画され、2秒ぐらいで上から下へ到達
つか、winui3は現状UWPのネイティブコンパイルもないしうーん... 仮想化はされてるはずだと思うが、x:bindにしなきゃいないオチなのかな
UWPでx:bindは今までは体感できなかったからbindingできたが おれはx:Bindでやってるけど多分同じ
DataGridのスクロール遅いのと、あとComboBox開く時も1秒くらい固まる
コレクションのバインドがうまくいってないのかな
早急に直してほしいわ
アプリ落ちるわけじゃないけどVSの出力見るとめちゃくちゃエラー吐いてて不安になる そっか、previewとは言え何かひどい品質だな...
しばらくはUWPの方で開発進めて、必要あらばコピペで移行... 1〜2年はWPFで様子見かな。
UWPみたいに始まる前にオワコン化の恐れもある。 WPFは見た目がな...
ModernWPFも何か更新止まってるし、やっぱオープンソースとはいえ個人に頼るとこうなる..
WPFはスタイルぐらい最新にしてメンテナンスしてほしいわ
切り捨て半端ねぇ 使ったことないんだけど、XAML islandsってどうなの
あれ多分UWPと同じスタイルでしょ？
と思ったけど、調べてみたら結構書き方めんどくさいねあれ
.netバージョンとかターゲットWindowsも制限あるみたいだ うん、俺もそれ考えてちょっと前に調べただけだけど、特定のラッパーコントロール用意されてなきゃ、xamlで使えなくて、プログラムでゴリゴリ書くのか??
と思ってそっと閉じた... 2年くらい前にisland使ったときはシームレスにスタイル設定する方法分からなくて挫折した vs 2022,.net 6とかどうでもいい
そんな事よりwinui 3はやくどうにかしろよ End of Support
.NET 6 LTS November 08, 2024
.NET 5 Current May 08, 2022
.NET Core 3.1 LTS December 3, 2022 >>208
まあ、サポート期間を厳格に気にする組織だったらこんな短命なもん使い物にならんわな
デスクトップアプリをCore系で作る場合は基本的には自己完結型実行ファイルにしてランタイムを丸ごと同梱するから、
例えばC++のアプリに同梱orスタティックリンクされたランタイムライブラリのサポート期限切れが問題になるだろうか？というのと本質的に同じ話なんだけど、
.NETは昔からどうしても運用側がバージョンを気にするから見逃されにくい面があるね >>209
大企業は嫌がるだろうね。
せめて3年は欲しい。 windows appsdk 1.0
11月16日
くそのまま出荷 dll同梱にしたらWindowsUpdateしてくれないんだよね？ >>212
もちろんそうだけど、システムに.NETを入れようと結局サポート切れ問題は避けられないよ
5から6みたいなメジャーアップデートがWindowsUpdateで入ったら互換性ブチ壊しだから流石にそれはMSはやらないだろう 同梱とかやるくらいなら.NET Native行けばいいんじゃないの .NET Nativeは長いこと放置されたままで、事実上死亡したよ
今後.NETに加わる予定のNative AOTはXamarin由来の全然別系統の技術だし、それも出る出る詐欺で終わりそう 短命なのが嫌なのに放置されたら死亡扱いって何がしたいのだろう 何を言ってるんだ？
.NET NativeでWPFは使えないんだから、このスレで引き合いに出すってことは将来的なサポートを期待してるんだろ？(君が無知なだけの可能性は置いといて)
放置されている時点で望みがないでしょ 開発マシンでこれが出てアプリ起動できなくなって無事死亡 今やってるのを一区切りつけてからじゃないと新しいのに手を出せない俺
それまでにFixしといてくれよ アプリを.NET 6に載せ替えたら処理の引っ掛かりみたいなのが大幅に改善された 結局WPFが生き残るのか。
もうWPFをバージョンアップしてくれよ。 propptabtabのためだけにprism入れてるわ ViewModelのベースクラスってもう標準で用意されてるんだっけ？ Microsoft.Toolkit.Mvvm.ComponentModel.ObservableObject WindowsCommunityToolkitのObservebleObjectは？ ViewModelのベースクラスだけでいいなら別に1分で自作できるしな
後、DelegateCommandも自作。
これ以上求めるなら既存のパッケージ使った方がいいが
後、これにMicrosoft.Behaviorsと必要ならReactivePropertiesなりを まぁ、MVVMガチガチでやるならそこら辺のベースパッケージに他のPub/Subのメッセージ機能だのいろいろ含まれてるだろうから使った方がいいかも知らんが
俺は多少のコードビハインド上等!!で緩くMVVMやってるから でも、今はそこら辺もコードジェネレーションさせるのがはやりなの?
全く知らんが 自作コントロールをコードビハインドで作ってね、というのがwpf元々のデザインなのかね？ そいやMicrosoft.Toolkit.Mvvmって使ったことなかったな・・・ >>226
UWP切り捨てなきゃだめだよな
win8以降のストアアプリ・タブレット互換路線は黒歴史 世に出る前から黒歴史になるって言われてたのに強行して出して案の定黒歴史 MSはダメなんだよ
まともにアーキテクチャーを考えられる人材がいない 明日のcommunity callと共にゴミ品質のまま正式リリースですか? どうせ誰も使わないんだからノープロブレムよ
MS自身も分かってやってるんだろ ちゃんとサポートしてくれるならいいけどね
どうせいつもみたいにすぐ飽きて放置プレイだろ winuiってウィンドウのサイズが変更できないとかそんなことみた気がしたけど
どうなったんだろ 同じ時期ぐらいに発表されたjetpack composeは順調なのに、mauiは延期でwinuiは品質低すぎって..
流石片手間プロジェクト 現実的な打開策として、WPFを強化するしかないんじゃないの？
UWPベースのものはプロトタイプとしてきれいさっぱり捨てて、
WPFにWin10〜11のルック＆フィールとx:Bind足すだけでWinUIよりも数段上のものが出来上がる。
ウィンドウサイズの件もそうだけど、WPFならデスクトップアプリに求められるあれこれを既に持っているんだから。 >>256
SizeInt32 Size { get; }
読 み 取 り 専 用 >>257
Resizeメソッドあるやん
触ったことないから知らんけど ElectronをWindowsでネイティブサポートするのが唯一の正解
Slack等が軽量爆速になれば数年前からMacしか使ってない俺でも乗り換えを検討するわ 1.0なのに試験段階っていうのがよくわからん
バージョンナンバーの使い方がおかしい ロードマップ的にそろそろ出さなきゃ。
でもまだ品質が全然…
そうだ！ stableってMS語だとalphaくらいの勢いだろ Dependencyとかアホかと
いい加減やめればいいのに... WinUIの100倍高速なWPFがまた勝ってしまった 不毛なMVVM論争に始まりこの界隈腐り切ってるな
もうこんなゴミ捨ててWin32でいいだろ >>269
これはmanaged,unmanaged間のinterlopのオーバーヘッド?
つまり、c++/winrt使えば問題ないのかな.. コンポーネントを書く時に今時インターフェイスをIDLでシコシコ手書きさせられるあのC++/WinRTでつか WPFはコントロールテンプレートで実装丸見えだから細かい改善はやりづらいだろうね
コミュニティによるコントリビューションもいくつか入ってるみたいだけど、
そういうのもWPFの場合は作法に合ったコントロール作るの無茶苦茶難しいからかなりハードル高そう resizeBitmap.Save("xxx.bmp")でセーブしたらPNGフォーマットのxxx.bmpファイルができちもうた。 こんなもんなの？ >>281
BitmapSource src = null;
// srcを設定
using (var fs = new FileStream("xxx.bmp", FileMode.Create))
{
BitmapEncoder be = new PngBitmapEncoder();
be.Frames.Add(BitmapFrame.Create(src));
be.Save(fs);
} >>277
IDLでしこしこ書いてもいいけど、簡単にマージできないよね??
これが最大の問題だと思う
よし、プロパティを追加しよう。IDLを修正。IDLからコード生成。
生成させたコードを既存のコードを壊さないように手動で合体? とういうかプログラミングってシンプルイズベストだろ
ややこしくしすぎてMSの中の人もわけわかんなくなってそう MSからWPFのベストプラクティスが出てこないのがその証左だろうなあ MSはVSの開発で実践したじゃん
> WPFのベストプラクティス
WPFの設計思想とか無視して低レイヤの機能だけを使用し、上に独自のフレームワークを構築するのが正しいWPFの使い方だよ ただでさえVS2008で実装すべきだったのにVS2010まで遅れた上に
独自フレームワークにしてしまうとは、VS開発者がWPFにブチ切れしてたのは想像に難くない。 １．VS2022でWinUI3のプロジェクト作成
２．EF CORE SQLite を Nuget
３．EF CORE TOOLS を Nuget
２までだと問題ないが、３までやるとエラーで止まる
.NET 5 では問題なかったんだけどね
対処法はマイグレーションを暫く諦めるしかないのかな windows appsdk 1.3ぐらいになったら呼んで 1.2から2.0になった時は起こした方がいい？
また不安定になってそうだから2.3まで待つ？ 291だが、
UWPと同じようにDBのクラスをクラスライブラリプロジェクトにするなど色々やると対応できた WPFの置き換えならAvaloniaはアカンの？
マルチプラットフォーム
WPFとほぼ同じ書き心地で書きづらい所改良済（移植も容易）
標準でモダンなUI搭載
標準でMVVMなテンプレート用意済
Rx(ReactiveUI)との親和性高め
主要なIDEでのサポートやプレビュー搭載済
それなりの規模で開発継続中
プロダクトには使えないだろって言う人もいるけど
WPF
+MaterialDesignInXamlToolkit or モダンなUIフレームワーク
+ReactiveUI or ReactiveProperty
+Prism or 他のMVVMフレームワーク
最低限これだけ外部のフレームワーク準備しなきゃ現代的なアプリ作れないWPFもどうなんって感じですけどねぇ
現状IMEのサポートが弱い点が痛いけど、最近割と優先度上げて対応してるし
もっと使う人増えてほしいな >>295
個人の趣味ならともかく業務ならWinFormsの代わりとしてのWPFの使い方で十分メリットある。
ReactiveXXもMVVMも使用禁止。 https://visualstudiomagazine.com/articles/2021/04/20/vs-2020-feedback.aspx
によると WPF & .NET Framework のまま
視聴者コメントではなんでCore移行しないのかと批判されてるけど、その答えはたぶん次はElectronになるからだろうな テレワーク需要でHiDPIとか複数モニタでもまともな見た目にしろって要件増えてきたから、WinFormsはちょっとね…
>>297
RxはともかくMVVM禁止で作られた業務ソフトって想像つかないなぁ
テストのこととか考えたら単機能ソフトしか作れなくないか 業務ソフトなんかほとんど人力テストだよ
手で操作してスクショ取ってExcel方眼紙に貼るの >>302
結合テストは入力が人力テスト同等じゃないと受け入れてもらえないからね
殆どの案件が人力による総合テスト
エビデンスはExcelへの画面キャプチャ張り付け
単体製造時のみ単体テストコード WinUI3など要らないなんて言っても、イベントのバインディングは便利だぞ
ブレンドのビヘイビアでも出来るけどアレは面倒だ 内部はともかくガワだけHTMLベースに変更は普通にありえるんじゃないか？
しれっと変えてもなんか綺麗になったなくらいで気付かない人が多いと思うぞ
VSCodeのエクステンションが使えるようになったりするかもしれないし良い事ずくめ >>298
Hi-DPI対応と全ての画面をレスポンシブ対応完璧にやってるならWinFormsでもいいけど。
WPFで作った方がはるかに楽だよ。 >>301
WPF使ったプロジェクトでMVVM採用してるのは自分が自己満足で採用した1例しか出会ったこと無い。
WPFでのMVVMはフレームワーク使用ありき（勉強目的以外で自力でやるのはただの馬鹿）だけど、
最近までMS公式とかそれに準ずるようなライブラリがなくて業務では使えなかった。 >>311
それは片寄った経験だな
企業向けで10案件ぐらい経験してるけど全部MVVMだったよ >>311
もしかしてサードパーティー製を一切許さないタイプの職場？ >>313
まだまだ多いよ。ライセンス表記したくないから余計なものは入れるな、とか。
市販のコンポーネントの方がまだ利用障壁は低い。
ASP.NETだと最初から色々入ってるからちょっとぐらい追加してもバレないけど。 >>314
そういえば昔 MVVM light は倫理規定で使えないから互換品の作成を依頼された事がある 大手でもライセンス表記して普通に使ってるのに零細の妙なこだわりはようわからんわ もうlinux使ってないテレビなんて売ってないんじゃないかなあと思う winformsからWPF+MVVMってのがそもそも飛躍なんだよな
もとのwinformsはMVVMだったのか？ってことだよ
MVCとMVVMの比較ならわかるが 確かにすごい飛躍で俺も大変だったが、他の環境でも同じじゃね??
例えば今androidで開発始めるとしても、jetpack composeだと宣言型+MVVM(MVなんか)だし
flutterやるとしても同じもだし
SwiftUIも..
もちろん、今までのビューベースの開発もできるが いや、ASP.NET MVCはMVCで作ることを前提としたアーキテクチャだけど、
WPFのMVVMは後付け。MVVMありきじゃない。
アプリケーションの性質によってMVVを採用するべきか毎回考えるんだよ。
Template StudioでもコードビハインドかMVVMを選択するようになってる。 >>318
地デジTV出てからどんだけ経ってると思うの？ まだMVVM界隈は宗教論争やってんのか
10年近く進歩してないねえｗ UnoPlatform 4.0
MVU-X
avalonia UIもゴミ品質だしUnoもゴミ品質だし
みんなでリリース分散して自滅するという プロパティにget set initだけじゃなくて bindを追加して自動実装してくれたらもっと普及していた可能性も…
ないか… >>324
フォームおじさんはそもそもwpf使えない
xamlにビビって逃げ出しちゃう >>329
WinFormsでポトペタするよりは数倍効率的だよ。 XAMLなどという安易なオレオレDSLを濫造した結果、
辻褄合わせの不完全な無理筋アーキテクチャが誕生して技術者に愛想つかされて廃れてしまったのがWPF 最新リリースのフレームワークでもXAML使われてるしね あわしろ氏もMS言語はベンダーロックインされるから避けろと言ってる。 Xaml はそもそも出が bland 用の言語なので！(￣▽￣;) UWPからWinUI３に移植しているが、Null関係で挙動が変わって落ちるのが多い
nullableが無効でも落ちるんだから、デバッグ不足なんだろうか？
例えばstring[]のプロパティーをSelectMany掛けたとき、プロパティーがnullだと落ち
以前のバージョンならnullでも落ちることはなかった
まあC#言語自体の問題だからWinUI3は直接関係ないが エラーと落ちるのは別問題だしnullチェックは実装側がチェックするんじゃね SelectManuでnullって元々例外にならん？ https://github.com/lepoco/wpfui
これなんなの
ModernWPFに続いてこれ
また中途半端で終わるのかな ちょっと前も書いたがModernWPFも更新停止してて
Microsoftが強力なリーダーシップとらんからavaloniaやUnoPlatformとかみんなで戦力分散してどれも中途半端な品質になって全滅
つか、UnoPlatform 4.0でVisual Studio Codeや色々対応したぞ
これっぽっちも話題になってない XamarinでなくUnoでいいだよな。
Xamarinチームのろますぎる。 unoってxamarinに乗っかってるんじゃなかったか unoしてみようかと思ったけど
xamarinとかいれないといけないからやめた Reactはいかにも欧米的な徹底したトップダウン指向で、島猿には馴染みにくいところがあるよね
本来MVVMなんかも根底の思想はトップダウン設計なんだろうけど、見た目から入ってそこからVMを抽出するようなボトムアップな作り方でもなんとか形になるんだよ
対してReactはそうはいかなくて、抽象から具体へ一方向にデータを流す完全にトップダウンな構造が強制される
外人のいう、MVVMはビューとの細かいインタラクションがうざいみたいなのって日本人には理解しにくい感覚だろうな WPF MVVMからReactに移行すると
あまりの簡単さに衝撃をうけるよな
簡単、極めてシンプルかつ必要なコード量も桁違いに少ない
あと驚くのがvscode使ってのデバック性能が桁違いによい
XAMLにブレークポイント貼れないとか笑える
MVVMで議論される事って
MVVMみたいな個性的な仕様を持ち込んだから発生してた事が良くわかるぞ >>338
候補として二人居る:
1. あわしろいくや(UbuntuLinux、OpenOffice、翻訳家)
2. プログラミング関連のYouTuberにあわしろというどっかの企業社長がいる。 >XAMLにブレークポイント貼れないとか笑える
どういうことをしたいんだろ >>360
間違った。
2は、「エンジニアチャンネル」の「粟島」だった。
だから、1.かな。 バインディングで値の変更が発生するタイミングに貼りたいことはあるなあ 証券のリアルタイムクライアントをWPFで
実装してた時とか
インジゲーターの発光条件のようなちょっとした判定がXAML内にあると苦労する
そういう時はコードビハインドで書いた方がよかった >>363
VMのプロパティに貼るで不足に思ったことは無いなぁ。
PropertyChangedがちゃんと飛んでいるか疑う場合とかかな。 散々言われていることだが
x:bindをバックポートしてくれるだけでかなり作りやすくなるのだがなぁ
全然完成しない次期UIプラットフォームよりWPFを拡張した方が実用になるんじゃないか 頑なにバックポートしないのはつまりそういうことだぞ
諦めたら？ flutterの方も4か月に1回リリースするから
今月にリリースくるかな
flutterのwindows,linux対応どうなってんのかな winui3待ってる間にflutterに浮気中なり・・・ フォームおじさんだったらflutterでも何も理解できないんだろうな WinUI3のWindow制御は、よく読むと必要な情報も機能も全て用意されているのは分かったが
AppWindowPresenterという概念を理解する前にuser32を使い始めたのが敗因だったわ
一応動いているけど作り直さんといかん
流石にwpfよりはちゃんとしている Flutterで作られたWinアプリってなんかあんの？ >>375
あんなの用意されてるとは言わんわ。
windows api使えば泥臭いけど色々できます、と同レベルやんけ。 WinUI 3触り始めたけどこれ現代版WPFみたいな感じだな
違和感が少なく作業できたわ ほぼ同じ感じだから使いたいんだけど、datagridやComboBoxのバインディングのエラーが改善されないと正直使い物にならないかなあ
かなり目立つし致命的なところだと思うんだけど、なんで放置されてるんだろ このスレでグチグチ言われてるのは、品質とパフォーマンスだね.. パフォーマンスはともかく
MSに品質を期待するのは野暮ってもんだ フレームワークの導入なんて最初でケチが付いたら当分は様子見になるから
初期リリースから完成度上げとくべきなんだけどMSは過去から何も学ばない 描画の負荷が軽くパフォーマンスはいいと思った
バグが表面化してるのがやばい 確かに０．８は酷いものだったが１．０は割と安定しているけどな
もしかすると触らずにネットの噂と印象だけで騒いでいないのか？ MSの.NET部門ってインターフェースを後から変えづらいAPIやフレームワークの開発ばっかりやってるから、
小さい機能セットで完成度の高いものを出していくという発想がないんだろうね
VSCodeみたいにデリバリー重視でMVPから開発していくスタイルで後から破壊的変更されまくっても困るだろ >>385
いやいや、ItemsControl系使ってみんひどいから
>>269のリンク先みた方がいい
バグに関してはちょっと本格的なアプリ作り出すと踏むこと間違いなし
俺は既に数個報告してるし
もう触るのやめた まぁGAFAMにいるソフトウェアエンジニアすべてが優秀ってわけじゃないし…
MSはその中でもひとつ落ちるというか、中の下〜中の中くらいのプログラマを多く抱えてそうなイメージ >>389
インターンが作った拡張機能とか公式で公開するレベルだからなあ >>269、よく見たら2019年に書かれてるじゃん
優先的に直すべき事象だと思うんだけど、今の時点で直ってないってことは修正には期待できないのかな
これがなければ普通に使いたいんだけど... >>393
依存関係プロパティーはかなり遅いようだが、対WPFで考えるとBinding VS x:Bindのアドバンテージは別に有るから
トータルでどっちが早いとか遅いの情報がないと判断つかないわな
テストはバインディングせずに直接依存関係プロパティーに値を入れているベンチマークだからね >>197だけど
x:bindとかでどうこうなる次元じゃない遅さだと思う >>199に書いたとおり、x:Bindでもクッソ遅い場面がある
使用に耐えないレベルだった
ただ0.8.4までしか試してないから、もし1.0で改善してたらごめん 1.0の正式版とそれ以前では違いそう
.net 6も正式版の直前までパフォーマンス酷かったし 1.0
>これはMicrosoft Windows App SDKの実験版です。
おやすみ WPFはいつ如何なるときもMVVMで作るのが良い設計だと思い込んでるWPFビギナーを何とかしてあげたい。
誰が戦犯だ? 使い分けた方が良いと思ってそうしてたけど
想定外に規模が大きくなって後からMVVMに直す方が手間だと気が付いてからは
確実に大きくならないのが分かってる時以外はなるべく最初からMVVMにするようにしてる 所詮ビューをどう作るかの問題でしかないのにそんなに大した話かね
作り方が悪いんじゃない？
VMにビジネスロジック書きまくってそう 良い悪いというより慣れるとMVVMが楽になる
イベントハンドラにコード盛り付ける時代に戻りたくない 配布する際のexeやdllを難読化（逆汗防止とまでは行かなくても）する有償無償問わずお勧めのツールありますか？ 昔:全部staticでええやん
↓
今:全部MVVMでええやん MとV以外に定まった構造なんてない
MVVM原理主義者なんて無視が正解。相手するだけ時間の無駄だから まあフォームズですらビジネスロジックは切り離すしな いや切り離したらデータ検証など分割、重複してめんどくさくなるから全部Viewでやったほうが簡単
ユーザーエクスペリエンスが高くなる
wpf向けのエラー通知装置が何種類もあり迷走しているのが何よりの証拠 おまえらReactとかやんねーーの？
意味不明のXaml覚える半分の時間で
Reactマスター出来んぞ
その上でXamlまたやるなら大したもんだと関心するけど WEBアプリは来年ですら動作が怪しいからやんねーよ Reactが人気みたいだけどVueでweb入門してる >>407
WPF全く関係ないけど"ConfuserEX 2" .net nativeが御存命なら何も問題なかったのにな >>419
ありがとうございます、試してみます。
ちなみにWPFで難読化かけると、バインディングなどリフレクションで解決する変数をpublic以外にすると
難読化されて変数名が変わってしまい上手く動かなくなるなんて弊害もありました。 なんでネイティブアプリ作らせようとしないのか不思議だよなあ >>399
1.0には安定板と実験版の二つがあるんだよ >>424
今時WebサービスはSPAだらけだぞ
SPAが出始めた当初の、一昔前でいう全面Flashのクソサイトみたいなイメージのままで止まってるんじゃない？
意外に普通のサイトでも普通に使われていて、もはや全く特別なものではなくなっているし君も気付いていないだけ >>422
「一般人には"難しい"インストール作業が必要」だからでしょ。 >>426
zipファイルを右クリックして展開、中のexeをダブルクリックするだけ >>427
それだとダウンロードしたファイルの実行許可みたいな処理をしないと起動しないな >>415
ウン千行のMainWindow.xaml.csでも量産してるのか？それともpartial祭り？ モデルを再利用しないならぶっちゃけ全部ビューに書いた方がメンテしやすいよね >>432
VMは作る必要ないが、切り出せる処理は可能な限りModelに切り出したほうがメンテしやすいだろ MVVMか・・・
ドメイン駆動開発には必須だが、カスタムコントロールをListView->GridViewにDataTemplateで埋める時なんか、
DataContextがListViewのItemSpurceに固定されて二段階ペアレント遡りとかマンドクセーんだよな。
コードビハインドでやった方が簡単だし速い。 >>434
一度React等の1-way dataflow系のUIフレームワークに触れてみることをお勧めする
MVVMなんかに戻る気しなくなるぞ この件に関しては何であるかは関係ないだろ
XAMLがそうなちゃってるだけでflutterや他のフレームワークでMVVMやれば>>434の件とか自由にできるだろ?? VMがあるがVMは最小限にして他はコードビハインドに書くという新たなるデザインパターンを発見してしまった pythonに描かせたチャートを表示する方法おしえてください Reactは俺も使ってるが、WebアプリもWPFみたいに開発できたらもっと楽なのにと思う。 >>439
Vue.jsとか使えばjs+MVVMで開発出来るでしょ もう10年ぐらい前から
backbone.jsがmvvmしてますよ winformみたいに楽に開発できるようにはなりませんかね。 どこが難しいのかわからない
やろうとしてないだけじゃないの >>444
難しいじゃなくて、
めんどくさいんじゃねーーの？ VSCodeがある時点でWPFよりオワコンじゃないんだが そのVSCodeの元になったATOMがElectronを捨てた >>437
VM最小限ではないだろうが、反応速度をトリミングしていけば、普通にそうなるんじゃね？
最初はActiveCommandやeventtriggerバインディングを駆使してストイックにビハインドコードを汚すまいとするが、
やっていくうちにBindingからeventへの悪魔が食指を伸ばしてくる。
Coreに必死でロジック入れまいとするが、DomainやInfrastructueから自然と入ってきて汚すDDDみたいなもんだよ。 そこでWinUI3ですよ。x;BindでイベントをVMで処理できるし、のこりはサービス作ってVMにインジェクションすりゃ良い
1.0になって地雷が少々残っているものの動作は軽快になって実用的になっている >>443
wpf使えばwinformよりは楽に開発できる >>443
wpfでmvvm捨てれば同等までにはなる >>448
githubがMSに買収された時点でatomはオワコン決定だろ GitHub クローンで、Ruby on Rails から、Go へ移行しない、
GitLab が上場して、時価総額が2兆円！
だから、Go へ移行するGitHubは、2兆円以上の価値がありそう >>453
イベントドリブンごりごりで描くならWPFの方が劣るかな
GestureTextとか変なところで手間かかる >>443
>>453
>winformみたいに楽に
って言ってるんだからMVVMを使わないのは大前提。
WPFの方が楽。
同等レベルだったらわざわざWPF使う意味はない。 Winアプリの構造がメッセージループである以上、
MVVMみたいに本末転倒で過度な抽象化をするとインピーダンスミスマッチでもっさりするのは必然 まぁ DomainのRepositoryが全てのSOLID原則の中心になっているようなものだからね。 抽象化で遅くなるのは仕方ない。
描画やIOディレイもっさりに関してはasync/syncやUser32.dllのPostMessge、WndProcで高速化しているのがハイスキル連中のテクニックとちゃう？
プロはリリース毎のコスト上昇にほとんどの神経を尖らしているので抽象化肥大は避けられない。 コスト上昇が飽和しなければ、プロジェクト崩壊している事になる。
MVVMはTDDの必須構造。 >>459
レスポンスを追求するならVに全て実装するのも最適解のひとつだよ 賢そうに見えない話を続ける人達にあれがよいこれがよいと推されてもねえｗ >>462
もっと賢そうに見えない人がそんなこと言ってもねえw M(VV)M フォッフォッフォッ
賢い人ならバルタン星人に見えます。 ネットや本のサンプルコードはWinforms ばかりなのは楽だから たからmvvmはblend前提のアーキテクチャだから
blend使わない時点で... ↑wpfのmvvmね
knockout.jsとかvue.jsのmvvmは結構使える mvvmがwpf特有のものだと思い込んでる人いそう 大半は開発者はmvvmなんてどうでもいいと思ってる。
そして大半の開発者はWPFは面倒だと思ってる。 切り捨て大魔王アップルと同じスタイルですな。ｶｯｺｲｲ >>458
高DPI対応のレベルが全然違うわ
今から新しくWinFormアプリシステム作る意味は無い >>472
高DPI 対応ですか…またやっかいなものが
GetDeviceCaps
がテキトーな値しか返してくれないし 4Kモニターが普及してきたし高DPI対応はもう必須やろなあ そんなに優れたアーキテクチャーなら15年も鳴かず飛ばずで一体何をなさっておられたのでしょう？ うちの周りだと普通にWPFで「いまさらForms？」みたいな雰囲気なんだけどそのへんの温度差がすごいな。 うちの会社は逆だ
WPFなど使い物にならんと随分前に見限られてる
UIはネイティブが第一選択でそれが無理ならFormsだな
俺がWPFを提案したとき上司にそんな物プログラマーが一時の流行りに乗りたいだけですぐに廃れるって一蹴された
まぁ結果論だが上司が正しかったのかな >>472
ボケボケのアンチエイリアスを高DPI対応と言われましても >>478
当のMicrosoftがWindows10になってもOS標準のGUIをWPFに置き換えに失敗。
結局は非スケーラブルなWindows GDI残渣を片付けられなかった事で、
WPFへの支持も得られず、一足先にSilverlight 、Xamarinも終焉を迎えたもんな。 Xamarinは日本政府も採用してんだから終わってない >>482
あれ反応したことないｗ
Xamarin採用に起因する不具合なのかね しっかしここまで「WinでGUIといったらこれ！」っていうフレームワークが存在しないのも凄いよな
どれも一長三短くらいなもの達ばっかりw
これじゃ初学者も何やりゃ良いか分からんだろ >>476
それが一般的なレベル。
デスクトップアプリを何で実装するかで技術レベルを測ってる企業もある。
今更Forms使ってれば最低レベルってことが一目瞭然だから。 >>485
C++ならキラーアプリMS-OfficeのフィードバックのMFC、
C#なら高速で人気のあったVCLの後継、winformだった。
実績もなく机上の空論で実装された低速なWPFをMSが押さなければ混乱なんてなかった。
VS開発チームすら採用に難色を示した出来の悪さ。自慢は高DPI対応。 今のマシンならWPFでも快適やろ
WinUI 3は今のマシンでも低速だけどw >>487
VS開発チームすら採用に難色を示したってどこの情報 >>487
ストアアプリやUWPは確かに混乱をもたらしたと思うがWPFとFormsは好きな方使えばいいんでは？
べつにそこ混乱する必要ないでしょ。 VS2010は出来が良かったな
2012以降余計な物が追加されてどんどん重くなっていって2017でリタイア
今じゃVSCodeに乗り換えた 前から思ってたんだがandroidのスレは過疎ってるのに
このスレ人だけはいるよな
俺はこの3,4年windowsアプリ作ってないがどうせお前らも似たようなもんだろ?? それは業務によるだろう。
うちは今もWindowsとLinuxのスタンドアロンアプリとあとWebだな。他の部署はAndroidもやってるが。 AndroidもiPhoneもWindowsアプリもWindowsドライバもやるよ >>480
フォントでしょ？
そりゃWindowsの問題であってWPFだろうがWinUIだろうが同じだろう >>495
うちは端末がWindows PCのシステムだからまだゴリゴリ書いてるよ >>493
VS2017の重さは確かに凄まじかったな
ただその後VS2019〜VS2021で大幅に軽量化されたから、暇な時に是非試してみて。第3世代のcore i5でもヌルヌルだったから驚いたわw >>493
2015から2017は軽くなった気がするけどな >>499
ジョブズがあの世から助走をつけて殴りに来るレベルｗ >>501
今2017メインで使ってるけど特に重さを感じたこと無いが。
初期のバージョンは違うのか？
メモリ8GBでCore i5のノートPCだから開発機としては並かそれ以下だと思うが。 >>505
何世代のcore i5？ここ5年位のIntel coreシリーズなら重く感じることは無いと思う
Celeron以下の貧弱CPU+メモリ4GBとか、Win7以前の時代のPCとかだと実感する 先月までcore i3 4150メモリ8GBでVisualStudio2019使っていましたよ。主にwpfですが普通に動いてましたよ。
一緒にAndroidStudioも使っていましたがこっちもそれなりに動いたけど、エミュレータが少し重かった感じ。
さらにHyper-Vでもう一個windows使うときつい感じだったかなぁ。 2017はPCリモートデバッグやRaspberryPI UWPリモートデバッグでちょっと遅く感じるな。
2019はOK。
2015はトンデモ。 フォントがぼけてたのって10年以上前の話だよな・・・
今はWindowsフォームなんかより綺麗だわ win7の頃のWindows PowerShell ISE って、滲んでボケボケだったよなｗ レンダリングの問題もあるのかもしれんが、Windowsマシンはハードの色んな組み合わせがあるからただ低DPIディスプレイ使ってる人が多いだけとか??
Macみたく高DPIディスプレイがデフォルトじゃないとか? マックもアイホンもアンドロイドも高詳細ディスプレーが当たり前になって、ギザギザしてるのはウィンドウズだけになった。 Windowsではグラフィックドライバや液晶モニタもゲーミング需要ばかり気にしてるからな。
4K8K や HiDPI よりも FHD@144fps 低遅延とか、大人やビジネスユーザを馬鹿にしてる。
もうね、ゲーム専用エディションでも別途作って分けてほしい。 モニタ2台でスケーリングサイズが異なる場合、片方がボケるのは諦めるしかない？ 画面に10cmまで近づいて使うための高詳細ディスプレイなんかWindowsにはいらん。
ド近眼で目が悪い奴ほど4k8k、高リフレッシュレートに拘るよな。 >>516
4K8KをDPIスケーリング100%で使うもんだと思い込んでない？ >>520
ど近眼だとスケーリング100%で使うってどんな理屈だよw ただでさえド近眼は画面に顔近づけて字がでかく見えるのに
スケーリング上げたらさらにでかくなるだろって理屈。
まぁ最初からド近眼が何考えてるか分からないって話だから話が通じなくて当然か。 自分も視力0.1ないけど眼鏡かけてるから50cmは離れて見てるぞ
裸眼で見てんのか？ あと例えば27インチモニターなら
WQHD 100%と
4K 150%が同じ文字の大きさな 物理的にUIが小さくなるHiDPIのスケーリング100%をなんでド近眼がわざわざ使いたがるんだよ
ド近眼じゃなくてお前の方が何考えてるのかわからんわｗ 10cmに顔近付けないと見えないとか近視じゃなくて弱視だろ その一方で老眼進行中の俺は、画面に近付いて見れば勝手にFormsの文字がWPFみたいに見える！ >>531
アクリル採用すると没個性だし、micaも9割以上の人は気づかない。
知ってる人がよーく目を凝らして見て気づくレベル。 おじさんたちってすぐ新しいものを否定するよね
ダークモードにすら対応してない糞アプリしか作れないんだろうなあ・・・(煽り) >>535
Androidはダークモード意味ありそうだしそれなりに簡単に作れるけど、Windowsはどうもやる気が起きない。 ダークモードなんてUWPで何もしなくても対応してたのに。 おじさんたちダークモードの重要性認識したほうがいいよ
ダークモードに慣れたユーザーはライトモードに戻れなくなる
ユーザーはライトモード眩しくて目が痛いって言いだすから
特にWinodowsアプリはデカいから白い画面出しちゃったら不快感がすごい どちらかというとおじさんの方がダークモードにしたがる。
若い子は白画面の方が好き。 おじさんだけどダークモードは目が疲れる
少なくとも明るいところでは背景白のほうがいい気がする Windowsだと黒画面はコマンドプロンプトの古臭いイメージがあってダサいみたいよ。 自分の好みはさておきユーザーの好みどおりに切り替えられることが重要 ダークモードめちゃくちゃ目が疲れるから苦手。
まともなカラーテーマにしてればそこまで目も痛くないだろ。 おじさんにありがちな自分が出来ないことを問題なしにしようとする癖が出てますねえ >>542
これよ
客「ダークモードにはどうやって切り替えるんですか？
俺「え？
客「え？ 俺はライトモードとかまぶしすぎ
ダークモードで輝度も低くしてるわ (暗くしたり暖色系のライトつかってる家の中ではね) まぁ、今時WinUI 3やUWPならダークモード5秒で実装できるようになってるが >>544
やってるよ、ダークモード対応。
でも何の良さもわからん。
寝る前にスマホ触るときぐらいでは？ >>548
しかしWinUI3のContentDialogとTeachingTipsのダークモードはバグってる
ContentDialogはインライン止めたらなんとかなったがTeachingTipsはどうにもならん WinUIでは関数がバインディングできるからXAML独特のバリデーションとかコンバーターに首突っ込まなくてよくなったみたいだな
ほかにもGridの書き方が楽になってたりWPFには戻れん 一時期はWPFで仕上げたVisual StudioのIDEすら作り直したし、MS自身がWPFを見切るつもり満々だもんなｗ 見切るというかWinUIはWPF 2.0みたいな感じだよ 中身がC++での実装になってるから本質的には別物だし 戻れン
のはいいけど7,8,9と走り続ける覚悟はあるの？ MSがこっちでやるって言ってるんだからWPFやWindowsフォームに残留して走り続けるほうがよっぽど苦労しますよ ただいまはスタートダッシュ決めたい人の時期だから
後でついていけばいいくらいの人は来年の4月5月あたりからでいいんじゃないかな
WPFより教えやすそうだからブログ記事とかも来年あたりから増えてきそう >>562
MSがこっちでやるって言ったストアアプリやUWPはあのざまじゃん。 WPFはダークテーマさえどうにかしてくれればずっと使えるぐらい安定はしてる でもその安定したダークスタイルがないので詰み
ModernWPF ? >>562
ストアアプリとかUWPに乗っかったやつは馬鹿を見ただろうけどな WPFおじさんがFormsおじさんと同類になろうとは… >>567
黒背景固定で作れば?
テーマ切り替えのパッケージも有名どころがいくつかあるし、
自前で作っても大した手間じゃない。
ただOSのテーマ連動「のみ」ってのだけはやめとけ。
スマホと違って複数のウィンドウを同時に表示させるPCではダークテーマだらけになるとどれがどのウィンドウだか分かりづらい。
アプリケーションごとにライトとダークをバラけさせておいたほうが視認性が上がる。 >>570
せやな、Javaおじさんが同類になるとは思わなかったよ…
… COBOL爺 >>570
そう考えると笑えるなw
人間誰しも歳取るとどっかの時点で新しい知識を受け入れなくなるんだなぁ >>570
WPFに固執してる人っていたっけ
デスクトップアプリ作るうえで消去法でWPFって人が多そうだけど WinUI3ってヴィジュアル系に不具合残っているけど
どうにもならないような不具合は１．０でかなり解消されているんだけどな 自由にファイルを置けるのはデスクトップとドキュメントフォルダのみ、各種設定は変更不可（もしくはリブートで設定リセット）、みたいな厳しい環境が増えてきてるから、xcopyインストールできないUWPなんか技術選定の段階で候補にもあがらなかったが、WinUIでようやくスタートラインに立ったかな。
あとは新しいことができるのは当然として、今までできていたことがどれだけ不自由なくできるかがポイント。
これプラス実運用に耐えられる品質とパフォーマンス。 WPFに出来てWinUIに出来ないものの大きなのは複数Windowだが
ページで組んでいなかった人には大問題なのかもしれんね
あとWindowsTemplateStudioが2022で動かないので、2019でテンプレ作成して
出来たクラスを移植するとなんとかなる
https://portal.productboard.com/winappsdk/1-windows-app-sdk/tabs/2-planned >>574
MSがWPF推してた時代にMVVMやってたような意識高い系の人達はみんなWebに移った メインウインドウの中にサブウィンドウ作らなきゃいけないな
マルチドキュメントインターフェースと名付けよう まだ新規プロジェクトの作成でMDIかSDI、コンソールなんて選択してるの？ ウェブっていえばマウントとれると思ってるおじさんなんだろう Windows11でウィジェットが追加されたけど、WinUIでウィジェット作れるようにならないかな
とりあえず今は対応アプリ少なすぎてあんまり使えないね 目が悪いので（盲学校に行ってた弱視です）
ダークモードは非常に見づらいので辞めて欲しい >>571
やっぱりダークモードって見にくいでしょ？ vscodeやvisual studioはダークテーマが疲れないね >>574
>>579
ここで言うMVVMおじさんってのは何でもかんでもMVVMで実装してしまう意識の低い人。
多分基礎的な事がわかってなくて他の実装方法を知らない。
MVVM使っておけば馬鹿にされないんでしょ？ってノリ。 >>590
そういう人が実際にいるとしたら、VMにビジネスロジック書いてるんじゃないかな
それはどっちかというとWebでよくあるエセWebMVCの類で、MVVMではない >>590
あらゆるところにMVVM使えと主張する奴がいたらそりゃ異常だがWPFに限れば別に普通なんじゃね？
ポトペタやりたいならわざわざWPF選ぶ必要もないし。 >>593
画面数が1〜2個、追加で何もライブラリを入れなくても作れるようなものまでMVVMでやろうとするならMVVMおじさん。 ？
「MVVMおじさん」じゃない人はその条件で何を使うというんだろう？コードビハインドにイベントハンドラで書く？
画面数が少ないからといってわざわざ別yのやり方するのも面倒だと思うが。
それとも、「画面数が1〜2個、追加で何もライブラリを入れなくても作れるようなもの」しかやらないから
最初からMVVMは使ってないってことかな。 MSのキラーアプリ群がC++からC#に移行しない時点でWPFは詰んでた。
結局C#で作るやっつけアプリはwinformで十分すぎた。 OracleがDBをJavaで書かないからJava終了という笑い話 WPF関係ないけどExcelを.Net対応に作り替えなかったの大失敗だろ そもそも.netの配列がアクセス時の範囲チェックで糞遅いから
大量データ扱うには結局C++、C、アセンブラで書くことになる。 >>595
実装方法はアプリケーションの性質に合わせてより適切なものを選択するべきであり、「面倒」なんて言葉が出てくる時点で技術者として3流。面倒なんじゃなくて知識が乏しいだけなんだろうが。
WPFでのMVVM開発はフレームワーク必須だと考えていて、フレームワークを使わないならMVVMを使うべきでない。
機能的にはコンソールアプリで十分なものの、利用者のPCスキルを勘案してUIをつける場合、exe1つで完結する方が利用者に親切。開発者にとっても無意味にソースファイルを増やすことなくメンテナンス性良く作れる。 >>599
そこまでやらなくてもunsafe使って範囲チェックを省略すれば相当早くなるよ だよな
unsafeで結構十分だよな
これがJavaだとJNIでCのコード書くことになるが >>600
後半の内容全く関係ないない話してるけど
詐欺師出身の方？ unsafeの突入コストがこれまた重い。クラス内で配列持ってると外からメソッド等でアクセスするとこの突入コストは避けれない。.netは遅くない、WPFは遅くない、unsafeがあると言ってる人たちは最初からその程度の要件だっただけなんだよ。速度重視の最適化で必ずぶつかる壁にぶつかってない。
だから速度が要件のアプリ、ライブラリではなかなか移行してもらえない。Javaと同じ轍を踏む必要はない。 範囲チェックの事しかいってないのに
どんどん後づけされてもきりがない WinUIのビッグウェーブくるぞ。
そしてWPFと同じく10年経ってなぜMSは移行に失敗したかって言うんだろうな。 UWPの,net nativeはunsafe相当の速度ってベンチマーク見たな >>602
U氏ならとっくにMVVMから足を洗ってるよ そりゃどこの世界でも原理主義者はそういうもんだろう >>614
UIデザイナーなんて碌な仕事しないという経験から直感で現場でWPFは使い物にならないと思ったPGは多かったが
実際そうだったのだからアホではなく単なる経験の差である。MSも移行してもらえなかったからwinformを捨てられないしね。
キミは確かに無駄な努力、遠回りしただけのように見えるがよく頑張ったよ、立派だよ。おつかれさん。 wpfはプログラムの出来ないデザイナーでも使えます！ >>615
何でMVVMの話がWPFの話にすり替わるんだ
まさかMVVM=WPFだと思ってるの >>617
そりゃここはWPFスレだからさ。なら最初からWPFは無視して
純粋にMVVMの話で限って言えば〜と先に断っておいてくれよ。
ボクはエスパーじゃないんだ。だがUIデザイナやMVVM連呼厨が
ユーザやPGのことなど全く考えてないことは経験として知っている。
MVVM論で言えば尻拭いするのはいつもPGと顧客だ。 >キミは確かに無駄な努力、遠回りしただけのように見えるがよく頑張ったよ、立派だよ。おつかれさん。
自分じゃマウント取りにいったつもりなんだろうけど他人からはアホに見えるパターン。
気を付けた方がいいよ。 MVVMの要であるBindingはListViewなどではイベント型でも避けて通れないものなんだからBinndingは習得するしかない
Bindを理解しているのにMVVMを避ける理由ってそれほどないよな >>618
WPFに限定してのMVVMか非MVVMの話だとしても
文脈を無視してWPFが使い物にならないとか言い出す意味が分からん 文脈がないのがUIデザイナー。ユーザの実務無視して見た目しか考えてない。マジ迷惑。
そんなことよりキミたちはよく頑張ったよ。その若さ溢れる才能で次のMVVMフレームワークをまた勉強したまえ。
WPFが登場して15年か。キミたちも相当に随分老けてないか。 「〇〇ができる」でマウント取るのは容易いことだが
「〇〇が出来ない」でマウントを取りに来るって
ある意味チャレンジャーだよなｗ >>623
キーボードスレにタッチタイプ出来ないことでマウントとる奴おったw 日本人のくせに効率のいい、頭にも負担が少ない「かな」入力ができないなんて頭に欠陥あるんですかね。
ボクはただの努力不足だと思いますよ。ガラケー使ってる私を馬鹿にしてるiPhone君見てると入力が遅くて遅くて仕事が遅いんです。どっかのMVVM論者ですね。 いつも思うけどW:PFやMVVMを批判する人はなんか必死だよねぇ。
それだけルサンチマンが溜まっているんだろうか。 MVVM、ひいてはMVCが理解出来ないVB6脳なんじゃないかと思っている WPFのは異常にめんどくさいMVVMだよ
他の知ってると馬鹿らしさ満点だから
しかも身につけたスキルが他で全く使えない
↑これが一番辛いぞ Reactとかと比べると別物だよなあ
考え方は同じにしても旧石器時代と現代くらいの違いがあるよ >>626
私はヘジのDOS時代のIDEに感動し、VCLのチート的な完成度にも妥協しwinformは最高だと思いましたよ。
そう言えば私がどれだけWPFに期待し、ガッカリしたか分かっていただけるかと。
そりゃあたたちMVVM信者の期待も無念に臥し、WPFは普及しませんでしたけどね。
この長く続くスレは負け犬たちの墓場なのです。 ReactのスキルをReact以外で使えたためしはないが、だからといって別にReactがダメだとも思わんがな。 >>601
ケースの1つをあげただけじゃん
後付け条件てｗ
読解力低すぎだろ 私は異常に面倒くさいってとこに同調しただけで、他で使えるとか使えないとかは論じてないのでご理解お願いしますよ むしろMVVMの考え方自体は同じである(他でも使える)とまで言っているんだぜ 相変わらずこんな熱いWPF批判をさせる何かがそこにはあるんだろうな。 大事なのはおまえは使えてもおれは面倒で使えないという事実だ。
神は越えられない試練は与えないのだ。 wpfの記述が長くなるのは何とかなりませんか？
Androidのレイアウトに比べて見にくくて仕方ありません。
複雑になりそうな時はUserControl作ってますが、例えばリストやコンボボックスの列のレイアウトを別ファイルに持たせることはできないのでしょうか？ DataTemplateをResourceに書いて外部化すれば良い >>638
ありがとうございます。初心者でDataTemplateの外部化がわからないので調べてみます。
よくあるサンプルで長々と書いてあるのは分けると説明がしずらいとかなんかあるんですかねぇ。 >>578
実質、WinUIはまだ使い物にならないって事か。
1ウィンドウページ切り替えのタイプで使い勝手を損なわずに済むものなんてかなり限られるし。
よくある一覧/詳細画面は別ウィンドウで自由な配置で見比べながら作業したいだろうし、
今の一般的な環境なら複数ディスプレイにそれぞれウィンドウを配置して使われるだろうし、
詳細画面は複数起動できたほうが喜ばれるだろうし。 wpfでデータバインド使いたい場合は
ViewModelにViewの参照渡してブンブン使っちゃえばいいのでしょうか DataContextにVMを入れてXAMLでバインドすんだろ >>640
Microsoft「ぜひMDIを・・・。」 >>644
いえ
反MVVM派のやり方が知りたかったのです
バインドは使ってない？
Viewのクラス(this)をデータコンテキストに入れているコードもありましたがこれは問題ありませんか？ WinUIならWPFほど何でもかんでもMVVMでっていう感じじゃないよ >>645
MDIじゃ親ウィンドウの外に出せないんだから
ページ切り替えの欠点を解消できない。 >>650
MDIを見たことない世代ですか？
イメージとしてはマックみたいな感じ
まず壁紙が見えない（他のアプリも）
マルチディスプレイ対応が無理ゲー WinUI始めてサンプルコードとか見てるとコードビハインドに書いていくのが基本
(WPFもだが)そのための機能は用意されてるわけだし
改めてMVVMは選択肢の一つというところに持っていきたい感じがする
実際、コードビハインドに書いて何か混乱が起きるようなことはそうそうないと思った >>646
MVVM派とか反MVVM派って考え方がおかしくて、
WPFアプリケーションごとにMVVMが適しているか、コードビハインドが適しているか考えて
その都度、より適切な方を選択するんだよ。 >>658
そんなものは無いから困ってる
WinUIは期待されてるけどどうなることやら 10年前からWinUIってあったのか完全にスルーしてたわ。既に普及に失敗してたんだな。 >>660
WinUI 2まではUWP専用だったから、まぁ当然の結果
WinUI 3で適用範囲を広げて仕切り直し 適用範囲広げてというかおすすめできるのはデスクトップのC#かC++かだけでしょ
WPFから使うとかUWPからつかうとかはやめたほうがいい >>655
寧ろイベントをバインディングできるから、コードビハインドと同じやり方でMVVM出来る >>657
もう確定だよ
アンドロアプリ作ってWindowsで動かす時代が目の前だ windowsの中でマテリアルデザインのアプリ動かすなんて違和感ありまくりだよな
https://github.com/bdlukaa/fluent_ui
flutterでfluent design
優秀 https://bdlukaa.github.io/fluent_ui/
web版のデモ
まぁパフォーマンス要求するアプリは専用の開発環境使った方がいいが 最新の宣言的UIフレームワークのcomposeのfluent design版もそのうちでてくるだろう 開発者に多い勘違いがクロスプラットホーム開発でユーザーが喜ぶと思ってるやつだな
ユーザーはそれぞれの環境で最高のもの作れって思ってるよ 一般ユーザーからしたら違いなんてわからないし作り方はどうでもいいでしょ、バグがあったら怒るけどさ >>666
fluentを名乗っているけどmetroじゃん >>672
これは確かにWindows PhoneのメトロUIだな。
これはこれで悪くない。
Windows 8のモダンUIは微妙だったが。 ん?
windows phoneのやつはWindows 8のメトロUIとは違うものなの??
windows 8のメトロUIとは似てないんだが
そもそもNavigationViewみたいのはないし
CommandBar(AppBar)はあったけど >>675
Windows8のUIはメトロじゃなくて「Windows8スタイル」とか「モダンUI」と呼ぶ。 WPFスレじゃなくて
最新Windows開発パラダイムを模索するスレ
になっとるな
どうせ過疎だからいいか メトロUIが実務でWindows使ってた人たちに拒否されたのが
GUIフレームワークライブラリの崩壊の発端。 >>679
実務でWindows使ってた人達がメトロUIに触れる機会なんてMS社員ぐらいしかいないだろ。
実務で使うWindowsにメトロUIは無かったんだから。 いまだにWindows8のツケを払わされている感がなぁ。
一回リセットしてWindows7からやり直してくれないかな。 地下鉄の案内見て目的地に着くのは無理では？
一貫性が無いし、わかりにくい。 >>690
アメリカの地下鉄は見やすいんじゃないの アメリカでは絶対に地下鉄に乗るなって言われたけど。 梅田の地下街で迷ったら半日潰れる。
GPS使えないし。 大阪メトロは外敵の侵入を防ぐため、わざとに錯誤させる案内表示にしてるって聞いた。 吉村が「明日から地下鉄を半額にするキリッ」って言えば良いのに。 Metro UIまではAppleも認めるほど優れていたんだが、
それをWindows8に移植してModern UIになったときには別物のゴミになっていた。 WindowsのUIは、少しずつ変えれくれればいいのになぁ
急に変えすぎなんだよ、見た目も中身も Metroは単に商標問題で負けたからModernに変えただけじゃね？
まあもともと、Windows Phoneには良くてもデスクトップ向きではなかったが。 実務しないマカーならともかく
フラットデザインっユーザーに与える情報量減らして何がしたかったのだろう。 わかりました。
Windowsはセキュリティを高めるために。
分かりにくくしたのです。
わざとです。
すべて。 >>703
狙ったのかどうかは知らんが、GDI+で影付き３Dに対応させるのは無茶苦茶面倒だったが
フラットデザインで最初から平なら気にすることもなくて簡単になった フラットデザインこれだけ定着したのにまだディスってるって化石人間かよ。 定着したからディスるなという頭の悪さは相当に脳ソミが硬化、粗大ゴミ化してると言えるが、
もそも定着したと思い込んでるところが相当に痛い。まさに化石人間である。 フラットデザインでユーザーに与える情報量減らすって、デザインの立体感が減っただけじゃね??
あのタッチしやすいようなスペース取りすぎで情報密度が減るのはフラットデザインと関係ないよな?? 半透明レンダリングなくしてGPU負荷減らして動作が軽くなったという効果はあったみたいね >>708
いや、フラットデザインは「押せるかどうか」の判断がつきにくい欠点がある
立体感はそれを判断させるのに効果的だったろ そんなの言われなくても誰でも想像できるし
そんなのすぐ慣れるから問題ないが
>>703の情報量はどうみても、フラットデザインのせいじゃなくタッチUIによる情報密度の低下のことしか思えない タッチUIで実務させようとしたわけだな。今までPC使ったことない奴しかできない馬鹿発想。 MS の中の偉い人ポジションが変わるたびに、その人のセンスに合わせて UI までごろっと変わるのは勘弁ね ボタンじゃないところをクリックしようと苦戦するユーザーを遠隔で見てほくそ笑んでいるのでは？
それがユーザーエクスペリエンス向上に協力するチェックボックスかも。 フラットUIでも押せる場所わかりづらいと思ったことないが... 大昔のOKボタンとキャンセルボタンだけなら分かるが、今は押せるとこだらけだからフラットでないとごちゃごちゃしまくりだよ。 単なる懐古趣味だな。Windows200とかXP,７をズット使いつづける爺さん結構居る キーボードじーさんより仕事が速いならとかもく、欠陥フラットデザインなんか好んでる奴は
仕事遅い、できない、頭の足りない奴ばっかだからな。>>ID:ccNKIwia ファミコン時代から3Dデザインで立体的に見せるとか当たり前でそれ以上前になるとテキストベース。
懐古とかいつの時代のこと言ってんだろう。 痛みを与えることで信仰心が深まると教祖が言ってたけど。 「押せるわけねーだろヴァーカｗｗｗ」って遠隔で笑ってるんだろなあ。 ウェブでは逃げるボタンとか、逆にクリックしたとたんにボタンが動いてきて勝手に購入されるとか。
最新のUIがあるもんね。
マイクロソフトはウェブ企業に憧れてるのかも。 メトロとかもうないのに何で盛り上がってるんだ？
実務ではWin8スルーでしょ？ そうだったな。時代遅れ、骨董品、懐古ってWPFとかWin8のことか。こりゃうっかり。 年寄りは脱線しやすいんだよ
上じゃ地下鉄の話しとるぞ これだけ言語や開発環境が進歩しても、ポトペタで作れるフレームワーク少ないなと思う それはあるね
なのでwinformでいいやってなりがち
webformはハシゴ外されてかわいそうだなと思う >>732
ノーコードとかの分野になっただけでしょ androidとかポトペタもできなかったっけ
昔ちょっと触っただけでうろ覚え
ただポトペタはとりあえず置いてみるのは楽だけどあとから修正するのが面倒でな >>736
Android Studioも中途半端にポトペタできるけど結局はXML直書きする事になる >>734
それはある
ポトペタで作れるようなものは今時ノーコード/ローコードツールで一瞬で作れてしまう テキスト表示して枠で囲んだものをキミはフラットデザインだと呼んでいるのですね。
罫線好きの日本人に昔、普及したワープロはすべてフラットデザインだった!!!って言いたいわけね。
そのネタでいつも周りはウケますか？ >>740
一番下のウインドにアイコン表示されてることも理解してないのか…
いつも周りからウケる以前にバカにされてるだろw アイコンが3Dデザインじゃないのをフラットデザインだ!!!と呼んでたのですね。
ドットも荒く白黒やグリーンディスプレイも多かった当時、立体に見せるために陰影をつけろとか無理筋ですからね。
高解像度化、カラー化で8bitPC時代に普通に立体デザインが普及したことからして単純に技術的制約ですな。 「クリックできないんだけど？」「そこはクリックできませんよ」という、人類が何兆回も繰り返したであろう問い合わせ。
それを仕組んだのがマイクロソフトdesign研究所。 しかし、Windows11はゴリ押ししてこないな。
何か心境の変化があったのだろうか。 >>742
> 高解像度化、カラー化で8bitPC時代に普通に立体デザインが普及したことからして単純に技術的制約ですな。
アホなの？
カラーじゃなくても立体デザインはできるしALTOとかは腐ってもワークステーションだから8bit PCと比較されても困るわw ドスシェルのテキストモードは影が付いてたな。
涙ぐましい努力だな。 文字コードに罫線が在るくらいだし、しかも縦細横太とかバリエーション揃ってるし。
こういうのが世界を混沌とさせてる歴史的遺物だろね。 >>745
後出しばかりでキミが当時を全く知らない知ったかお馬鹿君なのは最初から分かってるんだが。
知ったかしてGUI黎明期だのaltoをワークステーションだから〜だの頭がおかしいのか。
デモがせいぜいで当時の技術と価格で売り物、使い物になるかバカモノ。
ボタンだのスイッチだの陰だの物理的に既に存在していてそれが表現可能なら
誰でも実装しようとるすしおれも散々やったわ。子供だって紙と色鉛筆渡せば勝手に書き出すわ。 >>748
後出し？
黎明期のGUIでALTO知らんとかアホ丸出しだぞ
ちなみに出荷台数はALTO/ALTO-IIで、2,120台な
デモがせいぜいとか恥ずかしすぎるw ん？スペックの問題で仕方なく四角だけ書いてたのをフラットデザインと呼んではいけないってこと？ それはフラットではあるけど、それだけでは所謂フラットデザインとは呼べないのでは
知らんけど >>749
当時を知らないガキを虐める趣味はない。
昔を知ったかするには5chはじーさんばかりだから諦めろ。ネタならネタとして通せ。 漢字ROMだけでUIを作ってたワープロ専用機だって一生懸命デザインしてたが。 >>752
> 当時を知らないガキを虐める趣味はない。
必死に高解像度化とか、その価格じゃ売れないとか言ってたのに今更何言ってるんだよ…
恥ずかしすぎるだろw
> 昔を知ったかするには5chはじーさんばかりだから諦めろ。ネタならネタとして通せ。
お前が諦めろよ
ファミコンの前がテキストベースとか知ったかにもなってないし 書院、文豪でググったら3Dっぽくしようと頑張ってたわ。
机の引き出しデザインはなかなか革新だな。 どうでもいいことで爺さん婆さんが暴れてるな
そもそも現行のメインのFluent UIは操作性は良好だ ユーザーが直接触れる部分ですから、重要な話題と言えます。 スタートレックの操作パネルのデザインで
いいんじゃねーーの？ fluent designはもうちょっとコンパクトモードどうにしかしてくれないとな
情報密度の高いアプリ作るにはもの足りない >>759
何も考えず闇雲に手足を振り回すのは武術とは言わないだろ？
それなのに「これは何流？」って聞いているのと同じ。
使いやすく見栄えも良いフラットデザインにするには多少はデザインの勉強が必要。 勉強してようとしてなかろうと
ポリシーをもって何らかのデザインをしているのであれば何らかの流儀といえるでしょ
見た目にシッチャカメッチャカなら兎も角、過去のWSやMAC、DOS時代のGUIツールは
そういう類いのものに見えるな
後付けで「あれもフラットデザインと呼べる」と言って何が悪い？ >>766
>>751
とりあえずフラットデザインの定義をしっかりしてから話をしてくれ 本来、既に存在するもの、ボタンとかスイッチとかボリュームだとかをディスプレイ上に再現するときに
誰でも見て分かるようにすれば、何の機能を持ったコントロールか説明しなくて分かるんです。
そして元から3Dだったりするんで3Dデザインにすればより誰でも容易く理解するんです。そしてそれが普及した。
だがそこをあえて故意に必要な情報を消して、え？これなに？ ボタンなの？ラベルなの？って
ユーザーをおちょくるために考えた出されたのがフラットデザイン。根底に悪意があってこそフラットデザインと呼べる。そこははっきり定義として区別したい。 >>768
混乱する民衆を見てほくそ笑んでるんですよね。
神になった気分で。 >>768
3Dの反対がフラットデザインじゃないよ。
3Dのフラットデザインが今は主流だし。
勉強してきなさい。 >>773
今時のタッチパネルでもボタンにはグラデーションついて盛り上がってるように見えるし、
選択されてる、アクティブな要素には後ろに陰とかついてるよ。完全フラットデザインはなかなかないよ。
もしかして色覚異常とか弱視じゃないの？ それとも子供の頃からド近眼で3D要素が何か分かってないとか？ 既製品を使うだけならいいけど、カスタムコントロールで描画までしっかり作り込むとなると３D化は面倒過ぎるんだわ
だからフラットデザインだとそこまで手間かけなくても標準と同じフィーリングのものが作れるのは大きい
色違いのボタンを真面目に作るだけでもWinForms面倒だもんな ボタンに変な色をつけるとなにか意図があるのかとユーザーは混乱する。
そこで「ﾌﾟﾌﾟﾌﾟ、ただのボタンなのにw」とほくそ笑むわけですな。悪意の塊です。
先の定義のとおりそれはもう立派なフラットデザインです。 >>776
ボタンの数が増えると色を変えて操作性を良くするってやり方は
リアルの操作パネルでもよくある話
WinFormsを擁護したいんだろうが贔屓の引き倒しになっている 赤は危険とかエラー、黄色は警報、注意、とかブルー、グリーンは安全とか、
オレンジはスタンバイとか、一般に認知された色の意味というのはありますね。
ボクはボタンにそんな意味でも色はつけませんけどね。
ボタンの色につけるとボタンの字の色の組み合わせで視覚障害者に見えにくいかとか考えないといけませんからね。
標準ではない変な色つけたがるのは使う人のことを考えてないデザイナーに多く見受けられます。 >>774
3Dが何か分かっていないのはお前。
分かっていたらフラットデザインの対義語として出してこない。
完全フラットデザインって言葉もおかしい。
平坦ならフラットデザインじゃないんだよ。 そういえばリアルのゲームコントローラやマウス、キーボードとかでボタンの色がバラバラについてるものありますね。
あれで操作性がよくなるんでしょうか。デザイナーのKYなゴリ押しにしか見えません。 >>779
定義しろと言われて定義を答えたら、その定義を全否定はするが
自分で定義を一切説明せず、勉強しろと逃亡した人が戻ってきましたね。
いつも全否定はするが定義は絶対に説明しないマン。 >>777
ちゃんとUXガイドラインを理解したうえでそれでも不足するものを補うならいいんだが
この手合いはオレオレ定義でやっているのが多いから困りもん。 >>773
3Dのフラットデザインについて、デザインガイドラインとか実例とか教えてくれよ
おれにはお前が言うフラットデザインが理解できん metroやfluentよりwinformsが優秀と言い切るのにはドン引きですわ
webページのボタンが影付き疑似３Dってのはごく少数なことを説明してほしいものだ 昔はまだGUI慣れしていない層に配慮し、凹凸を表現した押せるボタンだという事を
見た目からイメージしてもらう工夫が重要だった。
でも今は誰でもGUIに慣れているから、そういった制約がほとんど必要なくなった。 WinFormsはとりあえず機能さえ最低限GUIで実装してればいいという手抜き用だろ
デザイン凝るならさすがにつらい デスクトップアプリの場合、デザインを凝るのが常に正義ってわけでもないしなぁ 凝らなくてもいいけど、最低限一人で浮かないデザインを html/cssでデザイン出来るならxamlは必要無いしな html/cssだけだとxamlに太刀打ちできないと思うけど >>794
何か？
デザイン性なら天と地の差だけど CLRオブジェクトに落ちるxamlとhtmlを比較しても意味がない GUIを記述するのに素のhtmlのままじゃ辛いよなぁ。xhtmlやjsxならいいかもしれんが。 >>798
今時のCSSやったことないなら黙ってたほうがいいよ >>800
CSSやったことないなら黙ってたほうがいいよ では論点はなんなんすかね
そもそもXAMLが比較対象なのかWPFに限った話なのか GUIのデザインをデザイナーに投げるならhtml/cssのほうが作業が捗る デザイナーに投げてもいかに奇抜で目立つか、
これでもかというカラーバリーエーションの見本を持ってくるだけで、
UIのことなど微塵も考えてない。芸術大学出身なんてそんなものだ。 >>805
デザイナーとアーティストを混同してない？
めちゃくちゃちゃんとしたもの上げてくるぞ。
芸大には建築学科もあればデザイン学科もある。 デザイナーとアーティストを混同しているデザイナーがいるんだよなあ >>808
野生のアーティスト気取りには多いが芸大卒にはほとんどおらんよ。 >>792
全然違うwww
レスポンシブとの相性も最悪w 寿司屋のタッチパネルとかよく見ると家族連れでそこボタンじゃねーからってところ連打してたりするんま >>812
どうせ勘違いするならトグナツィーニにしてほしいもんだよな 令和も4年だってのにまだ宗教戦争か
仲良いなお前ら >>818 ←なんでいつもこいつは上から目線でマウンティングしてくるんだろうな。 Microsoft StoreにWinUI 3 Controls Galleryってのが出てたんだな Google Trendsで
WinUI、WPF、WinFormsなんかをを比較してみたけど、
うーん… >>819
お前が地べたを這いずり回ってるから
普通に歩いてる人に踏まれてるだけだろ。 >>820
Xaml Control Gallerryと中身全く一緒でワロタ Xaml Control GallerryはUWP版でUWPからWinUIを使ってるサンプルコード書いてあるからちょっと違う Windowsアプリは結局Win32なンだわ
WPFとかMVVMとかほざいてた奴責任取れよ >>829
WPFでも64bitで動作せず32bit固定にするコンパイルオプションあるぞ >>199だけど、自分が書いたコードはそのままでWindowsAppSDK1.0と.NET6に変えたらそれなりに普通に使える速度にはなった
でも例の不具合自体は直ってない
githubでめっちゃ怒ってる人いるし早く直してくれやマイクロソフトさん
デスクトップアプリはサクサク動いてほしいよ きちがいみたいに反発してたやつらは正式版の環境にしてなかった奴らだろうな 正式版でも相変わらずゴミだぞ。
1.1の次あたりでようやく実用レベルに仕上がりそう。 >>834
そうか？いくつかバグに遭遇したけど頑張れば避けられる程度のものばかりだったが いや前より速くなったとは言ったけど正直まだ期待してたほどではないかな...
さらなる改善を求む そういえば動作の改善だけじゃなくて、コントロールのデフォルトデザインがWin11っぽいかわいいのに変わってたのが嬉しかったわ リリースビルドしたものをスタートメニューから通常起動した時には起こらない現象とかもある 特定のオレオレ基準を満たさないとゴミと言い切る人はいるな ノットフォーミーってキチガイみたいに叫びまくるのはtwitterでやってくれよなー そうやって現実を見てない連中が開発の中心にいたからUWPが死んだんだろうなぁ
何回失敗すれば目が覚めるのか 目が覚めるのが遅すぎる。
8割がた沈んでから目覚めてもそのまま沈む可能性大。
マルチウインドウなんて基本中の基本機能はver0.5ぐらいで対応しとけや。 WinUIはC++のライブラリだからC#のNull Safetyオンにしたら不都合があるのか？ >>839
まさにwpf信者、フラットデザイン信者のことだな。 ｗｐｆを知らないやつがイキってるな
ｗｐｆがフラットデザインだってさｗ せっかくフラットデザインの話が終わると思ってたらこれ..
そこまでして誰かをけなしたいのか... マイクロソフトの用意してるデザインが微妙にダサい、フォントにしてもUIにしても
そこはXAMLで入れ換えるかコンポーネント屋から買ってくると、見た目に金をかけると Windows11の角丸ウィンドウがダサい。
無理矢理加工した感があって浮いている。
スナップや最大化すると角丸が取れてみっともない状態になる。 >>853
Macはunixのパクリだよ
で、Linuxもunixのパクリ Macの前身のLisaはX Windowの一年前に誕生しております Alto、Star、Smalltalk、Lisa、Mac、Win の関係をはっきりさせよう
http://sumim.no-ip.com/collab/19 WinFormのパッケージがもう限界だっていう話になって
会議でWPF移行の話が出たが、もうオワコンだからWinUIにしようということになった
しかし性能が悪いと判明して暗礁に乗り上げた
VBとC#技術者大量に抱えてるからWebに舵を切るのも難しい
会社丸ごと詰んだ？ >もうオワコンだから
会議の場ではさすがにもっと具体的な根拠が挙げられたんだよな つーか今どきはどこでもWPFで作ってるよ、敢えてWinformsにしてる製品見たことない
限界というのも意味わからんよね 今の時期に移行するならWPF/.NET6でしょ
WinUIはもうちょっと待ったほうがいいし、WinUIは実質的にWPFの新バージョンなためWPFに慣れてる人はWinUIでの開発にすぐに馴染める >>865>>866
うちの周りもそんな感じだしそれが当たり前だと思ってたけど、このスレを見てると自信が揺らぐw >>865
ガチガチにレイアウトしてるからWinFormだと高DPIが辛いんよ
WPFって今でもアプデされてる？
x:Bindのひとつもバックポートされないんだが もちろん速いにこしたことないが、何そんなに速度重視されるアプリなの?
bindingとx:bindどれくらい違うか一度比較してみりゃいい
x:bindなんて気にしなくていいと思うが >>863
C#でWebをやればいいだけじゃね？
どのみち新しいの覚えなきゃいけないんだったら、さすがに今更XAML覚えるよりはモチベーション保てるでしょ asp.net mvcって書籍少なくない？
webformは腐るほどあるのに 普通のWebMVCだからな
あんなもん単にテキストでHTMLを吐くだけだ
そんな構えるほどのもんじゃない XAMLは今更ってものでもないし
Windows FormやWPFが候補に挙がってる時点でWebじゃない気がする
iOSやAndroidでもローカルアプリの需要あるしWebは万能じゃないんだよね >>863
現在のバージョンに限って言えばWinUIよりWPFの方が性能も自由度も上だぞ。
WinUIはまだβ版と言ってもいいくらい。
社内で使う小さなユーティリティ程度ならともかく、外部に出すものならWPFで作っておいて
1〜2年後、WinUIが実用に耐えられるようにになってきたら移行すればいい。
そもそも未だにWPFに移行できていないようなスキルの会社が
WInUIのxaml手書き開発に耐えられるのか？
デザイナがないから（こういうところもβ版たる所以）いちいちビルド・実行して画面を確認したり、
xamlの状態で画面イメージがつかめるよう可読性の高いxamlを書くよう注意する必要がある。 WPF程度でスキルがどうとか笑わせるな
レベルが低すぎるんだよ WPFもやってない状態から今WinUI使おうとすると結構大変だと思う 俺がそう
実行してみないとデザイン確認できないのも不便だし、何かやり方調べるときWPFとUWPの情報が混在してて結構混乱する
似てるけどちょこちょこ変わってるとこあるから >>876
2022年にもなってそのWPF程度にすら移行できていないのがヤバいんだよ WinUI３のデザイナだが、UWPで概ね画面だけ開発したあとにxamlをWinUI3プロジェクトにコピペでなんとかなると思う
違うことは違うんだが、ライブラリのネームスペースが異なる以外は大体同じです Blazorとかもう誰も使ってないでしょ
Svelte等JSフレームワークが進化しすぎた >>875
スキルセットは大丈夫
内製ツールとかはWPFとかweb化が進んでる
UWP班もあったけど消えた
パッケージがでかすぎて手を出せずにいるんだわ 今更xamlを使うよりもWebview2でよくね？ 今はWebView2とAngularで作るのが最強だね >>885
そういうのって何処かにテンプレートある？ >>886
今の最新バージョンのVSは完全に人柱用または内製開発で気軽に自己責任でシステム弄れるような組織向けであって、使う奴もそれを承知で使ってるんだから何の問題もないでしょ
2010以前のVSではそもそもリリースされていなかった開発中のものを、無いよりマシということで先行リリースしているのが今のVSの最新版 >>886
もうWinフォーム使うなら.NET Framework使ってね、でいいのにね。
オワコンに開発リソース使わないでほしい。 ついでにWinFormsをGenericsベースにして欲しい デスクトップはUIフレームワークが乱立していて、どれに舵切ればいいか判らんな
作れればまあ何でもいいんだが、短期間で廃止されたり、使われなさ過ぎて情報無いとかなるとつらい なんでわからないのかがわからない
答え出てるじゃん >>894
クロスプラットフォームはElectronがデファクトスタンダードになりつつある
WPFやWinUIは廃れる可能性が極めて高い >>890
でもWinFormsやUWPは更にオワコンだぞ
>>896
Electronは本格的なデスクトップアプリには力不足。
だから脱Electronの動きも一部ある。
WinUIは廃れる以前にまず普及するのか？って話がある。
UWPもさんざんテコ入れしてきてオワコン状態。
WinUIは色濃くUWP臭が残ってるからそれが普及の障壁になることを懸念している。 >>878
まったくだな。15年かけて移行できないんじゃWinUIへにも当然移行できない。
MSの黒歴史は続く。こりゃWinformがあと10年安泰だ。 >>899
Silverlightという超暗黒歴史から何の教訓も学ばなかったのは残念至極ですな
ユーザ体験としてはWPFもっさり＜＜WinFormsレスポンス速度 Electronはサイズでかすぎんよ
ちょこちょこっと気軽に作って配布したいのには全く向いてない ぶっちゃけ普段使いのアプリの数でも
Win32>>>Winform>>>WPF(VSだけ)
なんだよなぁ
WPFって委託下級会社のSEのオナニーでしかない まぁ WPF関係以外の話は他でやってくれという事だな。
MSDOSでもアーキが未来に残って、未だに現役かつ新アプリのベースになってている例も多いわけで、現場が何使おうが関係無い。
フレームワークはただのマクロ器。
ここはWinUI含むWPF関連のミクロテーマスレッドだ。 >>903
Nodeを知らんのだな…
デプロイの都度依存ライブラリのコピーを作るわけじゃないんだが >>907
Nodeを知ってるとサイズが小さくなるのか？ クライアント一回インストールするのに
サイズなんかどーーでもよいよ >>907こそNode使ったことないだろ
Nodeのパッケージはアプリケーション毎に全部ローカルディレクトリにインストールするのが普通であり、それこそが大きなメリットでもあるんだよ
.NETも最近はそうするのが一般的になってるね そーだよな
スマホじゃらねーーんなら
インストーラーサイズなんかどーーでもよくて
依存ライブラリを全部配布出来る方がいいだろ
WPFはそれ出来るようになったん？ インストーラ作るならWPFとか関係なくたいがいできるんじゃね Node.js のnpm/yarn は、Ruby のgem/bundler のコピー
各プロジェクト毎のlocal install と、
グローバルにインストールする機能がある
基本は、各プロジェクト毎
例えば、グローバルにインストールされているgem を、正規表現で検索すると、
2つのバージョンが見つかった
gem list "^rails$"
rails (6.1.4, 6.0.2.2) .NET Frameworkの方が息が長い可能性もあるな..
4系が消えるより先に今の.NETがさらに全く非互換なものに5年ほどで置き換わっても驚かんわー。 作るもの全部でかいハズがなくて
全体みわたせば95%が小さな小さなGUIツールやコマンドラインツールに過ぎないのに
c#はだんだんそういったものとの相性がわるくなってる。 .NET Framework出たての頃も
ランタイム入れなきゃいけないし
ランタイム入れたらOSの起動まで遅くなるし
起動が遅いし
VBよりも遅いし
でクソミソ言われてたな
WPFでさらに重く！プルスウルトラ！ >>899
まあ全アプリWPF移行に700人月かかりますとか言ったら経営陣ビビるわな そもそも今はWPF使える人間のほうが多い
WPFが採用率一番だし ネットや参考書のサンプルはWinformばかりだけどな >>921
生産性の高さやアプリケーションの品質。
WinFormsアプリの保守なんて地獄だぞ。 オレオレMVVMフレームワークの保守なんて地獄だぞ 有償コントロールなんか必要ない。
コントロールのカスタムが苦行だったWinフォームとは違うんだから。 >>926
開発体験なんて客にとってはクソどうでもいい なるべく安くというならExtended WPF Toolkitもあるじゃないの
いきなり全部いじらなくても大丈夫、必要なところからちょっとづつね？ つかC#のアプリ自体よく知らんな。有名どころだとなにがあるだろう >>936
Rust
Escape from Tarkov C#という広範囲なくくりだと今時のスマホゲームはどれもUnity3Dだな(DIコンテナのUnityではない)
PCだとRimWorldとか、カスタムメイド3D2とかコイカツ!とか 新規ならWPF一択、Winformsは検討しないね
主に保守のためWinformsを使わざる得ない場合に限られる その自己紹介ずーっとやってるけどなんか意味あんの？ >>947
ボウヤ、インターネッツは初めてかい？
同じ意見が同じ人ってわけじゃないんだぜ？ >>948
誰にもアンカーつけてないけどなんで自分のことだと思ったん？
答え合わせ完了やねw WPF一択って主張がまったく実感がないんだが
まあ、俺とは違う分野の人なんだと思うわ
ちなみにどんな分野で新規ならWPF一択なのか教えてくれ C# で .NET Framework のデスクトップアプリなら、じゃね？分野が限定されていると言われたらその通りだが。 デスクトップ前提ってそんなにあるかねえ
デスクトップとWebの選択って大抵のケースでは開発者のスキルの問題であって、
開発者が自分の都合のいいように勝手に「分野を限定」していることが多い
本質的な要件としてどっちかでなきゃいけないのは稀だと思うよ ローカルのハードウェアを動かすアプリはWebにするメリットが無いな >デスクトップとWebの選択って大抵のケースでは開発者のスキルの問題であって、
相変わらず、WPFスレでWeb持ち出す奴の認識はなんかおかしい。 デスクトップでどんなアプリ（システム）かって話なんだが
WinFormsだって用途のメインはデスクトップだろうよ デスクトップだったらWPF一択でFormの出番はないってことじゃね？ >もっと普及してるはず
毎度毎度それ言われるけど、客観的には上に挙げられた一連のリンクの通りだよね >>950
なんで>>948が他の誰かと同じだと思い込んじゃったの？
当事者じゃなくて客観的意見に見えるけど。
陰謀論とか信じちゃうタイプでしょ。 >>958
だって界隈は新しい技術を習得したがらないオジさんばかりだもん この争い一生終わらないしwinform とスレ分けたら？ WPFが普及してることにガクブルしながら耳を塞いでるのがWinFormsユーザーなんだよな あれこれリンクくれてるけど普及の証拠にはならないのでは
プロジェクトが多いっていうのも実験的なコードをアップロードしてるだけかもしれんし
意味不明なこと多くて質問が多いって言うのも普及とは違う
もっと具体的な普及している製品のリストアップが欲しいんだがそれは可能だろうか いつまでもこういう下の人間がいることに安心できるから教えなくていい WPFが普及してないって言う層が全然解らん。
10年ぐらい前からWPFしか書いてないぞ。 「WPFなんて全然普及してない。普及してるというなら証拠を出せ。」 書店に行ってもWPFを取り扱ってる本なんて皆無だろ、つまり需要が無い証拠 >>974
10年も末端プログラマーのまま進歩ないのか
お前の周囲時間止まってるだろ どっちにしろいまさらWPFを学習するとかありえんし
そもそもマイクロソフトのGUIやるなんて時間と労力のムダじゃね？ >>981
Windowsのアプリを組むのに、マイクロソフトのGUIを使わない方が時間と労力の無駄だと思うが >>978
医療関係のシステムを2社で全サブシステム、
その後は業務アプリ。
何本書いたのかな…数えてないわ。
>>979
実際には出世してるけどそれでも書いてるよw
レビューもしないといかんしね。 業務アプリとかちょっとした玩具つくるとか
そういう例はいっぱい出てくるけど
フォトショップとかオフィスとかブラウザとか
誰でも知ってる売り物のメジャーアプリには絶対に採用されないのは何でなん MACのVSってWPFじゃないよね？
なにでできてんだろ >>986
それらはWPFが登場するより前からあったし、
Windows以外のOS向けも作らなきゃいけないし、
C#じゃなくてC/C++で作ってるだろうし。
WPFのWって何かわかってる？ >>986
お前フォトショップとかオフィスとかブラウザがC#で作られてると思ってんの？
というか、あのネイティブな実装がWinFormsだと思ってんの？
嘘だろ、そこから？ >>986
マジレスすると重くて使い物にならんから
C/C++で不自由なくコード書けるならわざわざクソ重いCLR上で動くアプリなんて作る理由ないよね 特定企業向けの業務アプリと違って、>>986に挙がってるようなのはスケールメリットがあるから開発コストをそれほど気にしなくていいんだよ
UXの品質に対していくらでも金を注ぎ込める
WPFは最低限要件を満たせりゃいい開発にはオーバーキルだがコスト度外視で作り込むには弱いという、とても中途半端な立ち位置 >>993 そうかな？
最近WPF触り始めてまだ学習段階だけど、学習コストの高さと速度以外は割といい線行っている気がする
確かにMVVM周りとしてデータバインディングとかの情報が少なすぎて初学者にはちょっときついけど
でもWin32 APIとWinFormsそれぞれで組める人ならMVVMとXAMLの書き方さえ乗り越えたら割と楽に思える WinFormだとエディタのプロパティ一覧で大抵揃ってるけど
XAMLのは役に立たないからなぁ xamarinならともかくいまはflutter,reactnative,electronがあるからな
wpfがほかのプラットフォームでも動くならいいけど MVVMを乗り越えられない、学習コストを払えないところが多いからWinFormがまだ生き残ってる。 WPFだからMVVMで作らなきゃいけないと思い込んでいる人が結構いるよな。
これとか今でも使える良質の教材だと思うんだがな。
https://slidesplayer.net/slide/11235164/ >>999
これ書いた本人はとっくにWebに移って、Windowsすら使ってないというのがもう このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 123日 18時間 14分 24秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
