WPF(.NET, WinUI) GUIプログラミング Part33

2024/08/20(火) 21:16:46.38

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

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

前スレ
WPF(.NET, WinUI) GUIプログラミング Part32
https://mevius.5ch.net/test/read.cgi/tech/1694210576/

関連スレ
Windows 10 UWPアプリ開発Part 3
https://mevius.5ch.net/test/read.cgi/tech/1627556967/

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

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

2024/11/24(日) 10:04:49.03

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

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

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

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

2024/11/24(日) 11:15:56.24

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

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

2024/11/25(月) 11:51:01.20

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

2024/11/25(月) 11:53:43.97

OneDrive とか Dropbox とかも

2024/11/25(月) 12:50:11.92

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

2024/11/25(月) 13:10:09.67

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

2024/11/25(月) 22:39:22.95

なんかごめん

2024/12/05(木) 23:50:57.55

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

2024/12/25(水) 19:20:42.54

WinUI3の画面にWindowsTerminal埋め込んだったwww
https://qiita.com/C-Sharp_is_GOD/items/d02a2da67690342eb18f
https://youtu.be/EUKxCwRNE4g?si=THt6u0Izm1QRgl63
WindowsTerminal標準の設定も使えるしタブ機能も使える

2024/12/25(水) 20:22:33.08

君しつこいよ

2024/12/30(月) 19:04:40.52

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

2024/12/30(月) 20:05:33.26

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

2024/12/30(月) 20:21:17.17

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

2024/12/30(月) 21:03:02.41

ぜんぜん

2024/12/30(月) 21:32:22.79

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

2024/12/30(月) 22:04:44.38

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

2024/12/30(月) 22:26:17.62

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

2024/12/30(月) 22:38:07.94

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

2024/12/30(月) 23:01:18.81

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

2024/12/30(月) 23:18:27.36

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

2024/12/31(火) 00:42:34.02

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

2024/12/31(火) 00:44:36.08

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

2024/12/31(火) 10:06:10.65

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

2024/12/31(火) 10:12:02.23

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

2024/12/31(火) 10:19:11.69

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

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

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

2024/12/31(火) 10:31:04.49

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

2024/12/31(火) 10:39:29.91

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

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

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

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

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

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

2024/12/31(火) 10:42:43.55

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

2024/12/31(火) 10:44:23.87

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

2024/12/31(火) 10:49:14.60

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

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

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

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

2024/12/31(火) 10:53:31.07

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

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

2024/12/31(火) 10:57:19.21

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

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

2024/12/31(火) 11:01:21.58

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

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

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

2024/12/31(火) 11:04:24.31

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

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

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

2024/12/31(火) 11:07:24.97

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

2024/12/31(火) 11:17:53.96

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

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

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

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

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

2024/12/31(火) 11:22:43.40

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

教育って大事だな

2024/12/31(火) 11:26:21.09

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

2024/12/31(火) 11:27:25.06

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

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

2024/12/31(火) 11:32:40.90

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

2024/12/31(火) 11:32:50.05

君はわかりやすくて良い

2024/12/31(火) 14:52:49.56

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

2024/12/31(火) 17:00:27.19

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

2024/12/31(火) 18:39:03.11

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

2024/12/31(火) 20:00:33.49

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

2024/12/31(火) 22:07:55.17

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

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

2024/12/31(火) 23:18:09.38

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

2025/01/01(水) 15:48:34.59

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

2025/01/01(水) 15:54:30.70

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

2025/01/01(水) 23:40:44.91

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

2025/01/02(木) 18:25:22.13

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

2025/01/07(火) 00:36:52.79

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

2025/01/11(土) 23:04:19.08

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

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

2025/01/12(日) 13:42:32.40

>>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使えればなんでもいいかな

2025/01/14(火) 14:52:54.36

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

2025/01/14(火) 15:45:33.97

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

2025/01/15(水) 15:34:04.72

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

2025/01/15(水) 18:43:56.34

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

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

2025/01/15(水) 19:25:58.54

なんじゃそりゃ

2025/01/15(水) 21:30:16.76

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

2025/01/15(水) 21:34:09.40

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

2025/01/16(木) 17:15:23.31

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

2025/01/16(木) 17:22:20.40

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

2025/01/16(木) 17:51:47.75

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

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

2025/01/16(木) 18:18:59.08

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

2025/01/16(木) 18:34:38.58

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

2025/01/16(木) 18:35:56.72

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

2025/01/16(木) 19:27:49.37

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

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

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

2025/01/16(木) 20:25:24.48

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

2025/01/16(木) 20:41:31.65

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

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

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

2025/01/16(木) 20:52:24.00

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

2025/01/16(木) 22:25:36.62

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

2025/01/16(木) 22:35:10.45

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

2025/01/16(木) 22:37:23.51

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

2025/01/16(木) 22:58:43.09

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

2025/01/16(木) 23:48:51.43

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

2025/01/17(金) 02:03:42.02

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

2025/01/17(金) 02:05:09.48

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

2025/01/17(金) 02:44:40.96

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

2025/01/17(金) 08:06:24.51

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

2025/01/17(金) 11:45:29.01

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

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

2025/01/17(金) 12:53:04.28

スレで繰り返されるweb

2025/01/17(金) 13:22:01.00

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

2025/01/17(金) 13:25:07.45

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

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

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

2025/01/17(金) 13:28:05.39

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

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

2025/01/17(金) 13:46:39.82

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

2025/01/17(金) 15:45:46.58

令和のコボラー

2025/01/17(金) 15:54:14.26

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

2025/01/17(金) 21:38:14.28

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

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

2025/01/17(金) 22:53:47.34

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

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

2025/01/17(金) 23:25:27.76

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

2025/01/18(土) 00:53:27.87

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

2025/01/18(土) 01:10:13.97

Web苦手おじさん発狂中

2025/01/18(土) 03:05:36.05

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

2025/01/18(土) 06:43:10.38

>>452
どこ情報？

2025/01/18(土) 08:21:38.12

>>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/

2025/01/18(土) 11:43:33.23

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

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

2025/01/18(土) 11:45:44.49

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

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

2025/01/18(土) 12:12:08.09

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

2025/01/18(土) 12:52:58.93

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