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

**デフォルトの名無しさん** · 2022/10/29(土) 11:34:34.12

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

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

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

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

**デフォルトの名無しさん** · 2023/01/01(日) 13:31:24.51

でたよUIにロジックを組み込もうとするやつ
こういう関心の分離に従わないやつがゴミコードを書くんだよな>>660

**デフォルトの名無しさん** · 2023/01/01(日) 13:37:55.88

htmlやcssだってデザイナなくてもあれだけリッチな画面作れるのにデザイナなんかいらんだろ

**デフォルトの名無しさん** · 2023/01/01(日) 13:40:46.67

>>665
CSSはホットリロードで作ってくから
デザイナーいらんのよ

**デフォルトの名無しさん** · 2023/01/01(日) 13:42:58.51

XAMLをデザイナーなしでとか効率悪すぎ

**デフォルトの名無しさん** · 2023/01/01(日) 13:44:36.70

>>665
デザイナ業務の人たちはデザイナ使ってるよ

**デフォルトの名無しさん** · 2023/01/01(日) 13:46:57.06

デザイナ業務　→　デザイン業務
レスポンシブなどの概念が広まった後は商用でcss手打ちしてる人はほぼいないと思う

**デフォルトの名無しさん** · 2023/01/01(日) 13:50:01.48

>>664
分離してるからuiの表現に力使いたくないって言ってるのに

**デフォルトの名無しさん** · 2023/01/01(日) 13:53:03.67

一つ理解したのはこのスレの人たちは理解力が低く勝手に勘違いして攻撃しあってる

**デフォルトの名無しさん** · 2023/01/01(日) 14:13:21.74

草

**デフォルトの名無しさん** · 2023/01/01(日) 14:17:33.26

xml系が嫌なら宣言的ui使えるプラットフォームに移行すればいいだけでは？
考えの押し売りはキモい

**デフォルトの名無しさん** · 2023/01/01(日) 14:34:58.15

>>669
どのデザイナ使ってんの？具体的に教えてくれ

**デフォルトの名無しさん** · 2023/01/01(日) 14:37:29.49

そこで、猫だ。と言えれば格好いいんだろうなぁ

**デフォルトの名無しさん** · 2023/01/01(日) 15:20:22.34

>>671
はいはいすごいでちゅね～

**デフォルトの名無しさん** · 2023/01/01(日) 22:22:13.58

UWP/WinUI 2 アプリは、いつ WinUI 3 に移行すればよいですか?
UWP 開発者は、UWP とその機能セットに満足しているのであれば、アプリを Windows App SDK へ移行する必要はないはずです。

WPF は非推奨ですか?
いいえ。 WPF はまだサポートされていて、いくつかの機能アップデートを受けることもできます。

WinForms は非推奨ですか?
いいえ。 WinForms はまだサポートされていて、いくつかの機能アップデートを受けることもできます

Windows ランタイム (WinRT) は非推奨ですか?
いいえ。 WinRT とは、複数の言語間での相互運用を可能にするアプリケーションバイナリインターフェイス (ABI) を指します。
WinRT は COM の進化系です。
Windows App SDK は、その機能のほとんどを WinRT API を通じて提供します。

**デフォルトの名無しさん** · 2023/01/02(月) 09:35:36.77

＞　WinRT は COM の進化系です

**デフォルトの名無しさん** · 2023/01/02(月) 09:51:00.68

プレビュー自体はホットリロードでもいいけど、連動していたドキュメントアウトラインからのスタイルテンプレ取得の機能をなんとかして欲しい
今のところgeneral.xaml開いて拾ってくるしか無い

**デフォルトの名無しさん** · 2023/01/02(月) 13:39:08.45

お前らはやくMAUIに移行しろよ

**デフォルトの名無しさん** · 2023/01/02(月) 14:16:13.90

>>584
MAUIといいWinUIといいバグだらけ
時間の無駄

**デフォルトの名無しさん** · 2023/01/02(月) 20:23:38.94

貴方には人脈作りが足りないわ

**デフォルトの名無しさん** · 2023/01/02(月) 21:04:04.57

WPFを真っ当に発展させていけばいいものをUWPだのMAUIだのWinUIだの同じようで異なるものをポンポンと

**デフォルトの名無しさん** · 2023/01/02(月) 21:12:47.63

WPFアニメーションで質問
コントロールがぬる～っと動くアニメーションxamlで作ってて
DoubleAnimationコントロールのToプロパティにBindingすると
「スレッド間で使用するために、この Storyboard タイムラインツリーを固定することはできません。」
とかいう謎の実行時エラー出るんだけどxamlで完結出来る解決策教えて
要はToプロパティを動的に計算する手段が欲しい
コードビハインドは無しで

**デフォルトの名無しさん** · 2023/01/02(月) 21:21:23.14

>>683
しかもどいつもこいつもバグだらけで無意味に制約が増えるだけというw

**デフォルトの名無しさん** · 2023/01/03(火) 15:00:31.60

>>684
まずこういう初心者から脱しよう
>コードビハインドは無しで

**デフォルトの名無しさん** · 2023/01/03(火) 15:27:36.05

要は動きゃいいんだよ。コードビハインドでもなんでも。

**デフォルトの名無しさん** · 2023/01/03(火) 20:42:50.43

どうでもいいけどGridが内部のコントロールによってでかくなるのむかつくな
ツリービューにスクロール要素つけることが出来なかった。（Gridの高さを小さめに設定すれば行けるんだがAutoや*だと無理だった）

**デフォルトの名無しさん** · 2023/01/03(火) 21:54:45.82

>>686
解決策も示せない上級者(笑)には聞いてねえよ
そらコードビハインドで書きゃなんだって出来るわな
専用スレだってのに少しは建設的なレスできるやついないの？

**デフォルトの名無しさん** · 2023/01/04(水) 18:02:44.38

WPF で Data Binding と Command を使ったアプリケーションをシンプルに書きたかった話

**デフォルトの名無しさん** · 2023/01/04(水) 18:33:50.34

Bindingは遅い

**デフォルトの名無しさん** · 2023/01/04(水) 19:39:31.67

>>684
ビヘイビア

**デフォルトの名無しさん** · 2023/01/04(水) 19:54:43.54

コードビハインドでいいよな
周りに非コードビハインド(?)でできる人が
いればその人に聞く。
いないなら自分のやりたい手法で良い。

**デフォルトの名無しさん** · 2023/01/05(木) 00:20:37.46

コードビハインド=悪

やっぱり、この思想が世の中に蔓延ってるんだよな
WPF普及の足枷よ

**デフォルトの名無しさん** · 2023/01/05(木) 07:17:48.73

WPFの高DPI(Winformsでもできるが) 画面構築とコードビハインドでも
無問題。

**デフォルトの名無しさん** · 2023/01/07(土) 19:00:12.83

添付ビヘイビアを使うときの注意点ってありますか？
なんか検索するとイベントが残るとか、メモリリークの原因になるとか不穏な情報が出てきて…

**デフォルトの名無しさん** · 2023/01/07(土) 19:04:12.35

そうならないためにどこに注意しろというところまで書いてあるから読めや
なぜそれを読み飛ばしてここでまた聞いて読み飛ばすんだ
時間の無駄だろ

**デフォルトの名無しさん** · 2023/01/07(土) 21:26:26.92

つべこべ言わずさっさと教えろや
粗チンが

**デフォルトの名無しさん** · 2023/01/07(土) 22:19:27.33

コードビハインドが悪とかそもそも誰が言い出したんだっけ？
WPF初期から使ってるがMVVMはじめてみんなコードビハインドが悪だと信じ込まされて苦しんでたの草生えたわ
そもそもユーザー定義コントロール作ろうと思ったら継承必須だからコードビハインドせざるを得ないしConverterもBehaviorもおもっくそコードビハインドなのだが当時はMVP持ってる奴等が荒唐無稽な妄想で喚き散らしてて呆れたもんだわ

**デフォルトの名無しさん** · 2023/01/07(土) 22:23:24.11

xamlの中にC#書けばコードビハインドじゃなくなるのに
誰も推奨しないのは何故だ？

**デフォルトの名無しさん** · 2023/01/08(日) 02:43:01.75

>>699
MVP野郎たちだね
一方コントロールの内部実装では
バインディング全く使われて無かった

**デフォルトの名無しさん** · 2023/01/08(日) 11:23:34.32

コントロールはバインディング提供する側だろ

**デフォルトの名無しさん** · 2023/01/08(日) 14:13:40.53

結局フレームワークが新しいものに移り気だからぜんぜん成熟しないんだよね

バインディングサポート謳うなら
view作ったらviewmodelのテンプレート生成して
標準で提供しているコントロールぐらいどのプロパティもどのイベントのコマンドもお手軽バインドできるようにして
xamlにバインド記述したとき対応してない型なら自動でconverterコード生成するぐらいしてくれないと

**デフォルトの名無しさん** · 2023/01/08(日) 14:19:29.23

C#という言語としてはしっかり進化してるだけにもったいない

**デフォルトの名無しさん** · 2023/01/08(日) 14:35:32.75

マウイキチのせいで変なやつしか残ってねえ

**デフォルトの名無しさん** · 2023/01/08(日) 14:37:21.85

おちんぽ様があればなんでもいいや🥰

**デフォルトの名無しさん** · 2023/01/08(日) 14:48:32.64

xamlが別言語並に独特すぎて覚えるのクソダルいクセにまともに使えない機能多過ぎるのがマジで終わってる
>>700が言うようにC#スクリプトでも埋め込めりゃまだマシなのにそれすら無いせいで使う側が死ぬほど面倒なコード書かなきゃならん
コードビハインドだのViewModelだのビヘイビアだの依存関係プロパティだのカスタムコントロールだの
こんな面倒なコード量産しなきゃならん時点で流行るわけねーんだわ
使えば使うほどムカついてくる素晴らしいフレームワークだよ

**デフォルトの名無しさん** · 2023/01/08(日) 15:04:32.93

Windows向けのアプリ開発するならWinFormsが一番楽なのがな

**デフォルトの名無しさん** · 2023/01/08(日) 17:58:15.70

Winforms派だけどテキトーに作っても画面が最適化されるXAMLはいい。
縦モニタあるんだが最大化したら普通にうまく表示されたし。
逆に言うとこの辺しか利点がないと思った

**デフォルトの名無しさん** · 2023/01/08(日) 19:35:19.77

>>708
それな
しかもWinUI3.0は結局WinFormsだけでUWPを切り捨てて先祖返りしてるのマジでMSが行き当たりばったりで戦略性やビジョンが皆無なのが露呈してしまった
そもそもUWPはGlobal Hook使えなかったり.NETのサブシステムで機能が足りなかったりと欠陥すぎてあえなくMS Storeが死亡してそうだ！AndroidアプリをWSAで動かせばええんや！(ピコーン)とか斜め上の解決策なのも草
俺ならとりあえずXAML捨ててUIをWinFormsだけにするけどなもうHTML5+JS(TS)に慣れた開発者がXAMLに乗り換えてくれることはワンチャンすらねーよノーチャン

**デフォルトの名無しさん** · 2023/01/08(日) 21:06:53.22

この荒ぶっている彼はxamlをあまり解っていないようだね
最近使ったこと無いのがよく分かるよ

**デフォルトの名無しさん** · 2023/01/08(日) 21:47:08.89

お前より100億倍XAMLに詳しいよｗｗｗ
そしてお前がReactもVueも触ったことないのがよく分かるｗｗｗ

**デフォルトの名無しさん** · 2023/01/08(日) 21:51:15.67

実際のところどうなのかは知らないけど

>お前より100億倍XAMLに詳しいよｗｗｗ

こんなこと書いている奴はそれだけで頭悪そうに見えるよな

**デフォルトの名無しさん** · 2023/01/08(日) 22:09:38.16

5chでよくある光景だけど人のレッテル貼りしか出来ない奴よりは
言葉悪くても具体的な意見とか主張書ける奴のが有能だよ
それでもマウイくんはちょっとどうかと思うけど

**デフォルトの名無しさん** · 2023/01/09(月) 00:05:14.55

すみません。
Viewのイベントハンドラーをコマンドで呼び出したいのですがいい方法ありますでしょうか。

以下のTreeViewがあります。このツリービューのアイテムを選択した時に発火させるためのEventHandlerがItemInvokedなのですが普段のMVVMの通り{Binding 〇〇Command}とViewModelのコマンドを呼び出すことができません。
ViewModelのコマンドを呼び出すためにはどうすればよいでしょうか。
<TreeView x:Name="boardTree"
ItemsSource="{Binding BoardSource}"
SelectedItem="{Binding SelectBoardList}"
SelectionMode="Single"
ItemInvoked="boardTree_ItemInvoked">
<TreeView.ItemTemplate>
<DataTemplate x:DataType="model:BoardList">
<TreeViewItem ItemsSource="{x:Bind Children}"
Content="{x:Bind BoardTitle}"/>
</DataTemplate>
</TreeView.ItemTemplate>
</TreeView>

因みにItemInvoked="{Binding 〇〇Command}"としたところ以下のエラーが表示されました。
XLS0523 イベント ItemInvoked はデリゲート型 TypedEventHandler`2 のプロパティのみにバインドできます。

**デフォルトの名無しさん** · 2023/01/09(月) 00:43:59.11

>> 715
Biindできるのは
TypedEventHandler<TreeView, TreeViewItemInvokedEventArgs>型のみ
Commandインターフェースは持っていない

**デフォルトの名無しさん** · 2023/01/09(月) 00:57:04.65

Trigger使えよ常識だろ
このスレはド素人しかおらんのか？ｗｗｗ

**デフォルトの名無しさん** · 2023/01/09(月) 01:24:32.51

BoardListとか書いてるからこれ作ってる5chBrowserの事でMAUI君だろこれ
初めての実践とはいえひどいなww

**.NET MAUI HighSchool** · 2023/01/09(月) 02:46:28.31

>>718
酷いと言われてもまだ経験年数6ヶ月なのですが…

**.NET MAUI HighSchool** · 2023/01/09(月) 02:47:02.73

>>717
常識なのですね
MAUIではTrigger使ったことなかったので知りませんでした

**デフォルトの名無しさん** · 2023/01/09(月) 05:15:33.29

Triggerは古いんだってWinUIで切り捨てたのに
Xamarinからの流れでMAUIで復活したような形になっちゃってる
設計思想ェ…

**デフォルトの名無しさん** · 2023/01/09(月) 05:34:49.69

コテ隠して投稿したのに一瞬でバレてるのほんま草

**デフォルトの名無しさん** · 2023/01/09(月) 09:08:07.33

マジでまともにXAML書いたことないド素人しかおらんの草ｗｗｗ
俺は大企業で数多のカスタムコントロールを作ってきたからわかるが圧倒的にHTML5+CSS+JS or JSX or Vue or Svelteの方が優れてるからXAMLを採用し続ける限りMSの言語や開発環境が人気が出て盛り上がることは100%ない

**デフォルトの名無しさん** · 2023/01/09(月) 10:05:34.91

>>709
>Winforms派だけどテキトーに作っても画面が最適化されるXAMLはいい。
「画面(GUI)が勝手に最適化」はまず不可能だと思うけどね。
そもそも、Windowsアプリは最低、1024*768の解像度が有る環境が必須と
されていた。それより狭い画面だとまともに動かない。だから、スマホだと
無理が出る。XAMLで書いてもその制限は越えられない。
スマホのタッチパネル付きの狭い縦画面(?)には、それに配慮したGUIが
必要となる。XAMLなどで自動化しようとしても完全に自動化はまず不可能。

**デフォルトの名無しさん** · 2023/01/09(月) 11:13:58.50

709だが、

>>724
そりゃ全ての環境においてうまく最適化は
されないでしょう。
高い解像度もってると意外とうまく程度。

**デフォルトの名無しさん** · 2023/01/09(月) 11:18:17.95

スマホだと、ボタンが二つ以上横に並ぶようなインターフェースは無理が有るみたいだ。
ボタンは1つずつ縦に並べる必要があるらしい。
チェックボックスのようなものも同様。
しかも、デスクトップだと
項目名1[x]　項目名2 [x]
なのに対し、スマホだと、
項目名1
　　[o-]
項目名2
　　[o-]
みたいに項目とチェックの箱を二行に分けないと画面に入らないことがある。
こんなもんまでXAMLで共通化は難しいだろう。
もしかしたらできるかもしれないが、想像力と実機での確認が必要となるだろう。

**デフォルトの名無しさん** · 2023/01/09(月) 11:27:12.03

>>724
そんな制限はないしアダプティブにもできる。

**デフォルトの名無しさん** · 2023/01/09(月) 11:29:43.14

>>727
どのみち人間が考えないと駄目だろうて。
特に、デスクトップでは1画面内に出来るだけ多くの情報があった方が便利だったり
する。それが仕事の効率を高める。
ところが、スマホだと画面が小さいから不便であろうが「認識」できることが重要となる。

**デフォルトの名無しさん** · 2023/01/09(月) 11:37:36.93

なんというか、スマホだとある意味、項目を全て一個ずつ縦に並べるという
インターフェースにしか出来ないのに対し、デスクトップは作成者の判断で
何でも出来る。
一方は1通り、他方は無限種類(作者次第)。
そういうものはXAMLで共通化しにくいだろう。

**デフォルトの名無しさん** · 2023/01/09(月) 11:41:26.32

>>729
スマホの場合、画面上での並べ方は1通りでも、タップしたときにサブ項目を出したり
するようなことが必要になるかもしれない。
それはプログラミングで行なうことになると思う。
デスクトップだとそれは不要だから、プログラムもスマホとデスクトップで
場合分けが必要になるため、XAMLで共通化なんてできそうにない。

**デフォルトの名無しさん** · 2023/01/09(月) 11:43:56.57

Windows用のamazonのKindleアプリはなんか使いにくい。
それはマウスを前提にして無いからだと思う。特に右クリックやダブルクリックに。
AdobeのPDFリーダーも、どうも、Mac風に右クリック無しに設計されているように
思える。だから使いにくい。
結局、XAMLで共通化しようとしてもこのような不便さを乗り越えることは出来ない
だろう。

**デフォルトの名無しさん** · 2023/01/09(月) 14:26:00.62

>>719
その割にはえらいマウント取ってんじゃん

**デフォルトの名無しさん** · 2023/01/09(月) 14:32:56.60

>>726
WrapPanelに全部放り込めばいい
見栄えは悪いがウィンドウサイズに応じて勝手に折り返してくれる

**デフォルトの名無しさん** · 2023/01/09(月) 14:59:33.67

>>733
見栄えが悪い段階で競争力低下につながる。
中小企業は大企業に機能の量では勝負できないので、インターフェースの
良さで勝負するしかない。

**デフォルトの名無しさん** · 2023/01/09(月) 15:04:05.50

>>726
androidだと広いタブレットとスマホの2種類用意するけどなあ。

**デフォルトの名無しさん** · 2023/01/09(月) 15:08:47.01

スマホ・タブレット・デスクトップでUIを1本化しようとしたWin8はクレイジーだなw

**デフォルトの名無しさん** · 2023/01/09(月) 15:12:42.08

そもそも論として、マイクロソフトやGoogleが用意したフレームワークのXAML
で自動化できる範囲では、彼らのソフトを上回れないだろう。
彼らは大量の予算で大量の機能を盛り込んでいるから、そこでは勝負は出来ないわけで
せめてUIだけでは上回らないと。

**デフォルトの名無しさん** · 2023/01/09(月) 15:25:12.15

>>734
必要な機能の量なんて実務で違うだけで
小・大企業は無関係。

**デフォルトの名無しさん** · 2023/01/09(月) 16:32:43.44

>>738
そうでなくて、アプリを作る中小企業だとしたらの話。
アプリを作る大企業にアプリの機能の量で勝負は難しい。
受注生産なら関係無い。パッケージソフトの場合。絶滅危惧種かも知れないが。

**デフォルトの名無しさん** · 2023/01/09(月) 16:38:16.97

UIを使いやすくするのってむちゃくちゃ手間かかるよ
単純に機能の頭数を増やす方がよほど楽

**デフォルトの名無しさん** · 2023/01/09(月) 17:14:39.24

>>735
https://codezine.jp/article/detail/7658

**デフォルトの名無しさん** · 2023/01/09(月) 20:55:01.23

>>740
PhotoshopやBlenderみたいな機能は難しいぞ。

**デフォルトの名無しさん** · 2023/01/09(月) 21:32:38.63

UWPやWinUI3だと、AdaptiveTriggerってやつを使うとxamlだけで画面の広さに応じてレイアウト変更できるんだけどね

**デフォルトの名無しさん** · 2023/01/09(月) 21:46:08.04

なんかふわっとした中身無い話してる面倒臭いやついるけど
デザイン云々はろくに絵もかけないような素人が考えたって出来上がるのはダサいゴミだし
ユーザビリティもデザインの話であってフレームワークにはなんの関係も無いんだわ

**デフォルトの名無しさん** · 2023/01/09(月) 22:33:55.37

>>743
なるほどサンクス

**デフォルトの名無しさん** · 2023/01/10(火) 00:19:33.85

>>742
機能を実装できるだけの能力がある前提であれば、難しいのはPhotoshopやBlenderの基盤を設計、実装すること
その上に機能を実装していくのは大したことではない

**デフォルトの名無しさん** · 2023/01/10(火) 07:09:58.28

これまたスゴイ前提だなw

**デフォルトの名無しさん** · 2023/01/10(火) 07:21:14.00

>>744
これまたふわっとした話だなw

**デフォルトの名無しさん** · 2023/01/10(火) 08:53:27.69

.NETが頼りなさすぎてWindowsにしか使えない…

**デフォルトの名無しさん** · 2023/01/10(火) 08:59:42.68

サーバーサイドのcoreは？
docker(Linux)で使ってるけど

**デフォルトの名無しさん** · 2023/01/10(火) 09:21:33.49

MAUI頑張って欲しいんだが無理そうなん？

**デフォルトの名無しさん** · 2023/01/10(火) 09:39:09.65

帯に短したすきに長し

**デフォルトの名無しさん** · 2023/01/10(火) 10:37:26.87

>>751
最強

**デフォルトの名無しさん** · 2023/01/10(火) 10:50:02.95

次スレはWPFやめてMAUIに改名だな

**デフォルトの名無しさん** · 2023/01/10(火) 10:56:02.86

>>747
いやいや画像処理を実装する能力のない企業がフォトレタッチツール分野でPhotoshopと戦えるわけないだろw
UX以前の大前提よ

**デフォルトの名無しさん** · 2023/01/10(火) 12:56:02.79

>>744
マジコレ
ほとんどのプログラマは生まれつき視覚が劣化してるのか映像を理解する脳みそが劣っているのかわからんが
UIがゴミレベルで何もできない
お話にならないくらい酷い

**デフォルトの名無しさん** · 2023/01/10(火) 13:16:13.96

WinFormsのデートピッカーみたいに
マウスポチポチならいいけどキーボードだけで打ち込もうとすると終わってるとか
UIって難しいよね

**デフォルトの名無しさん** · 2023/01/10(火) 21:00:50.24

>>754
MAUI for desktopね。

**デフォルトの名無しさん** · 2023/01/10(火) 23:18:00.83

>>746
Photoshopには、
・人物の輪郭を自動的に選択する機能が有る。
・マウスで囲った部分の人物や物体だけを消す機能が有る。
　周囲の背景を上手く延長するような機能。
こういうものを実装するのは難しい。
単純な「画像処理」の範囲ではないと思う。　

**デフォルトの名無しさん** · 2023/01/10(火) 23:19:02.06

>>759
他にも、ウエストを細くしたり、おっぱいを大きくしたりするようなこともできるらしい。
こういうものも「画像処理」の範囲を逸脱しているはず。

**デフォルトの名無しさん** · 2023/01/10(火) 23:20:25.14

>>756
ただ、デザイナーがデザインしたUIは、見た目がいいだけで余り使い勝手が
よく無いかもしれないぞ。
PC-9801時代のプログラマーのUIは便利だったと思うし。

**デフォルトの名無しさん** · 2023/01/10(火) 23:45:36.07

>>759
そういう機能も持ったアプリめちゃたくさんあるぞ
色のコントラストがはっきり違えばどのアプリも似たような結果になる
逆に輪郭と背景の色差が小さいとどれも微妙な結果になるから手作業で修正が必要

差があるのは機能よりむしろUIの使い勝手

**デフォルトの名無しさん** · 2023/01/10(火) 23:59:40.27

>>761
「思う」「らしい」「はず」「かもしれない」
ここは無知な懐古ジジイの想像語るスレじゃねえよ
画像処理の話がしたいのかUIデザインの話がしたいのかUIプログラミングの話がしたいのか
前者二つならスレチだから他でやれ
そして二度と戻ってくんな