WPF(.NET4.x, .NET Core) GUIプログラミング Part24
■ このスレッドは過去ログ倉庫に格納されています
Windows Presentation Frameworkについて語るスレ。
前スレ
WPF(.NET4.x, .NET Core) GUIプログラミング Part23
https://mevius.5ch.net/test/read.cgi/tech/1557960752/
関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.net/test/read.cgi/tech/1499658092/
コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured 通知領域常駐アプリ整備士
「80パーセント？冗談じゃありません。現状でアプリの性能は100パーセント出せます」
シャア
「ウィンドウは付いていない」
通知領域常駐アプリ整備士
「あんなの飾りです。偉い人にはそれがわからんのですよ」 WPFもWindows 7 SP1 .NET Core 3.1(LTS)の最終環境に到達したな >>8
MSは、UWP から、Win32アプリの方に戻ってきていると書いている人がいた。 >>13
MSの取り巻きって内輪ノリが酷くてキモいんだよなあ
MS系スタックはなまじ一貫性があるから変な空気が醸成されやすい 結局、今 windowsのexeアプリを作る時、UIは何で作ればいいの？
wpfは機能追加全然ないし。プレースホルダー付きのテキストボックスすら無いし(追加されたらすまん) https://github.com/Microsoft/Xaml-Controls-Gallery
これとか落としてみたけど、相変わらずスマホで使って欲しいのかmenu itemやボタンとかのテキストにことごとくマージンついてるし
マウスで操作したいからマージン0でいいし、表示のアニメーションも全部いらん OSSが主流の時代になって各陣営はどれだけ優秀な貢献者を集められるかのがキモなんだが
windowsのGUI は全然人が集まらないので全然何も進まない
WPFはコントロールを提供するのがめんどくさいのでこれからも流行らない その他すべての陣営
react.js vue.js python PHP ruby RonR べつにWindowsデスクトップが特に好きなわけじゃないけどJavascriptは無茶苦茶嫌いなのでGUI全部がHTML5で動くような世界にはならないでほしい
MSはほどほどに頑張れ vue.jsとかのjavascript系フレームワークはwpfのMVVMの影響をかなり受けてるよ。 >>17
楽したいならWebでやりなはれ
工数いくらでもかけられるならWPFでもUWPでも、できないことはほぼない >>23
Javascriptそのものが嫌いなんだよ
MVVMであろうがなかろうがJavascript死んでも触りたくない 今だとUWPもWin32もWindows UI Libraryにまとめてく方針なのかねえ
まああれもﾁｶﾞｳｿｳｼﾞｬﾅｲ感凄いけど コントロールをWinUIにまとめてくれることはいいことじゃね？OSSにしてOSのアップデートと切り離して、更新とか頻繁にしてくれてるし。
少なくとも前よりマシじゃないかな。
>>17
Windows だけなら、.NET じゃないの？
web 系なら、HTML, CSS, JavaScript で、
VSCode は、Electron 製
Redmine は、Ruby on Rails >>29
いかにプロダクトの思想が正しかろうが、思いつきでUIフレームワークを量産して次々に見捨てていくことこそが最低最悪の害悪 Blazor流行ったらいいけどセキュリティ的にActiveXの二の舞になりそう >>32
昔、ネスケとMSが法廷で争ったとき、MSの懸念の1つはブラウザがOSの支配的地位を奪ってしまうことだったらしい。
ブラウザが有れば、どのOSでも同じ結果が得られてしまうため、どのOSを使っても差がなくなってしまう。
それはちょうど、WindowsOSをインストールしてしまえば、アプリ環境としては、PC-9801とPC/AT機の差がなくなってしまうので、オープン化で安くなったPC/AT
機が売れてしまったことと似ている。つまり：
・Win/Mac/Linux/iOS/Android と ブラウザの関係
・PC・AT/PC-9801 と Windows の関係
に対応関係がある。
何が言いたいかというと、Blazorが普及してしまえば、Windowsが必要なくなってしまうため、MSの安定収益が1つ無くなってしまう。
そうなれば、Googleは検索エンジンが安定収益になっているのと対照的だから、Googleに負けてしまうことになる。 >>33
一つ考え忘れていることがあった。それは：
Blazorアプリを動かすにはWindowsは必要ないが、Blazorアプリを開発するにはWindows(またはMac?)が必要だということ。
これがあるのでBlazorの発展はMSには問題にならないかもしれない。 >>34
ただ、Blazorアプリの開発がWindowsでしかできなくても一般人には全く関係ないが、プログラマの数と一般人の数は、1:50 位なので、Blazorアプリの普及はWindows離れを起こす可能性はある。 >>35
1:50 ではなく、1:300 くらいかもしれない。 >>34
WindowsとMacでほぼカバーできてるだろ
別にLinuxでも開発できるし BlazorをWebに乗りそこねたドットネッター達の救世主みたいに持ち上げてる人多いけど、
BlazorってReact系のプログラミングモデルでHTMLもCSSもバリバリ書くんやで
これ使える人なら普通にReactやVue使えるだろうし、単にそこに選択肢が一つ増えただけのことでしかないよ >>39
javaScript書かなきゃいけない量は格段に減るっしょ。それが何より。 >>40
君にとってはJSを書かないことが重要なんだろうね、それを否定する気はない
・HTMLやCSSはバリバリ書ける
・しかも出来合いのJS製のコンポーネントに頼らなくても余裕なハイスキルフロントエンダー
・しかしJSやTSは絶対書きたくない
・だがC#は得意
こんな君みたいな奴がどれだけいるだろうねw あとBlazorでJS書く量が減るのって、クライアントコードをC#に置き換えたからというよりは仮想DOM技術の恩恵が大きいと思うよ
Blazorが多くのドットネッターにとって革新的に感じるのは、
彼らが仮想DOM系フレームワークに始めて触れたのがBlazorだったからじゃないかな
SPAだから全部JSで書かなければならないとでも思ってるなら別だが >>41
javaScript絶対書きたくないとか誰も言ってないやろ Blazor に親でも殺されたんだろ
すでに拗れてるみたいだしスルーしといた方がいいよ 今のBlazorのプレゼンテーション層はRazorのままだから仕方がないが、Blazorに期待してる人は
WPFまで移植してくれることを夢見てるんだろう。
ClickOnceが使えなくなる前になんとかしてほしい、と俺も思う。 JavaScriptは絶対悪だからな
それを根絶できるという理由でBlazorに限らずWebAsm由来言語は期待されてる >>47
現状だと根絶はできないけどマシにはなるよねって感じ jsに触れた途端いろんなものが腐りだす
それを正そうとしたtsですらすでに腐れがとまらない WPFもjsも死にプロパティ多くない？
あ、これもあのクラスと同じプロパティあるじゃん
よし、じゃこうやってセットして・・・アレ？効かないよ？
？？？：ブブー、このクラスはそれじゃできませーん
↑作った奴、腹、切れ WPFのオリジナルの開発チームはとっくに全員クビにされてそう
WPFのCore移植でも作業してたのほとんど外注だったから、実際には外に丸投げしてたのかもしれないけど >>52
なんでだよ
htmlもそうだけど
存在するにも関わらず死にプロパティ多すぎだろ
せめて効かないやつ削除しろや 言語にそういう機能があればいいんじゃね？
って思うけどね この前まで6のドキュメント置いてあっただけだから
見出し書くていどのやる気は出たってことかなｗ メルヘンだね〜
WPF, Prismの情報が少ないのに本家までこれじゃぁハードル高いわ 複数のVisualBrushで重ね塗りする方法を教えてください VisualBrushの足し算みたいなことはできないということですかorz google playにあるUno platform製の電卓アプリUIが重すぎ。xamarinと同じで絶対流行らん そういう流行らんもんがいっぱい出てきて淘汰されて良いもんが出てくる
良いもんだけを出すことは不可能
だから糞が出てくること自体を否定する意味はない
業務でその糞を使えと言われないことを祈るのみ ためそうかとしてたがUno重いのか……
まぁいらってみるか みんないつかは、Brazorに行ってしまうん？ WPF捨てて WPFよりBlazorのほうが未来あるしそうなったほうがいい WPFとBlazorは排他的なものじゃないと思うが。Razorのことか？ Blazorは結局Webのスキルセットが必須だからWPFの比較対象にはならんだろう
この期に及んでクライアントアプリに固執してるような奴がBlazorのためにCSSの勉強とかすると思うか？
百歩譲って勉強するとしても、だったら普通にWebへ行くだろ >>73
Blazor for Native次第だね Blazorっていうかデスクトップアプリは捨ててWebアプリに移行するよ。 10年くらい前からそんなこと言われていてずっと環境が揃うのを待っているんだが、あと何年かかるのかね。 WPFは15年経っても流行らなかったがまだこれから来るとか抜かしてる奴がいるし
言い続けている限りは負けじゃないのさ(彼らの中では) Browser+RazorなのにBlazorっておかしくね？ Brazorと呼ぶべきなんじゃ？ >>78
Lの方がかっこいいやろーとか言ってなかったっけ？ >>73
C#案件が広がりを見せるという結果が期待されてるんでしょう C#で全部やりたいとかのニッチ向けに感じる
Webに移行するならコミュニティ、情報などの面からもクライアント側は素直にJS/TSでやった方がいいし
デスクトップGUIに価値を見出すならブラウザ上ってだけで欠点になる >>82
作れる。世界最大(?)のCADメーカー AutoCadがWasmを使ってWebアプリとして移植したとされている。
Wasmの例：
https://yutakaaoki.github.io/ >>83
毎度思うがもうちょいマシな見た目のサンプル紹介したれ photshopもあるし3Dもブラウザでできる
逆にブラウザでできない分野ってある？ >>86
実は、ローカルPCのファイルシステムに上手くアクセスすることがデフォルトでは出来ない。
ローカルPCにファイルを保存することは出来るのだが、ブラウザ(Chrome)の特殊な
データ領域に保存されてしまい、c:\ のディレクトリ内容を取得したりすることはブラウザを特殊なオプションで起動しない限りできないようになっている。
>>83 でdemo1などを起動してファイルメニューのOpenやSave As は少しトリッキーな特殊な方法でやっているが、自由自在にファイルを読み書きできるわけではない。 >>87
すまん、途中で書き込んでしまった
それは流石にautodeskに聞いてくれ >>90
「バックエンドが必要である」ことは正しい情報？？ >>91
すまんがそれもautodeskに聞いてくれ
とりあえず単体では動かないみたいなので何ら名のバックエンドはあるはず
ライセンス認証だけかも知れんが >>92
もしかしたら、それとは意味がずれるかもしれないけど、少なくとも、データ保存のためには、クラウドというか、リモートのサーバーにデータを渡す必要があるかもしれない。それはWebアプリはローカルPCのファイルシステムには容易にデータを保存できないから。 >>88
DTMのようなリアルタイムかつ低レイテンシーが重要な分野は厳しいんじゃないかな ローカルPC に、Node.js, Ruby などのサーバーを立てれば、保存できる
VSCode は、Electron 製 = Node.js + Chrome。
Redmine は、Ruby on Rails 製 >>95
ElectronはNode.jsのモジュールとしてChromiumエンジンを組み込んでおり、決してHTTPサーバーを立てている訳ではない
あとRedmineみたいなゴミとVSCodeを一緒にするな cgiが使えるLocalServerを起動していれば、cgiの仕組みを使ってローカルファイルシステムに自由にアクセスできるようにはなる。
また、この仕組みを使えば、WebアプリからローカルOSのあらゆる機能が使えるようになる。 RubyやPython, node.jsなどはどれも cgi server として起動することも出来て、
さらに、cgiを書くスクリプト言語としても使える。
そしてほぼあらゆるプラットフォームで動作する。
だからそれらを利用すれば、理論上は1つのcgiスクリプトであらゆるプラットフォームでOS固有のファイルシステムにアクセスすることが出来る。
>>99
まあ、悪用すればそうなんだけども。 ■ このスレッドは過去ログ倉庫に格納されています
