「2D-RPG」の記事 - Crieit

2D RPG 制作ツールを作ろうぜ（＾～＾）？　＜その2＞

2023-07-17T02:38:05+09:00

📖 前回の記事： 2D RPG 制作ツールを作ろうぜ（＾～＾）？＜その1＞

📅 （2023-07-17 mon 海の日）ボタンのマウスホバーはだいたいでけた

「　👆　MAUI は　タップ仕様なんで　マウスに対応してない。これでも　ちょっとは　マシにした方」

「　今日は　ここまでだな」

「　せっかく　２つ目の記事に来たのに……」

（Zzz　Zzz　Zzz　Zzz）

ズームしろだぜ

「　起きた」

「　枠線が太くて　タイルがよく見えない。タイルをでかく表示してくれだぜ」

「　ズームか。
係数を　ちゃんと正しく書けば　いけるはず……」

「　👇　行列演算するんじゃないか？」

📖 SkiaSharp + Zoom

「　キャンバスがやってくれるのか、画像がやってくれるのか分からん」

「　キャンバスの　横幅と　縦幅を変えるだけで　ズームしてくれるんじゃないの？」

「　あっ！　そういうことか！」

（カタ　カタ　カタ　カタ）

「　グリッドは　画像として実装しているので、ズームされると　ばかでかい画像になるんだが」

「　グリッドは　画像に対して　かけるのではなく、
画面に　かければいいんじゃないの？」

「　そうか！」

「　画面のスクロールと連携とれるかな？」

グリッドの実装を考えようぜ？

「　グリッドは　元画像のサイズとは関係なく　画像サイズも指定することにしたい」

「　グリッドの線には太さがあって　元の画像から　1px　はみ出るけど、
1024 x 1024 pixels の画像にかけるグリッドが　1026 x 1026 pixels なの、気持ち悪くない？」

「　ゲームの実行時に合わせて最適化すると、開発環境は　割り食うが、
ゲームの実行環境より、開発環境の方が　大幅にマシン性能が良いということを期待して、
開発環境は　割り食うことにしようぜ？」

「　👆　まず、 グリッド全体　と呼んでいたものを、 グリッド位相　に改名する」

「　上側のメニュー、 画像 の１行じゃなくて、
元画像 と ビュー の２段にしないと　のちのち　混乱するんじゃない？」

「　👆　利用者としては　不要な情報だが、
これがないと　開発中の　わたしが混乱するから　付けておこう」

「　Width と Height を変えて画像がデカくなるの　元画像を引き延ばすだけなら　そうかもしれないが、
いろいろ　加工したいので　ズームは自力実装することにするぜ」

「　👆　数字を　ちょこちょこ変更できる入力欄に　すぐ反応するように　ズーム機能を実装するの　大変だな。
要らん処理しないようにすることが」

📅 （2023-07-18 tue）健康診断のため休み

「　寝不足で　電車移動と　炎天下の徒歩で　きつい」

「　せっかくの年休なのに　お父んが　ヘロヘロだ。
寝てるぐらいなら　風呂掃除でもしてくれだぜ」

「　ユニットバスの床だけ　洗い流した。
全部きっちりやろうとすると　つらいので　これで終わり」

グリッドの画像サイズ

「　👆　グリッドがなんか切れてない？」

「　グリッドも画像だからな。ズームをしたときに
グリッドの画像サイズも変えてないので　切れてるんだぜ」

「　分かってるんだったら　直せだぜ」

「　画面上に　グリッドの画像サイズを出そうかな。わたしがデバッグするために」

「　グリッドは　なんかトリック・コード書いていて　やりづらいな……」

「　トリック無しで　グリッドを再描画できないの？
Invalidate() メソッドとか使えば　再描画できないの？」

「　なんらかのプロパティが変わってないと　再描画しないようだぜ」

「　👆　ズームに実数を入れると、ずれてしまうな。
計算式の端数の丸め方が　揃っていないのだろう」

「　for文で　横幅ずつ　横に移動しているところが　int 型なの、これが怪しいな　double 型へ変更しよう」

「　SkiaSharp のメソッドが float 型を受け取るようだから、 double 型ではなく、 float 型にしよ」

「　👆　グリッドは　ズームに対応したぜ」

「　カーソルが　ずれてるぜ。直せだぜ」

「　👆　テキストボックスの　小数点の桁数を何桁表示するかのフォーマットって　設定できないかだぜ？」

「　👇　そんなものは無いかもしれないな」

📖 Microsoft　＞　入力

「　じゃあ　表示用に整形したプロパティを別途用意するかだぜ」

「　👇　書式指定子　わかんね」

📖 Microsoft　＞　Standard numeric format strings

「　👆　"F1" にすれば　小数点以下１桁　になるみたいだぜ」

「　👆　カーソルや、カラー・マップを　ズームに対応させるの　まだまだ　かかりそう。
今日はもう寝る」

📅 （2023-07-19 wed）野球のオールスター観てた

休み

📅 （2023-07-20 thu）野球のオールスター観てた

休み

📅 （2023-07-21 fri）カラーマップもズームに対応しろだぜ

「　作業用ＢＧＭなんか　ないかな？」

「　👇　植松伸夫の　バトル１　を永遠に聞き続けなさい」

📖　バトル1

「　ＲＰＧだ！」

「　原曲じゃないか……　アレンジがいいのに……」

「　👆　この List RecordList というのが　タイル１個分のデータだが、
ズーム後の表示サイズのようなものは　記録しないぜ」

「　そこで　例えば　List RecordViewModelList　のように
ズーム後の表示サイズも記録するように　拡張するのが　基本的な考え方だぜ」

「　👆　TileRecord　ってこういうモデルだが、これとは別に　TileRecordViewModel　というビューモデルを作ることにしよう」

「　👆　主な違いは、位置とサイズを、元データとズーム後の２つに分けて持つことだぜ」

「　👆　タイル設定ファイルも　ビューモデル　バージョンを作っておこうぜ」

「　👆　そして　ズーム欄の数値を変更したタイミングで、
カラー・マップの　色矩形の位置とサイズを　全部更新すればいいわけだぜ」

「　ズームの数値を変えたときに　起こることが
タイルセット画像の伸縮と、グリッドの伸縮と、
切抜きカーソルや、画面上のオブジェクトの位置とサイズの変更と、
やることが多いのよねえ」

「　👆　カラーマップを拡大したぜ」

「　お父ん、タイルセット画像を暗くしていたのが　効いてないぜ」

「　あれま　ほんとだぜ。なんでだろな　調べるか」

「　👆　ズームした時も　明度を下げるようにしたぜ」

入力もズームの縮尺に合わせろだぜ

「　お父ん、マウスカーソルが指している位置と、切抜きカーソルが出てくる位置がずれているぜ」

「　入力は　ズームかかってないからな。そこも実装しないといけないか～」

「　👆　入力も　ズームを考慮して　行えるようにしたぜ」

「　👆　ズームを変えても、切抜きカーソルが　置いてけぼりをくらってるぜ」

「　ズームの数字が変わったら、切抜きカーソルの矩形の位置とサイズも　再設定しないといけないな」

「　👆　カーソルも　ズームに置いてけぼりされないようにしたぜ」

インターセクションが無いようにしましょう

「　矩形が　重なりまくって　分けわかんないんだけど」

「　👆　つまり　こういう状態になることを　強制する方法か」

「　既存の登録タイルと重なっているときは　タイルを追加できないようにすればいいのでは？」

「　既存のタイルと重なっている と、ユーザーにどうやって　気づかせるんだぜ？」

「　とりあえず　追加ボタンが押せなければいいんじゃないの？」

「　じゃあ　切抜きカーソルの位置を決めるために　マウスを動かしている間、
インターセクション（Intersection；重なり合った領域）があるかどうか　判定すればいいんだぜ」

「　👇　交差の判定方法を調べて」

📖 矩形同士の交差

「　👆　判定方法を実装」

「　👆　登録されているすべてのタイルと　比較すればいいわけだが、
リストではなく、 IEnumerator 型を使うのが　ひと工夫だぜ」

「　👆　このように　ストリームで渡せるようにしておくと、
ビューモデルも　同じアルゴリズムを使い回せるな」

「　👆　これで交差中か　判定できるようになったぜ」

「　👆　お父ん、コングルエンス（congruence ；合同）と　インターセクション（Intersection；交差）は　区別してくれだぜ」

「　考え出すと　お互いに部分的な交差、完全に覆っている交差、完全に覆われている交差、いろいろあるな。
インターセクションから　コングルエンスを除外するか、それとも　インターセクションでありコングルエンスでもあることがあるか？」

「　インターセクションを見つけることと、コングルエンスを見つけることは　時間が異なるんじゃない？
同じアルゴリズムで一緒にやろうとしたら　実行時間が最悪のケースにならない？」

「　じゃあメソッドを分けるか」

「　👆　合同のときは　上書きできるように直したが、
今度は削除ボタンが効かなくなった。調べるぜ」

「　論理削除されているものを　保存から除外してたから　保存されなかったんだ。
論理削除されているものも　保存するように直そう」

「　それでも直らん」

ファイルの内容をチェックするプログラムを入れておくべきでは？

「　👆　データの中に　合同の矩形が２つある！
片方を論理削除しても、もう片方が残ってる！」

「　ファイルの内容をチェックするプログラムを入れておくべきでは？」

「　👆　とりあえず　デバッグモードで確認するようにした」

「　👆　あれっ！　Ｉｄが重複しまくってる！」

「　Ｉｄの採番部を見直せだぜ」

「　👆　Ｉｄの採番部を直したぜ」

Disable のボタンのスタイル直せないの？

「　不活性のボタンは　文字が黒い青いボタンになってるけど、
グレーのボタンにできないの？」

「　スタイル　いつの間にか　おかしくなった　調べるか」

「　👆　ここに指定している通りに　表示してくれたらいいのに……」

「　その上で　BackgroundColor　を指定しているのが　ダメなんだろうかだぜ？」

「　👆　Normal も設定したら　直った」

グリッドの色を白にしない？

「　グリッドの色が赤なの主張が強いから　白にしない？」

「　👆　カラーマップの色と　衝突してしまうぜ？」

「　タイルセット画像と同じだけ　明度を落とした白にすんのよ」

「　👆　落ち着いた　目に優しい色になったぜ」

カラーマップの枠の色の青紫の明度を上げれないか？

「　青紫の明度が低いなあ」

「　SkiaSharp には　ＲＧＢじゃなくて　色相と明度で指定する方法　無いの？」

「　👇　ＨＳＶか。有るかも知れないな。調べてみるか。有った」

📖 SKColor.FromHsv(Single, Single, Single, Byte) Method

「　👆　目に優しくないな……」

「　ビビッドか、ストロングなの　やめなさいよ」

「　👆　じゃあ　ライトで」

「　ここらへんで　決めましょう」

作業中の表示が邪魔じゃないか？

「　ここまで画面ができあがってくると、画面上に出ている 作業中 の表示は　もう要らないんじゃないか？」

「　コメントアウトの切替えで復活できるようには　しておきたいな」

「　👆　デバッグ用のものを　非表示にしたぜ」

「　ひとまず　この画面は完成としましょう」

タイルセット画像選択画面を作れだぜ

「　その画面に入る前に　本当は　タイルセット画像を選ぶ画面が要るだろ」

「　フォルダーや　ファイルの概念が分からない　ツクラー種族や、スマホ種族を　どうしてくれよう」

「　👆　このフォルダーに置け、と決めて置いたら　いいんじゃない？」

「　タイルセット画像というものが、ファイル名ぐらいでしか管理されてないことに
前時代的なものを感じるぜ」

「　Author で分けたくは　ある」

「　全ての .png 画像に、 .toml 設定ファイルを添えるかな？」

「　👆　これぐらいじゃ　全然足りないだろうけど」

「　画像フォルダーに　.toml　入ってたら　邪魔じゃない？」

「　ファイルの説明のファイルだから、ファイルの隣に有ってほしいんだぜ。
同じファイル・パスですぐ見つかる感じで」

ファイル名のリストを表示してみろだぜ

「　試しにファイル名のリストを表示してみろだぜ」

「　といっても　テーブル・ビューを使えばいいのか、
コレクション・ビューを使えばいいのか、　リスト・ビューを使えばいいのか、
さっぱり分からないが……」

「　👇　サンプルがあるそうだぜ」

📖 .NET MAUIのCollectionViewを試してみる
📖 DotNet　＞　maui-samples

「　👇　これを見てみるかだぜ」

📖 https://github.com/dotnet/maui-samples/tree/main/7.0/UserInterface/ControlGallery

「　👆　これが　コレクション・ビュー　らしいんだが、何がいいんだろなあ？」

「　👆　これが　リスト・ビュー　らしいんだが、何がいいんだろなあ？」

「　👆　これが　リフレッシュ・ビュー　らしいんだが、何がいいんだろなあ？」

「　👆　これが　スワイプ・ビュー　らしいんだが、何がいいんだろなあ？」

「　👆　これが　フォームが乗っているテーブル・ビュー　らしいんだが、何がいいんだろなあ？」

「　👆　これが　メニューになっているテーブル・ビュー　らしいんだが、クリックすると画面遷移するぜ」

「　どれが　いいんだろな？」

「　グーグルのイメージ検索結果みたいに　画像を並べるのがいいんじゃない？」

「　そういうのが　コレクション・ビュー　なのかな」

「　👆　じゃあ　コレクション・ビューの　ＸＡＭＬ　を見てみるか」

ItemsSource="{Binding Monkeys}"

「　👆　Monkeys　って何なの？」

「　ＭＶＶＭ　使ったサンプルなのかと思ったら　ＭＶＶＭ　使ってねー」

「　👆　ただの　Monkey　型のリストだぜ」

「　Monkey　型は、　Name,　Location,　Details,　ImageURL　のプロパティを持っているぜ」

作業用ＢＧＭをかけようぜ？

「　作業用ＢＧＭを掛けようぜ？
ＹｏｕＴｕｂｅ　に何かないかな？」

「　それは　作業用ＢＧＭじゃなくて　違法アップロード動画なのよ」

「　👇　この音楽データは　買ったことがあると思うぜ」

📺 Rockman Arrange Album - iwao

「　また　ＲＯＣＫＭＡＮ　だ。　お父んは　音楽の聞き分けは　ＲＯＣＫＭＡＮ　かそうでないか　ぐらいしか　耳が分からないんだ」

コレクション・ビューを調べようぜ？

「　👆　Monkey　クラスは　ただのモデルだぜ」

「　👆　じゃあ　　というのは　ただのグリッド・レイアウトだから
それ以外のところに　コレクション・ビュー　独自のものがあるはずよ」

ItemsLayout="VerticalGrid, 2"

「　👆　ここだけしか　独自のものが無いが……」

「　👇　ItemsLayout は　ここにまとまってあるぜ」

📖 CollectionView レイアウトの指定

「　コレクション・ビューの使い方は分かった。使ってみよう」

「　じゃあ　Monkey　クラスに当たるものを作ろう。
TilesetRecord　みたいな名前でいいかな」

「　👆　とりあえず　深く考えず　TilesetRecord　を作った」

「　👆　リストも　仮の内容で　作っておこうぜ」

「　internal プロパティは　ＸＡＭＬから見えないのか。 public プロパティに変えよ」

「　モデルのプロパティに　public　を強要するのは　おかしい。
本来は　ビューモデル　にするべきでは？」

「　ＭＶＶＭのサンプルじゃないしなあ。
ＭＶＶＵでやるなら　ビューモデルかな」

「　👆　こういう見た目になった。　サムネイル画像が無いと　寂しい」

「　サムネイル画像を生成するプログラムを　先に書いたらいいんじゃない？」

テンポラリー・フォルダーをどこにするかだぜ？

「　👆　ユニティ・プロジェクトに　一時ファイルを入れたくないんで、
ローカルＰＣのフォルダーに　著者名、作品名で　フォルダー切った方がいいかだぜ？」

「　Windows べったりな発想だな。MAUI に　テンポラリー・フォルダーの概念　無いのかだぜ？
👇　調べろだぜ」

📖 How can I save temporary file in .NET MAUI?
📖 File system helpers

「　MAUI の流儀では　テンポラリー（Temporary；一時的な）と呼ばず　キャッシュ（Cache；隠し場）って呼ぶんだな」

（カタ　カタ　カタ　カタ）

「　👇　C# で Windows のファイル・エクスプローラーを開く方法も調べとこう」

📖 How can I open a folder in Windows Explorer?

「　👆　キャッシュ・ディレクトリーを開こうとしたら　アクセスを拒否されたぜ」

（カタ　カタ　カタ　カタ）

「　あれっ？　隠しフォルダーではないフォルダーからも　アクセスを拒否されたぜ」

「　MAUI でファイル・エクスプローラーを開けることが　イレギュラーなんじゃないか？」

「　👆　とりあえず　キャッシュ・ディレクトリーの場所だけ示すことにした」

「　キャッシュ・ディレクトリーの下は　どのように使うかといった流儀は　あるのかだぜ？」

「　MAUI より、 UWP を調べた方がいいんじゃない？」

「　分からん。　とりあえず　勝手に使って、文句出たら　変えよう」

「　👆　１７０文字ぐらいあるが、だいたい　２５５文字しか入らないのに大丈夫か？」

「　まあ　とりあえず　それで」

📅 （2023-07-24 mon）フォルダーなの？　ディレクトリーなの？

「　フォルダーなの？　ディレクトリーなの？」

「　どっちでもいい」

「　お父んのソースコードでは　ディレクトリ　という単語は０件で、　フォルダ　で統一されているぜ。
しかし　C# の入出力ライブラリーのプロパティ名は　Folder　ではなく　Directory　だぜ」

「　プログラマーは　この表記ゆれを気にしないの？」

「　ファイルで連想する対になるものは　フォルダーだぜ。
ディレクトリーは　歴史的な名称だぜ」

「　じゃあ　ネギラーメンは　フォルダーで統一するかだぜ」

Tileset フォルダーなの？ Tilesets フォルダーなの？

「　Tileset フォルダーなの？ Tilesets フォルダーなの？」

「　タイルセットが　いくつか入っていることを期待するから　Tilesets　でフォルダーだぜ。
うおお。　名前の付け直しだ」

タイルセットのサムネイル画像の仕様を決めようぜ？

「　そもそも　タイルセット画像って　小さいんだよな」

「　そのまま　並べりゃどうなの？」

「　とりあえず、タイルセット画像を、そのまま複製して　キャッシュ・フォルダーの下に置くプログラムを考えてみようぜ？」

「　👆　前に似たプログラムを書いたので参考にしよう」

「　👆　ファイルのコピーは　できたが、
サイズを調整したいぜ。 MAUI ではできないから、 SkiaSharp でやるかな」

「　👇　SkiaSharp で作ったビットマップを保存する方法が分からん」

📖 Using SkiaSharp, how to save a SKBitmap ?

「　👆　画像サイズの変更もでけた」

ファイル名は UUID にするか？

「　インターネット上の　すべてのタイルセット画像のファイル名が　被らないようにする対策は　してんの？」

「　ガチでやるなら　ファイル名は　UUID　にするか」

"adventure_field" ----> "86A25699-E391-4D61-85A5-356BA8049881"
"map-tileset-format-8x19.png" ----> "E7911DAD-15AC-44F4-A95D-74AB940A19FB"

「　👆　こういう名称変更をするぜ」

「　名前って　何だったんだろな？」

「　ローカルで通じればいいのが　名前よ」

「　👆　UUID と　タイトルだけあれば　いいのでは？」

「　👆　タイル名も、　タイルタイトル　に名前を変えたろ」

「　👆　サムネイル画像を出すところまでは　できたぜ」

「　やったな！」

「　やったわね！」

📅 （2023-07-25 tue）UUIDを勝手に付けてくれだぜ

「　UUID って、どうやって生成するんだぜ？」

「　勝手にファイル名を　UUID　に置き換えてほしいよな」

「　👇　C# は GUID という名前になってて、UUID とは別物らしいわよ？」

📖 How can I generate UUID in C#

String UUID = Guid.NewGuid().ToString();

「　👆　これで作れるらしい。試してみようぜ」

be6c25e9-2bca-40ba-84b4-b9f24bef6df3

「　👆　小文字かあ。大文字にしてやるかな」

95DE5BEE-A51E-41D1-B068-C6F436603AD4

「　👆　いいんじゃないか？」

「　📂 Tilesets フォルダーの下に 📄 {名前}.png 画像を放り込んでおけば、
名前が UUID じゃないとき　UUID にしてくれだぜ」

「　そんなことしていいのかな……」

「　対応する TOML ファイルも勝手に作ってくれたら便利じゃない？」

「　画像ファイルを　コピー貼り付けしたら、勝手に　UUID　振られる　地獄のフォルダーになるぜ？」

「　地獄のフォルダーなのよ」

「　ユーザーの知らない所で　元ファイルを変更すると　ユーザーのストレスになるケースもあるから、
タイルセット一覧画面　で　『ファイルを変更しますか？』　か何かのメッセージを出してもいいかもしらん」

「　👆　うそ画像を　水増しして　Tilesets　フォルダーに放り込もう」

「　ひどい……」

「　👆　こんな風に出てくるのか、嬉しくないな」

「　もっと　詰めて表示しなきゃ　サムネイル画像を小さくした意味がなくない？」

「　👆　ItemsLayout 属性を HorizontalList にすると　１段になってしまうんだな」

「　UUID が横に長い！」

「　ファイル名が画像に被ってない？」

「　UUID は３行に折り曲げたろかな？」

「　UUID なんか表示しなくてよくない？」

「　そういう考えもあるか」

「　👇　Collection View には　Flex Layout　が無いらしいぜ」

📖 [Enhancement] WrapLayout support in the CollectionView #1808

「　じゃあ　どうすんだぜ？」

📅 （2023-07-26 wed）妥協しようぜ？

「　MAUI のパターンから外れると　つらそうなので　妥協しようぜ？」

「　と思ったが HorizontalGrid, 2 が機能しない。なぜだかは分からない」

「　👆　VerticalGrid, 10 。　静止画だと　できているように見えるが、
ウィンドウを広げても　ずっと　１０列」

「　ウィンドウを広げるという概念は、 MAUI が大好きな Android アプリには無いのでは？」

「　MAUI は　デスクトップ・アプリ向けではないのよ」

「　じゃあ　どうすんだぜ？」

「　妥協しようと思ったが　その妥協ラインでもダメだった　手詰まりだぜ」

「　他のビューを調べろだぜ」

「　👆　リスト・ビューは　縦長で、なんか選べそうな色が付いてるな」

「　画面全体を使って　サムネイルを並べる　フラットなレイアウトは無いの？」

「　ＭＡＵＩには無いぜ」

「　CollectionView　の　VerticalGrid　というのは　縦長のスマホで何列にするか　という意味なのでは？」

「　それでも　HorizontalGrid　が機能しない理由が分からない」

「　縦でも　横でもなく　ウィンドウ・サイズの面積を　最大限に使ってほしいのよ」

「　ＭＡＵＩは　デスクトップ・アプリ向けではないんで」

コレクション・ビューで進めようぜ？

「　じゃあ　VerticalGrid, 4　で進めようぜ？」

「　👆　コレクション・ビューは　初期状態では　項目の選択はできないみたいだな」

「　👇　これを読めだぜ」

📖 Single selection

「　👆　こんなＵＩが良いとは思わないが　これで我慢するかだぜ」

「　画像が切れてるわよ？」

「　どうして　こんなに　欠陥だらけなのか……」

「　左上のタイルのサイズに　引きずられているのでは？」

「　そんなん困るぜ」

「　👆　固定サイズにするしかないか～」

「　ユーザーが　ウィンドウサイズを変更するたび、
列数を変えることはできないの？」

「　👆　コンテント・ページのサイズは取れるけど、
コレクション・ビューの ItemsLayout プロパティに Binding した文字列が効いてないぜ」

「　文字列ではないのでは？」

「　👆　GridItemsLayout　クラスを使ってみるが、効かないなあ」

「　👇　これを読みなさい」

📖 CollectionView does not update when changing ItemsLayout #7747
📖 [Windows] Update CollectionView changing ItemsLayout #14532

「　👇　これで　できたという報告なんだが、わたしには　理解できないなあ」

📖 [Windows] Update CollectionView changing ItemsLayout #14532
📖 AdaptiveCollectionView.xaml
📖 AdaptiveCollectionView.xaml.cs

「　そのサンプルを動かせないのかだぜ？」

「　クラス・ライブラリの出力タイプらしくて、動かないぜ」

「　👆　回転したり　半透明にしたりすることはできるのに、
１１列にするとか　８列にするとか、列数を変えることは　頑としてできない」

「　要らんことは　できるのに……」

「　👇　直ってるらしいんだが、直ってないぜ」

📖 CollectionView with GridItemsLayout: Issues when changing Span #8387
📖 [Windows] Notify changes in CollectionView Layouts #13137

MAUI のバージョンは？

「　MAUI のバージョンって　どうやってチェックできる？」

「　👆　これは　新しいのかだぜ？　古いのかだぜ？」

「　公式ページに何か書いてないかしら？」

「　👆　マイクロソフトは　直ったと言い張り、わたしの環境では　直っていないので　これは放置して次へ進むことにする」

📅 （2023-07-27 thu）ページを開くときに、ページの縦横幅を知ってることはできるの？

「　ページを開いたときに　ページの縦横幅を知ることができるなら、
ページを開いた直後なら　コレクション・ビューの列数を　調整することができるんじゃない？」

「　調べるか……。プログラマーの美徳の１つは　怠惰だしな」

「　怠惰のくせに　しつこく粘るな」

「　👆　ＸＡＭＬの中で　ビューモデルを埋め込んでいたが、
このビューモデルの中で　ItemsLayout　を初期化していて、その値を　そのあと一切　上書きできないというのが
今回の不具合だぜ」

「　ＸＡＭＬの中に　ビューモデルを埋め込むのを　止めろだぜ」

「　👆　InitializeComponent() の中で ItemsLayout の読込もしてるようなので、
それより前に ItemsLayout をセットしないとな」

「　👆　ページのコンストラクターでは、ページの横幅を取れないぜ？」

「　MAUI は　InitializeComponent( )　の中で　どうやって　ページの横幅を算出するの？」

[TilesetListPage.xaml.cs TilesetListPage] this.WidthRequest: -1, this.MaximumWidthRequest: ∞, this.MinimumWidthRequest: -1, this.Width: -1

「　👆　横幅は　持ってないみたいだなあ」

「　親ウィンドウのサイズは取れないのかだぜ？」

「　this.GetParentWindow()　はヌルだぜ」

「　このページに遷移してくる前に　横幅を渡せばいいんじゃない？」

「　画面の遷移は自動化されていて、
遷移前に値を渡す方法は　分からないぜ」

「　そして　ページのコンストラクターは　１回呼ばれると
画面遷移して戻ってきても　２回目のコンストラクターは呼び出されないぜ」

「　ページは破棄されてないんだ」

「　グローバル変数を使えばいいんじゃない？」

「　👆　NavigatingFrom　イベントハンドラで　メイン・ページの横幅を取れたぜ」

「　👆　これは挫折。　マイクロソフトの仕様の前に　失望し、意志を曲げ、諦めよう」

タイルセットをクリックして、この前作った　タイル切抜き画面へ　遷移してくれだぜ

「　じゃあ　タイルセットをクリックして、この前作った　タイル切抜き画面へ　遷移してくれだぜ」

「　クリックして　すぐ画面遷移すると　タイルセットのデータを見れないんで、
タイルセットを選んだあと　ボタンを押してから画面遷移するようにするぜ」

「　ファイル名を　UUID　に変えてもらいたいんだが、
ユーザーに　どう説明して
ファイル名を　UUID　に強制的に変えさすかな？」

「　『ファイル名をＵＵＩＤに変更する（言うことを聞け）』ボタンを置けだぜ」

UUID かどうかを判定

「　ＵＵＩＤになってるか、そうでないか　判定する方法が欲しいな」

「　👇　これを読みなさい」

📖 UUIDをヒットさせる正規表現

「　👆　とりあえず　画面レイアウトは　こんな感じだとしようぜ？」

タイルセット・タイトルは　ローカライズすんの？

「　タイルセット・タイトルは　ローカライズすんの？」

「　１つのタイルセットに　２００か国分の添付ファイルが付いてくるのとか　嫌だな……」

「　添付の TOML の中にロケールを詰め込んだらどうだぜ？」

「　１つのファイルに　複数のロケールが入っているのは
使わないものが必ず付いてくる　という　効率が最悪のケースになるかも知らん。
ロケールのフォルダーを作って　そこに .toml ファイルを置いた方がマシか……？」

「　丁寧にいくなら　それねえ」

📅 （2023-07-28 fri）タイルセットのロケールの仕組みを作れだぜ

　　C:\Users\むずでょ\Documents\Unity Projects
　　└── 📂 Negiramen Practice
　　　　└── 📂 Assets
　　　　　　└── 📂 Doujin Circle Negiramen
　　　　　　　　└── 📂 Negiramen Quest
　　　　　　　　　　└── 📂 Auto Generated
　　　　　　　　　　　　└── 📂 Images
　　　　　　　　　　　　　　└── 📂 Tilesets
　　　　　　　　　　　　　　　　├── 📄 86A25699-E391-4D61-85A5-356BA8049881.png
　　　　　　　　　　　　　　　　└── 📄 86A25699-E391-4D61-85A5-356BA8049881.toml

「　👆　今　こうなっているが……」

　　C:\Users\むずでょ\Documents\Unity Projects
　　└── 📂 Negiramen Practice
　　　　└── 📂 Assets
　　　　　　└── 📂 Doujin Circle Negiramen
　　　　　　　　└── 📂 Negiramen Quest
　　　　　　　　　　└── 📂 Auto Generated
　　　　　　　　　　　　└── 📂 Images
　　　　　　　　　　　　　　└── 📂 Tilesets
　　　　　　　　　　　　　　　　├── 📂 Locales
　　　　　　　　　　　　　　　　│ 　├── 📂 ja-JP
👉 　　　　　　　　　　　　　　│ 　│ 　├── 📄 86A25699-E391-4D61-85A5-356BA8049881.toml
　　　　　　　　　　　　　　　　│ 　└── 📂 en-US
👉 　　　　　　　　　　　　　　│ 　　　└── 📄 86A25699-E391-4D61-85A5-356BA8049881.toml
　　　　　　　　　　　　　　　　└── 📄 86A25699-E391-4D61-85A5-356BA8049881.png

「　👆　こうなる想定かだぜ？」

「　そうだな」

「　どの言語にも差が無い共通の設定は　ja-JP　に入れるの？」

「　デフォルトが　ja-JP　だからな」

「　en-US　で編集したら　ja-JP　に保存されるみたいなことがあるの？」

「　編集したのなら、すべての言語ファイルに更新を掛けないと　おかしくないか？」

「　英語版にあって　日本語版にないと　おかしな感じだしな」

　　C:\Users\むずでょ\Documents\Unity Projects
　　└── 📂 Negiramen Practice
　　　　└── 📂 Assets
　　　　　　└── 📂 Doujin Circle Negiramen
　　　　　　　　└── 📂 Negiramen Quest
　　　　　　　　　　└── 📂 Auto Generated
　　　　　　　　　　　　└── 📂 Images
　　　　　　　　　　　　　　└── 📂 Tilesets
　　　　　　　　　　　　　　　　├── 📂 Locales
　　　　　　　　　　　　　　　　│ 　├── 📂 ja-JP
　　　　　　　　　　　　　　　　│ 　│ 　├── 📄 86A25699-E391-4D61-85A5-356BA8049881.toml
　　　　　　　　　　　　　　　　│ 　└── 📂 en-US
　　　　　　　　　　　　　　　　│ 　　　└── 📄 86A25699-E391-4D61-85A5-356BA8049881.toml
　　　　　　　　　　　　　　　　├── 📄 86A25699-E391-4D61-85A5-356BA8049881.png
👉 　　　　　　　　　　　　　　└── 📄 86A25699-E391-4D61-85A5-356BA8049881.toml

「　👆　ベースとしての設定ファイルは、ロケールとは別に　要るのでは？」

「　Author　とか　どうすんだぜ？
Michael さんは　ja-JP ではミカエルさんになるのかだぜ？
ベースの設定ファイルには　どっちが入ってる？」

「　最後に見たロケールで上書きしたらどう？」

「　ja-JP から en-US に切り替えてから保存したら、
en-US の設定ファイルが　日本語で上書きされるのかだぜ？」

「　設定されていなければ　上書きしたらいいんじゃない？」

「　要らんデータで　上書きされたくないぜ」

「　全ての翻訳可能なプロパティは　個別にロケールを記憶しておけばどうだぜ？」

title = "冒険の荒野"
title_locale = "ja-JP"

author = "むずでょ"
author_locale = "ja-JP"

「　👆　こんな感じで」

[title]
value = "冒険の荒野"
locale = "ja-JP"

[author]
value = "むずでょ"
locale = "ja-JP"

「　👆　TOML なら　こうするかな」

「　画面を　英語で表示して、日本語入力したい人は　どうすんの？」

「　そんなことは　するなと　言いたい」

「　素直に　設定されてないロケールで見たら　空欄が楽かなあ？」

「　プレースホルダーに出すとかかな」

ベース：

[global]

uuid = "86A25699-E391-4D61-85A5-356BA8049881"
extension = ".png"
publish_date = 2023-06-26T00:00:00+09:00

[user_defined]

ロケールが ja-JP：

[local]

title = "冒険の荒野"
author = "むずでょ"

[user_defined]

# 自由に使える欄

ロケールが en-US：

[local]

title = "adventure field"
author = "Muzudho"

[user_defined]

# Please feel free to use here.

「　👆　こんな感じで　どうだぜ？」

「　試しにやってみないと　分かんないわねぇ」

「　UUID ではないファイル名は　どこにセットしたらいいんだぜ？」

「　じゃあ　fileStem　というフィールドも増やすかだぜ」

📅 （2023-07-29 sat）TOMLファイルを読めるようにしようぜ？

「　打ち込むか」

（カタ　カタ　カタ　カタ）

「　あっ、循環参照した。空間が成立してない」

「　サークル名と、作品名は　アプリケーションが始まる最初に入力しておかないと、
構成ファイルの場所を取得するために　構成ファイルを見る、という循環参照が起こるぜ」

「　トップ・ページは　構成ファイルを読まなくても　表示できるようにしておかないといけないのよ」

「　構成ファイルの場所　が先に在って、　構成ファイルそれ自体　は後に在るのか」

「　👆　今こんな感じだが、内部的に改修しよう」

「　あれっ？」

「　すると構成画面に入る前に　毎回、サークル名と　作品名を　入力する必要が出てくるぜ？」

「　ユーザー名と　パスワードみたいだな」

「　じゃあ　構成ファイルは　サークル名とパスワードのペアを　覚えておけばいいのよ」

[[entry]]
circle = "Doujin Circle Grayscale"
work = "Negiramen Quest"

[[entry]]
circle = "Apple Banana Cherry"
work = "Dragon Fruits"

[[entry]]
circle = "Shogi Club"
work = "Furi Bisha"

「　👆　こんな感じか」

「　現在の　configuration.toml　ファイルは、　Doujin Circle Grayscale/Negiramen Quest/project.toml　みたいな名前に変えるべきでは？」

「　じゃあ　まず　ログイン画面から作るか」

ログイン画面を作ろうぜ？

「　👆　こんな感じかだぜ？」

「　同じのを何度も入力したくは　ないんじゃない？」

「　👆　リストから選べるように工夫だぜ」

「　試しに作ってみてくれだぜ」

「　あっ！　だったら　Unity の Assets フォルダーの場所も　入力しておいてほしいぜ！」

「　今の構成ページを、ログイン・ページに変えたらいいんじゃない？」

メインページより先にログインページを出すには？

「　メインページより先にログインページを出すには　どうやったらいいんだぜ？」

「　👆　試しに　AppShell.xaml　を　いじったったらどうだぜ？」

「　👆　Ｏｋ！　これでいける！」

Workspace フォルダーの名前を変えたい

「　👆　この Workspace フォルダーへのパスを入力させるの、難しいな」

「　インストール時に勝手に設定してくれないの？」

「　ユーザーを想定して　開発者がパスの設定をするのは大変だから　ユーザーが設定してほしい」

「　このフォルダーの中で作業するのではなく、開始時にデプロイする初期ファイルが入ってるだけだから
フォルダーの名前も　Starter Kit　とかに変えたいぜ」

「　ログイン後は　２度と使わないんじゃないの？　このディレクトリー・パス」

「　Starter Kit　という名前にリネームしていくぜ」

（カタ　カタ　カタ　カタ）

「　じゃあ、　user_configuration.toml　というファイルは　現状、　configuration.toml　で置き場所を設定できるようにしていたが、
大変なので　Starter Kit　フォルダーの直下に置くように　固定していい？」

「　設定できることは少ない方が　ユーザー・サポートが楽になるぜ」

configuration.toml を改造したい

「　👆　今　こんな感じだが、　[profile]　テーブルを、　[[entry]]　テーブル配列に変えるぜ」

（カタ　カタ　カタ　カタ）

「　あっ、　次回　どの設定で　再開するか　覚えておく必要があるぜ！」

[remember]

# あたなのサークル名
your_circle_name = "Doujin Circle Negiramen"

# あなたの作品名
your_work_name = "Negiramen Quest"

「　👆　こんな感じのデータは　やっぱり要るか？」

「　変えたり　戻したり　だな」

「　エントリーは　ドロップ・ダウン・リストでいいかな。 50 件も 100 件もあるようなデータじゃないだろ」

やっぱりログイン画面は作ろうぜ？

「　👆　構成ページではなく、　別途　ログイン・ページが要ると思う。それも２ページ構成で」

「　変更じゃなくて　機能追加だったのね」

「　LoginPage1 にすると LoginPage1ViewModel になるのが　カッコ悪いから、
Login1Page にして Login1PageViewModel になるようにする」

「　👆　これを整形したり　動きを付けたりしないといけない　大変だ……」

『君たちはどう生きるか？』

「　観てきた～」

「　じゃあ　続きをしろだぜ」

ログイン画面の作成の続き

「　つら……」

📅 （2023-07-30 sun）ログイン画面　はよ作れだぜ

「　ログイン画面　はよ作れだぜ」

「　画面制作は　つらい」

（カタ　カタ　カタ　カタ）

「　👆👇　まず　レイアウトから。 MAUI はバグ放置があって　思ったように　レイアウトできない」

📖 Picker width on Windows not filling container #6391

「　大企業でも　進捗は　こんなものなのね」

「　👆　２ページ目のレイアウトは　こんな感じで」

文字数のカウント

「　動きを付けろだぜ」

「　👆　文字数のカウントは付けたが、すでに登録されているかどうかで
新規作成か　続きからかを分けるところ　作るの　めんどくさいな」

エントリー・リストを出す

「　１つ１つ解消していきなさい。まず　リストを出してみなさい」

「　👆　ItemDisplayBinding 属性に　リストの要素のメソッド名を入れれば　表示文字列になってくれるのか」

「　👆　サークル名と　作品名を　構成ファイルから取ってくるようにしたぜ」

リストから選んで、テキストボックスへ入れる

「　それを選んだたら　隣のテキストボックスへ入れろだぜ」

「　👆　隣のテキストボックスに入るようにしたぜ」

レイアウトを調整

「　文字数がサークル名を、　使える文字が作品名を指しているように　誤解を与えるんじゃない？」

「　レイアウトの設計は　本当に大変」

「　👆　翻訳時に　伸縮変わるんで」

続きから始めるボタン

「　入力したサークル名と　作品名が　既存のときは　次へボタンではなく、
続きから始めるボタンが出ろだぜ」

「　👆　続きから ボタンは　出るようにしたぜ」

次へボタン

「　次は　次へ　ボタンを作れだぜ」

「　👆　作ったぜ」

サークル名、作品名に使える文字

「　サークル名、作品名は　フォルダ―名に使うのに、
このままだと　長い名前を入力されるんじゃない？」

「　フォルダー名に使うサークル名　という日本語で２回　名　が出てくるのが煩わしいぜ」

「　じゃあ　サークル名　じゃなくて　サークル・フォルダー　だろ」

「　👆　フォルダー名を入れろ、という主張を強めたぜ」

「　推奨する使える文字じゃなくて、アスキー・コードで縛った方がいいんじゃないの？」

「　別に　うまく使ってくれりゃ　いいんだぜ」

「　あとで困る使い方を　自由にする人が　ほとんどなのに」

「　バリデーション・チェックは無しで」

テキストボックスへ、前回使った値を入れましょう

「　何度も　サークル・フォルダ名、作品フォルダ名を入力するのが　手間だから
前回使った値を　最初から入れておくようにしましょう」

「　👆　構成ファイルから　初期値を読み取るのは作ったぜ。
構成ファイルに保存する方は　まだだけど」

新規作成のケースを作ってくれだぜ

「　新規作成のケースを作ってくれだぜ」

「　ページの　Loaded　イベント・ハンドラーって　１回実行されたら　ページは破棄されていないのか、
２回来訪しても　呼び出されないんだな」

📅 （2023-07-31 mon）ログイン画面　はよ作れだぜ（２日目）

「　👆　ページを最初に読みこんだときと、ページに再び訪れたタイミングで
ピッカーの中身を入れ替えればいいんだぜ」

ピッカーの項目に削除ボタンを置けないの？

「　項目多くなったら　ウザいわよね。
リストの項目に　削除ボタンを付けれないの？」

「　その削除ボタンは、リストから項目を削除するボタンなのか、
それとも　プロジェクトを丸ごと消すボタンなのか？」

「　リスト上から消すボタンよ」

「　じゃあ　非表示の意味で　眼玉マークの方がいいのでは？」

「　一度　非表示にしたものは、どこから　再表示できるんだぜ？」

「　昔のＲＰＧの皮袋みたいに　要らない道具は　皮袋に詰め込めば
預かりもの屋に　テレポーテーションすればいいのよ」

「　その意図を　アイコン１つで説明するのは　難しいな……」

「　預かりもの屋も　作らないといけないしな。　いったん保留かな」

ConfigurationEntry を ProjectIdentifier へ名称変更

「　あのピッカーの項目は、構成のエントリーというより、プロジェクトの識別子だよな」

[[project]]

# あなたのサークル・フォルダ名
id.your_circle_folder_name = ""

# あなたの作品フォルダ名
id.your_work_folder_name = ""

# Unity の 📂 `Assets` フォルダ―へのパス
unity_assets_folder = ""

「　👆　意味を強調するなら　こうしたいところ」

「　構造的にネストしなくても、コメントで十分では？」

[[project]]

# （Ｉｄ）あなたのサークル・フォルダ名
your_circle_folder_name = ""

# （Ｉｄ）あなたの作品フォルダ名
your_work_folder_name = ""

# Unity の 📂 `Assets` フォルダ―へのパス
unity_assets_folder = ""

「　👆　じゃあ　こう」

「　unity_assets_folder は　プロジェクトの構成ファイルが　持つべきで、
ネギラーメンの構成ファイルが持っては　いけないのでは？」

「　それもそう。じゃあ　プロジェクト構成ファイルを作るか～」

remember を current に変えたい

「　変数の整合性を　きつくしたいので、
テキスト・ボックスに入れた値が　現在の設定だ、という風にするぜ」

📅 （2023-08-01 tue）まだログイン画面　できてないのかだぜ？（３日目）

「　まだログイン画面　できてないのかだぜ？」

「　もう　つらい」

「　👆　このリストは　構成ファイルに記憶するのではなく、
ディレクトリ階層を　探索するだけで良かったのでは？」

「　ディレクトリを探索できない権限のケースもあるから、
構成ファイルに記録するプログラムは　有るっちゃ有るぜ」

「　画面作りの何に時間がかかんの？」

「　作ってみたあとに気づく設計が成立してない矛盾と、
押されたくないボタンが押せてしまう状態の管理漏れ、
そしてバリデーション・チェックが通らなかったときの表示だぜ」

「　ほっとくと　都合の悪い入力を通してしまうしな」

「　👆　とりあえず　こんなもんで勘弁しろだぜ。
入力チェックは　パス」

「　入力欄は　縦に並んでいる方が　ふつうじゃない？」

「　もっともだぜ」

「　👆　これでどうだぜ？」

「　良くなったわね」

「　しかし、　あなたのサークル・フォルダ名って何だろな？　と、ユーザーは思わないかだぜ？」

「　思うぜ」

「　👆　あなたのサークル・フォルダ名のテキストボックスの右端に　×ボタンが付いているんだが、
わたしが付けたわけじゃないし、取り除く方法も分からないぜ」

「　仕方ない。ほっといて　次へ進めだぜ」

ログインページから始まるように、 MainPage をログインページにしようぜ？

「　ログインページから始まるように、 MainPage をログインページにしようぜ？」

「　なんで　最初のページの名前が　MainPage　なんだぜ　やめてくれだぜ」

「　まあ　プログラムは昔から　main　から始まるけど」

（カタ　カタ　カタ　カタ）

「　差替えたぜ。これで　ひとまず　ログイン・ページは終わりだぜ」

📅 （2023-08-02 wed）初回ログイン時にスターターキットをユニティのAssetsフォルダーへコピーするようにしよう

「　まだ終わってなかった」

「　サークル・フォルダ名、作品フォルダ名を作ったあとは、初回ログイン時に
スターターキットをユニティのAssetsフォルダーへコピーするようにしよう」

（カタ　カタ　カタ　カタ）

「　とりあえず　実装した。不具合があるかどうかは知らん」

タイルセット一覧画面にインポート・ボタンを付けようぜ？

「　タイルセット一覧画面にインポート・ボタンを付けようぜ？？」

「　ドラッグ＆ドロップの方がいいかも知れないが、
とりあえず　インポートボタンは要るかだぜ」

「　👆　インポート・ボタンは　こんなんでいいかだぜ？」

「　こんなでかいボタン、噴飯ものだが　MAUI　だから仕方ない。良いんじゃないか？」

「　👇　ファイル・ピッカーの説明が　何言ってるか分からないな」

📖 Microsoft　＞　ファイルピッカー

「　👇　サンプル・プログラムに　ファイル・ピッカーがないか　調べてみるか」

📖 jfversluis　＞　MauiFilePickerSample

📅 （2023-08-03 thu）疲れたので寝た

Zzz

📅 （2023-08-04 fri）インポート画面の練習をしよう

「　👆　前述のサンプルは　動くぜ」

「　👆　コードはこれを真似すれば　良さそうだぜ」

「　ファイル・ピッカーは　コントロールではなく、ただの関数なんだな」

ドラッグ＆ドロップ

「　ファイル・ピッカーに取り掛かる前に　コントロールの色々なことが分からないので　本番に組み込む前に　練習したいぜ」

「　👇　リポジトリ―を作っておいたぜ」

📖 Muzudho　＞　MAUI-Control-Practice

「　👇　画像ファイルを　ネギラーメンに　ドラッグ　アンド　ドロップ　できるかな？」

📖 Microsoft　＞　ドラッグアンドドロップジェスチャを認識する

「　👇　Square クラスなんか　どこにあるのか？」

📖 Microsoft　＞　Microsoft.Maui.Controls.Shapes Namespace

「　Rectangle で十分じゃないか？」

「　MAUI の Rectangle は、 XAML の Rectangle 要素なんだぜ」

「　👆　矩形を　ドラッグ＆ドロップ　しようとしたら　こんな見た目になるのか」

「　👆　ドラッグ・イベントの仕事は、　禁止マークとか　コピー・マークとか　表示するところにありそうだぜ」

「　👆　XAML は　こう書いて」

「　👆　コード・ビハインドは　こう書けば良さそうだぜ」

「　Windowsのファイル・エクスプローラー上の画像ファイルを　ＭＡＵＩへドラッグ＆ドロップできるの？」

「　👆　できそうな見た目をしているが、ドロップすると　強制終了するぜ」

「　👆　エラーの理由は　ヌルにできないパラメーターに　ヌルを入れたかららしいが、
分けわからん」

「　👇　MAUI にデスクトップ・アプリケーションの機能が無いのは　鉄板の話題らしい」

📖 Does MAUI support file drag and drop to other application (Windows, Linux, macOS)? #7508

「　じゃあ　MAUI　は　WPF　より先に廃止するかもしれないな」

「　ファイル・ピッカーで　しのぎましょう」

アラート

「　👆　うーん、ファイルのフル・パスは取れるのか。
この　ダイアログボックスみたいなの　現代では　アラートと呼ぶらしいが、
キャンセル・ボタンも出せるだろうか？」

「　👇　ポップアップはなぜ　XAML　じゃないのか……」

📖 ポップアップの表示

「　👆　いろいろ　あるっちゃ　あるのか」

「　👆　とりあえず　こんなんでいいか……」

ファイルのコピー

「　👆　ひとまず　上図のような　ファイル・コピーをやってみるかだぜ」

                    System.IO.File.Copy(
                        sourceFileName: result.FullPath,
                        destFileName: tilesetPngLocation.Path.AsStr);

「　👆　ファイルのコピーだけなら　これでいけるはず」

「　Windows の API 使ってるの、いいのか知らんけど」

「　👆　ファイルのコピーはでけたけど、コレクション・ビューにも追加しないと　画面に出てこないな」

「　コレクション・ビューに入れるのではなく、
アイテム・ソースに入れるんじゃないか？」

「　そうか」

「　👆　インポートで　画像を放り込んだった」

ファイルの削除

「　要らんもの　放り込まれたら　削除したいんだけど」

「　削除ボタンを　どこに置くかという　レイアウトも困るよな」

「　👆　左下に赤いボタンを置くというのは　どうだぜ？」

「　危ないから間違って押したくないボタンなのに、主張が激しくて　むしろ目が　そっちに行くんじゃない？」

「　頻繁に　マウスカーソルが近づくとこに　削除ボタンを置いては　いけないのでは？」

「　👆　右上に　ペール・バイオレット・レッド　のボタンを置くというのは　どうだぜ？」

「　ロケールのピッカーの真下なのが気になるけど、ちょっと　ずらしたら　どう？」

「　👆　おかしくないか？」

「　誤クリック防止よ」

ボタンのスタイル

「　あっ、この　ペール・バイオレット・レッド　のボタン、
不活性にしても　グレーにならねーっ！」

「　背景色を指定しているからな」

「　👆　このボタンのスタイル、　削除ボタンだけ　別のを使うようにできないのかだぜ？」

「　x:Name 属性を使って　なんとかならないかしらねえ？」

「　👇 x:Key というのが　あるそうだぜ」

📖 XAML を使用してアプリのスタイルを設定する

「　でけた」

キュー構造だから、任意の場所の要素を削除できねー

「　キュー構造だから、任意の場所の要素を削除できねー」

「　前から入れて、後ろから出すしか　できないぜ」

「　なんで　キューなんかにしたのよ？」

「　コンカレント処理に強ければ　なんでもいいと思ったんだぜ」

「　ConcurrentBag にしよかな」

「　👇　ConcurrentBag も要素を削除できないのか」

📖 How to remove a single, specific object from a ConcurrentBag?

「　非同期処理をしているときには　どんなコレクションが使えるんだぜ？」

「　👆　連続読込は　ConcurrentBag、　UI は同期のコレクションに変えた。
インポートと　タイルセット削除は　でけたぜ」

「　疲れたので　今日は　ここまで」

📅 （2023-08-05 sat）たいとる１

「　たいとる１ って何なの？」

「　タイルセットのタイトルを入れたいところだぜ」

「　入れなさいよ」

「　PNG画像があって、TOMLファイルが無いといったペアがあるとき、
TOMLファイルを自動生成する機能が要るぜ」

「　その機能を付けなさいよ」

「　タイミングとしては、インポート、タイルセット削除、ファイルのリネームの３か所だな」

（カタ　カタ　カタ　カタ）

「　👆　万国共通の構成ファイルの方は　自動生成するようにしたが、
画像のタイトルは　ロケール別の構成ファイルの方に入れる仕様だぜ」

「　ロケール別の構成ファイルも　早よ作れだぜ」

ロケール用のフォルダーを作ろうぜ？

cultureInfo:
    DisplayName: 日本語 (日本),
    EnglishName: Japanese (Japan),
    Name: ja-JP,
    NativeName: 日本語 (日本),
    IetfLanguageTag: ja-JP,
    TwoLetterISOLanguageName: ja,
    ToString(): ja-JP

cultureInfo:
    DisplayName: 英語 (アメリカ合衆国),
    EnglishName: English (United States),
    Name: en-US,
    NativeName: English (United States),
    IetfLanguageTag: en-US,
    TwoLetterISOLanguageName: en,
    ToString(): en-US

cultureInfo:
    DisplayName: 中国語 (簡体字),
    EnglishName: Chinese (Simplified),
    Name: zh-Hans,
    NativeName: 中文（简体）,
    IetfLanguageTag: zh-Hans,
    TwoLetterISOLanguageName: zh,
    ToString(): zh-Hans

「　👆　画面のピッカーには NativeName で表示した方がいいのかな……？」

「　👆　NativeName の方が　かっこいいな　こっちにしよ」

「　👆　ひとまず　ロケール用のフォルダーと、空のファイルを作成……」

コレクション・ビューの選択中の色

「　コレクション・ビューの選択中の色、グレーで見にくいな！」

「　スタイル　見たけど　さっぱり分からん。後回し。ダークモード消したった」

タイルセット削除ボタンの位置

「　👆　タイルセット削除ボタンの位置を　左下に戻したった」

プレースホルダ―のロケール設定を分けたいぜ

[global]

uuid = "6FBD83F1-D2A3-45EE-AFC5-411CD6E50144"
extension = ".toml"

[local_placeholder]

title = "適当に作った画像"
author = "むずでょ"

[user_defined]

「　👆　タイルセット・グローバル構成ファイルに　local_placeholder　という項目が欲しいぜ」

「　最初に思っていなかった　いろんなものを　盛り込むなあ」

「　英語で設定されていて、日本語で設定されていないとき、
英語の設定を　プレースホルダーで表示してくれてもいいじゃないか、というものだぜ」

「　第１言語、第２言語を選べるようにすりゃいいんじゃない？」

「　フーム、大改造は嫌なんで　後回しにするか」

タイルセットのタイトル

「　👆　まず　日本語で対応を進めていこう」

「　じゃあ　画面から　タイトルを変更できるようにしてくれだぜ」

エントリー（テキストボックス）で１文字入力するたびにビュー・モデルが更新されるのつらい

「　エントリー（テキストボックス）で１文字入力するたびにビュー・モデルが更新されるのつらい」

「　それが　MVVM　なんじゃない？」

「　👇　このサイトは　細かく書いてるが　知りたい情報はあるかな？」

📖 TextEditBase.Text Property

「　👇　Completed　というイベントハンドラがあるのでは？」

📖 Microsoft　＞　入力

「　それを使うように変えていくか～」

「　なんだこれ　エンター・キー　押さないと　Completed しないじゃないか。
エンター・キー押さなかったら　どうする？」

「　エントリーで　タブ・キー押したら　タブが入るし」

「　MAUI の不具合なんだから、エンター・キーを押せ という運用でやるしかなくない？」

画面を移動するボタンと、それ以外の機能があるボタン

「　画面の移動も、　データの編集も　同じボタンの形状なの　分かりづらいんだが」

「　そんなもんだろ」

「　画面遷移も　スライドするトランジションが入るやつと、
トランジションが無いやつもあるし」

        //
        await contentPage.Navigation.PushAsync(new ConfigurationPage());

        //
        var shellNavigationState = new ShellNavigationState("//MapExplorerPage");
        await Shell.Current.GoToAsync(shellNavigationState);

「　👆　やり方が２つあるのも　分けわかんないわねえ」

「　Navigation を使うやつは、戻るボタンが勝手に付くのでは？」

「　わざわざ　ShellNavigationState　を使うやり方って　メリット無いの？」

日本語と　英語で　別々にタイトルを付けれる機能

「　日本語と　英語で　別々にタイトルを付けれる機能の実装を進めるぜ」

「　👆　付けた」

アンドゥとリドゥ

「　そろそろ　アンドゥと　リドゥができないことに　突っ込まれそうだぜ」

「　Command Pattern を自力実装するのか、それとも　MAUI　に何か便利なフレームワークがあるのかだぜ？」

「　👇　他人が作ってくれてるけど、自力実装すりゃ　いーんじゃねーの？」

📖 C#でUndo/Redoを実装した

「　ＭＶＶＭは　アンドゥに従ってくれんの？」

「　全ての操作には、逆向きの操作も用意しておく必要があるな」

「　テキストボックスの文字を１つ消したのも戻せるレベルで　ヒストリーを作んの？」

「　エントリー（テキストボックス）には　アンドゥ・リドゥ機能がもう付いていたぜ」

「　じゃあ　MAUI　に元から付いている　アンドゥ・リドゥ機能と、
お父んが作る　アンドゥ・リドゥ機能は　ぶつからないか？」

「　そこらへん　どうすんだろな？」

「　いきなり　バイナリで作ると　バグ取りが難しいだろうから、
ヒストリーは　TOMLファイルで書き出すかな」

「　削除したリソースや、　上書きで加工してしまったリソースとか　出てくると思うが
復元する方法は？」

「　ネギラーメンは　リソースは編集しないぜ。
リソースを組み立てるだけだぜ」

「　インポートした素材は　削除も　上書きもされないという前提に立っているのね」

「　ネギラーメンから　素材を削除するときは、アンドゥもできません、ということにするんだぜ」

📅 （2023-08-06 sun）アンドゥ・リドゥ機能を作れだぜ

「　アンドゥ・リドゥ機能を作れだぜ」

「　👆　コンピューター将棋と同じだぜ。　全ての操作には、進むと　戻るが　あるんだぜ」

「　👆　履歴管理機能も　便利機能を付けなければ　芯は　これだけだぜ」

「　👆　イベントハンドラの内、自動ではなく、ユーザーの操作によって呼び出されるものが
ヒストリーの記録対象になるぜ」

「　じゃあ　試しに　ズームを　ヒストリカルにしなさいよ」

「　👆　ヒストリカルにしていないということは、
リドゥの方向のプログラムしか　書かれていないということだぜ」

「　画面の更新しか　書いてなくない？　ズームの数字が　いくつから　いくつへ変更したか書いてないわよ？」

「　コード・ビハインドだからな」

「　👆　ズームして何が起こるかは　ビュー・モデルの方に書いてある」

「　👆　ズームすると、画像を作り直したり、グリッドを作り直したり、
切抜きカーソルを描き直したり、カラーマップを描き直したり、
広範囲に影響があるようだぜ」

「　ズームの変更と、ズームの変更によって起こる事象を切り分けてくれだぜ」

「　👆　IDone インターフェースは　IProcessing　インターフェースに名称変更、
Redo　メソッドも　Do　に名称変更。そして実装」

「　👆　History クラスも Done メソッドを止め、 Do メソッドに変更、中で Processing クラスの Do メソッドを呼び出している」

「　あと、コードの書き方が下手で　無駄に再帰してるから　書き直したい」

「　👇　MAUI には　キーボード操作のイベントハンドラが無いじゃないか」

📖 .NET MAUIでのCtrl+Enterなどのキーイベントハンドリングの難しさ

「　スマホに　キーボードは付いていませんからね」

「　[Ctrl] + [Z]　の操作をカスタマイズできないのかだぜ、クソじゃないか」

「　MAUI は　意固地にも　画面上のボタンを押せ、ということかだぜ」

「　それが　クロスプラットフォームの真実　なのでしょう」

「　♪
真理は　避けられず
真実は　踏み込んだ者にしか知られず
真相は　勝手なものである」

「　お父んの前で　真実に触れるなだぜ」

アンドゥ・リドゥ　ボタンを置こうぜ？

「　アンドゥ・リドゥ　ボタンを置こうぜ？」

「　Unicode には　アンドゥ・リドゥに適した絵文字は無いようだぜ」

「　アンドゥ、 リドゥ と書かれたボタンが　画面上に置いてあるのも　邪魔ねえ」

「　日本語なのに Undo、 Redo というボタンを画面に配置するのも　負けた気になるしな」

「　画像ボタンは作れないのか？」

「　👇　機能はあるみたいなんで、頑張って　絵　を描くか……」

📖 ImageButton

「　👆　置くとこないし、右上でどうだぜ？」

「　やっつけ　わらう」

「　👆　機能を実装するには、これだけだぜ」

「　バグが起きたわよ」

「　えっ！？」

「　アンドゥ　したら、その操作が　ドゥ　されてるわよ」

「　アンドゥ中は　ヒストリーのドゥを通っても　そのドゥは　無視する必要があるのか」

（カタ　カタ　カタ　カタ）

「　状態遷移を管理して　修正したぜ」

「　リドゥが　１回しかできないんだけど？」

（カタ　カタ　カタ　カタ）

「　将来リストの中身を全部捨ててるところも　状態管理の内側に入れて直した」

「　完了リストが０件のときは　アンドゥ・ボタンを押せないようにしてくれだぜ。
将来リストが０件のときは　リドゥ・ボタンを押せないようにしてくれだぜ」

（カタ　カタ　カタ　カタ）

「　アンドゥ、リドゥは　完了リスト、将来リスト間の移動が終わってから実行しないと
画面更新時に　反映が後手後手になるのか。直して　実装した」

「　👆　ズームだけ　アンドゥ・リドゥに対応したぜ」

マップ切抜き画面、前に開いたときの内容が残ってる

「　お父ん、バグがあるぜ。
マップ切抜き画面、前に開いたときの内容が残ってる」

「　キャッシュされてるよな。
破棄して　新規作成してほしいんだが」

「　👇　キャッシュを止めてもらう方法がないか　調べるか」

📖 .NET MAUI シェルページ

「　👇　MAUI が更新されてないという情報が　よく見つかるな」

📖 Call Dispose() on Page and ViewModel when the page is popped if they implement IDisposable #7354

「　画面遷移が　進んでいるのか、　戻っているのか　フレームワークに情報を与える方法が無いのだから
キャッシュを削除していいのか、　キャッシュを残すべきか、判別できないんじゃないの？」

「　C# で　メモリ管理を自力実装することになるとは……」

グラフィック・ビューを、ビュー・モデルから Invalidate する方法が無い

「　グラフィック・ビューを、ビュー・モデルから Invalidate する方法が無いぜ」

「　👆　そら、ビュー・モデルは　ビューに指図しないしな」

「　横幅を振動させるトリック・コードを書くかだぜ？」

「　そのトリック、偶数回　振動させると　元に戻って使えないという弱点があるのよね」

「　縦に振動すれば　回避できるが……」

「　👆　試しに　Dirty　フラグを付けてみるか。このフラグが立ったら再描画されるといいんだが」

「　あっ、 Drawing の方でフラグを下ろしても、ビューモデルの方のフラグは下ろされてないから
１度フラグを立てると　立ちっぱなしで　プロパティ・チェンジしないぜ」

「　Byte 型値にして　永遠に足し続ければどうか？」

（カタ　カタ　カタ　カタ）

「　束縛変数に　変更通知をバンバン送っても　再描画は走らないぜ」

「　Drawable ではなく、 GraphicsView に変更通知を送る必要があるのでは？」

「　👇　他の人は　苦労してないんじゃないの？」

📖 Binding from view to GraphicsView property in .NET MAUI

「　👆　そのようなコードは動かない。　仕方ないので　トリックコードを使う」

「　フレームワークに不具合があると、トリックコードが増えていくの　わらう」

全部の操作に Do と Undo を用意しろだぜ

「　全部の操作に Do と Undo を用意しろだぜ」

「　アンドゥによる削除は　完全削除で、
手動操作による削除は　論理削除なのな。
これは　非対称でいいのかだぜ？」

「　論理削除フラグを　下げるだけで　元データが復活するのだから、
削除のアンドゥには　向いてるのに」

「　追加のアンドゥには向いてるの？」

「　追加のアンドゥで　論理削除されたデータを残すとして、
リドゥするのは　論理削除の解除ではなくて　上書きなんで、
追加のリドゥの役には立たないぜ」

論理削除してるのにデータが見えるバグ

「　👆　論理削除してるのにデータが見える」

「　直せだぜ」

「　そこに無いとき、選択アイテムを無しで上書きしないといけないんだが、
それをやってない気がするぜ」

「　切抜きカーソル と 選択タイル は別の概念なのに　プロパティを使い回している気がするな。
これを直すのは　大がかりなので、また今度だぜ」

「　上書きボタンをクリックして保存する という操作も止めたい。
テキストボックスに入力したら　そのまま保存してほしい」

「　アンドゥ・リドゥを考え出すと　設計に変更が生じるな」

📅 （2023-08-07 mon）アンドゥ・リドゥ機能を早よ作れだぜ

「　アンドゥ・リドゥ機能を早よ作れだぜ」

「　アンドゥ・リドゥ機能は　もう付いていて、
既存のプログラムを　すべて　それに対応していくという作業なんだぜ」

「　それを早よしろだぜ」

「　既存のプログラムの不出来なところを直さないと　そこへ進めないぜ」

📅 （2023-08-08 tue）アンドゥ・リドゥ機能を早よ作れだぜ（３日目）

「　アンドゥ・リドゥ機能を早よ作れだぜ。３日目だぜ」

「　既存のコードを　アンドゥ・リドゥ　に対応するために、事前のコードの整理整頓中だぜ」

「　プログラムがヘタクソで　すぐに　アンドゥ・リドゥ　に置き換えられないのねえ」

１つのボタンで　追加／上書き　の２つの機能を切り替えて使うの、やめたい

「　👆　１つのボタンで　追加／上書き　の２つの機能を切り替えて使うの、やめたい」

「　アンドゥするには　追加をアンドゥするのか　上書きをアンドゥするのか　はっきりしたいわねえ」

「　リドゥは同じ処理なのに、アンドゥは別の処理になるから　分けたいのか」

（カタ　カタ　カタ　カタ）

「　作りながら　方針転換していくのねえ」

TilesetSettings を TilesetDatatable へ名称変更

「　タイルセットに　設定ファイル３つもあって　名前が似ていてややこしいので、
CSV ファイルに対応するクラスは　TilesetDatatable に名称変更するぜ」

「　調整ばっかりだな」

(カタ　カタ　カタ　カタ)

上書きボタンやっぱ要る

「　あっ、　やっぱ　上書きボタン　要るぜ　戻す」

(カタ　カタ　カタ　カタ)

「　迷走してるわねえ」

「　上書きボタンは　名前を変えて　復元ボタンにするぜ。
論理削除フラグを解除するのに使うんだぜ」

「　本当に必要な最小限の機能を　洗い出したか？」

「　👆　例えば　復元は　こんなケースで使う」

「　マーカーが無い所で　タイル・タイトル入力できるの　おかしくない？」

「　状況を調べて　テキストボックスを不活性にするの　わりと大変な作業」

論理削除フラグが False になってる

「　見えないマーカーがあるんだが、論理削除フラグが　False　になってるぜ」

「　IsNone フラグと、 LogicalDelete フラグの２つがあるのが　ダメなのでは？
どちらか片方にしたら　どうだぜ？」

「　やってみるかだぜ」

（カタ　カタ　カタ　カタ）

「　論理削除済みの跡地を　クリックしても　選択できなくなったぜ。
だから　復元ボタンも　活性化しなくなったぜ」

「　論理削除されてない　何もないところなら　選択できるぜ」

「　カーソルが無いということと、カーソルが論理削除されているということは　何が違うの？」

「　論理削除されているカーソルは　有る　はずだぜ」

「　そこは　分けるのか……」

📅 （2023-08-09 wed）寝てた

Zzz

📅 （2023-08-10 thu）アンドゥ・リドゥ機能を早よ作れだぜ（５日目）

「　アンドゥ・リドゥ機能を早よ作れだぜ。５日目だぜ」

「　論理削除フラグのできが悪くてな。見直しだぜ」

「　👆　ファイルでは論理削除フラグが立ってるのに、
デバッグ出力では下りてるから、それがなぜなのかを調査するぜ」

「　ファイルから読み込んだときは　論理削除フラグは立ってるぜ」

「　じゃあ　途中で下ろしたのかだぜ？」

「　途中で　タイトルも消えて、論理削除フラグも下ろしてるな」

「　そんなことは　やめろだぜ」

「　ログにコードの場所を付けてみた。
タイルを選んだときに　タイトルと、論理削除を読み取ってないのかな？]

（カタ　カタ　カタ　カタ）

壊れた

「　👆　なんだか分からないが　壊れたぜ」

「　👆　x:Name を認識しなくなったぜ」

「　PCを再起動したら直った。何だったんだ……？」

「　なんか　エラー出るけど　無視して実行したら　動くな、不気味だな」

８月下旬の予定

「横幅を奇数、偶数振動させてるトリックコードを止めて、
オフセット 0, 1 を切り替える変数を別途用意したい。これは８月下旬にしよう」

「また　範囲指定するとき　Working　の方を使っているが、
全部　Source　の方を使うように変更したい。
Working　は変数にしないようにしたい。これも８月下旬にしよう」

📅 （2023-08-21 mon）ドーナツUI にしようぜ？

「　四方をぐるっと　青い領域で囲みたい」

「　👆　現状こうなわけだが」

「　👆　３重グリッドにするわけだぜ」

「　作業領域が狭いなあ」

「　MAUI のテキストボックスが　でかすぎんのよ」

「　👇　なんで　フォントがこんなに大きいのか分からん」

📖 .NET MAUI のフォント

「　👆　ルビ振る領域も考えると　ドーナツは　これだけ広くなる。
4K ディスプレイ推奨だぜ」

「　じゃあ　それで進めてくれだぜ」

ホーム画面もドーナツUI にしようぜ？

「　👆　ホーム画面も　四方をぐるっと　青い領域で囲みたいぜ」

「　👆　ドーナツUI にするとこう」

タイルセット一覧画面もドーナツUI にしようぜ？

「　👆　タイルセット一覧画面も　四方をぐるっと　青い領域で囲みたいぜ」

「　👆　こうなるぜ」

タイル切抜き画面もドーナツUI にしようぜ？

「　👆　タイル切抜き画面も　四方をぐるっと　青い領域で囲みたいぜ」

「　👆　ひとまず　こう。朝はここまで」

📅 （2023-08-22 tue）アンドゥ・リドゥをやってたのよ

「　アンドゥ・リドゥを　形にしないと　次に進まなくない？」

「　その前に　タイル切抜き画面の　トリック・コードが足引っ張ってるので
それの改修だぜ」

View Model がでかくなりすぎる

「　ビューモデルがでかくなりすぎる。
View Inner Models というフォルダーを作って中身を分けることにするぜ」

「　View History というフォルダーも作る」

📅 （2023-08-23 wed）寝てただけ

Zzz

📅 （2023-08-24 thu）コード掃除

「　コード掃除」

「　ビュー・モデルは　透過メソッドばっかりでも　良い気がしてきたな……」

📅 （2023-08-25 fri）コード掃除

「　コード掃除」

📅 この間　サボり

……。

📅 （2023-09-20 wed）ナビゲーションの作り直し

「　👆　パンくずリストは大変なので廃止した」

「　１か月近くサボっていたな」

「　その間に阪神タイガースが優勝したわよ」

「　👆　また、スクリーンショットからは見えないが、論理削除といった機能を　廃止した。
論理削除はデバッグを助けるが、論理削除自体のメンテナンスが大変だから嫌になった」

「　そういえば　Unity　が料金体系変更で　ひと騒動やってるらしいぜ」

「　Godot への乗り換えも考えないと　いけなくなるのかしらねえ？」

アンドゥ、リドゥのバグをマシにした

「　論理削除をやめたから、壊れていたアンドゥ、リドゥの動きが、マシになったぜ」

「　タイル切抜き画面は、そんなもんでいいだろ」

📅 （2023-09-21 thu）～（2023-09-27 wed）この間サボり

…

📅（2023-09-27 thu）Godot へ改宗する

「　わたしは　Unity　からイチ抜けた　をし、　Godot　へ改宗するぜ」

「　そうか」

「　次の記事はもう始まってるわよ」

次の記事へ

📖　Godot って何だぜ（＾～＾）？

2D RPG 制作ツールを作ろうぜ（＾～＾）？

2023-06-24T19:36:39+09:00

📅 2023-06-25 はじめに

「　２Ｄ　ＲＰＧ　制作ツールを作ろうぜ？」

「　なんで　お父んが　そんなこと　しなければならないのか？
働けだぜ」

「　思いついたら　やるんでしょ。
そこらへんの　凡人と同じよ」

「　👇　それより　作業用ＢＧＭ　かけようぜ？　気分を盛り上げないとな」

💿 Rockman ロックマン 11 [OST] Full Album

「　それは作業用ＢＧＭではなく、違法アップロード動画なのでは？」

「　👆　サイドＰＣを　Ubuntu　に差し替えたんで　Steam　を久しぶりに動かしてみたら、動いたんで驚いたぜ」

「　えっ？　ＲＰＧ制作ツールを作るのに　作業用ＢＧＭが　ロックマン１１　でいいのかだぜ？？」

MAUI を調べろだぜ

「　👇　企画と　アーキテクチャーを　長々と　説明しても　あれなんで……
MAUI を調べようぜ？」

📖 .NET MAUI (環境構築からHallo, World!～Windowsアプリ編～)

「　プラン全部　飛ばしたな。もう作業か」

「　あんたのお父ん　ノー・プランよ。
ウォーター・フォール・モデルの下流工程の　実装　という狭い範囲でしか仕事できないんだから。
あと　事務と経理」

「　それって　羨ましがられるらしいぜ。　いーな、コードばかりやってて、と」

「　なんか　知らん間に　Windows の 開発者モード というのが　オフ　にされているらしく、
これを　オン　にして　ビルド」

「　👆　これが　MAUI　を実行した画面か～。　なんなんだろうな　これ？」

「　何も分からん。　ロードマップもない」

「　Click me を押したら　ボタンを押した回数が出てくるぜ」

「　こっから　ツールを組み立てていくの、気が遠くなるわね～」

「　タイトル画面なんか作らずに　メニューがさっさと出てきたら　良くね？」

「　お父んがよく選ぶのは　家系二郎ラーメン、　塩ラーメン、　レモンサワー」

「　今日は　ネギ・ラーメン　にしようぜ？」

「　メニューって、そのメニューなの？」

👆　2D-RPG-Negiramen

「　👆　リポジトリ―は　作っておいたぜ」

「　ネギ・ラーメンは　リポジトリ―の名前じゃなくない？」

使用フォント：　📖　たぬき油性マジック

「　👆　こんな感じの　ファースト・ビュー　でどうだぜ？」

「　縦スクロール・バーは　付けておいてくれだぜ」

「　いいのか　よくないのか　分かんないから　さっさと作って　動かしてみましょう！」

「　👇　アラートが出てきたぜ。ここ読めだって」

📖　Build your first app

「　わたしが　やりたいことを　説明してくれるのではなく、
マイクロソフトが　説明したいことを　説明してくるので　つらいぜ」

「　画面にボタンを置きなさいよ」

「　👇　どこを読めばいいのか　分からない、ドキュメントとの戦いだぜ」

📖　Customize the app shell

「　👆　様々な概念が分からなかったが作った、とりあえず　これで」

「　じゃあ　とりあえず　マップを作る画面に進みなさいよ」

「　？？」

「　画面遷移って　どうやって　やるんだ……？？」

「　👇　これでも読めだぜ」

📖 .NET MAUI (いろんな画面遷移)

「　うーん？」

「　👆　AppShell.xml　というのを　何か設定しないといけない？」

「　👆　とりあえず　画面遷移は　できたぜ」

「　どうやって　ＨＯＭＥに戻るんだぜ？」

「　パンくずリスト　が有ったらいいんじゃない？」

「　👇　パンくずリストのような機能は用意されているのではなく、自力で作らないといけないらしいぜ」

📖　.NET Maui Tabs with Breadcrumb Navigation

「　👆　作り方　分からんので　とりあえず　ボタンとラベルで」

「　じゃあ次は　戦闘を作る画面に進みなさいよ」

「　👆　同様だぜ」

「　じゃあ　残りも　以下同様で　やってくれだぜ」

「　つら」

「　👆　.xaml ファイル増えてきて　邪魔なんだけど、置き場フォルダーは　どう作るのが　ベストプラクティス　なんだぜ？」

「　👇　調べろだぜ」

📖　MAUI(WinUI3)でMVVMを超単純にやる

「　👇　Qiita の素人記事読むぐらいだったら　公式読むぜ」

📖　Microsoft　＞　Upgrade your app with MVVM concepts

「　👆　こうすりゃいいのか」

「　MainPage.xaml も 📂 Views フォルダーに入れろだぜ」

エクスプローラーが要るんじゃないか？

「　お父ん。
プレイヤー・キャラクター編集画面に入る前に、
どのプレイヤー・キャラクターを編集するのか　選択する画面が　要るんじゃないか？」

「　あっ、そうか！
ほとんどの　データ編集ページで　リストが要るぜ！」

「　リストでいいの？
テーブルじゃなくて　いいの？」

「　じゃあ　エクスプローラー　だ。
MAUI にそんなコントロール　あるかな？」

「　👇　お父ん。コレクション・ビューと、テーブル・ビューを調べてみてくれだぜ」

📖　.NET MAUI (UIコントロール)

「　だから　素人が書いた記事なんか　読まねーっつーの」

📖　Microsoft　＞　CollectionView

「　👆　なんか知らんが　ListView より　かっこいいのが　CollectionView らしいぜ」

「　考えるの止めるの　わらう」

📖　Microsoft　＞　TableView

「　👆　コレクション・ビューを使うべきか、テーブル・ビューを使うべきの判断方法が分からん」

「　ページネーション（Pagination；ページ割り）の機能は付いているのかだぜ？」

「　調べたいことが　出てこないのが　マイクロソフトの　ドキュメントなんだぜ」

「　マイクロソフトの　Bing　の人工知能に利いても　MAUI　がなんだか分かってないし」

「　じゃあ、ページネーションも　自力実装することにしよう」

「　そうであるなら、クリテリア（Criteria；判断基準）が必要だぜ。
どのような規則に従って整列しているか、
表示されているデータは　何件目～何件目までのデータか、
表示されているのは　何ページ目か、
昇順か逆順か、
フィルタリングされているか」

「　無いものを　自力実装するのが　プログラマーだぜ。
必要だったら　片っ端から　実装していけばいいんだぜ」

「　迷ったら　テーブル・ビューと　コレクション・ビューの両方実装すりゃいいのよ」

「　ぬぎぎぎぎ！」

「　👆　こういう風に　途中に　検索ページを１枚　挟めばいいんだろ？」

「　デザインを分かってないエンジニアが作りがちな検索画面だぜ」

「　ぬぎぎぎぎ！」

「　動いているところを見ないと　よく分かんないから、
明日は　動くところを作ってみましょう」

「　ライセンスが　オープンソースの　２Ｄ　ＲＰＧの素材　なんも　持ってねー　ぬぎぎぎぎぎ！」

「　あっ！　ゲームとして利用するならフリーだが、素材集を　ツールに同梱して　そのまま再配布することを許可している素材が無いのか！」

「　当然よねえ」

Unity プロジェクトを作ろうぜ？

「　まあ　無いものは無いで　変数ｘ　とでも置いておいて　解けるところから先に解くのが　数学だぜ」

「　それを問題の先送りと言う」

「　👆　テンプレートは　２D　を選び、プロジェクト名は Negiramen Practice にして
プロジェクトを作成しようぜ？」

「　ネギラーメンでは、それが何だか　分かんなくない？
検索のサジェスチョンも汚すし」

「　聞き慣れてくれば　イカしてくるぜ」

「　なんか最初から　いろんなものが入っている……、ちょっと見てみるか……」

「　👆　多分　エディターなんだと思うんだが、この１つ１つを調べて行くか」

「　👇　お父んが作らなくても、すでに　いいものがあるのでは？」

📖 TileMapEditorはいいぞ！

「　オープンソースだけで　やりたいぜ」

「　👆　ちょっと　ボタンを追加しよう」

「　👇　それで……、テキスト・ボックスって　どうやって作るんだ？　調べるか……」

📖　Microsoft　＞　入力

「　Entry というタグがあるのか」

「　👆　それで　こういうページ作るだろ。
ディレクトリー・パスを入れて　ボタンを押すと……」

「　👆　Unity プロジェクトへ　フォルダーや　ファイルを送り付けるという算段だぜ」

「　Unity の外部で　ゲーム・オブジェクトを作れるの？
Unity の外部で　プレファブは作れるの？」

「　Unity に　そういう　ＡＰＩ　があるか？　ということだな。
調べてみようぜ？」

「　そんなことを　しようという人が少ないのか　記事が見当たらないな」

設定の保存を作れだぜ

「　毎回　📂 Assets フォルダーへのパスを入れるのが　面倒なんだけど？」

「　ユーザー・データとして保存したいよな。
最近流行りのファイル形式は何だぜ？」

「　👇　TOML 1.0 はどうだぜ？」

📖　公式　＞　toml

「　👇　Tomlyn を NuGET で入れてみるか」

📖　Tomlyn

MVVM

「　あれっ？」

「　このテキスト・ボックスの初期値って　どうやって　入れるんだぜ？」

「　👇　お父んが　さっき読んでいた記事に書いてあるだろ。 MVVM のところを読み直せだぜ」

📖　Microsoft　＞　Upgrade your app with MVVM concepts

「　👆　とりあえず　📂 Views 、 📂 ViewModels 、 📂 Models　の３フォルダーを揃えよう」

「　👆　なんだか分からないが　Model　は　ただのオブジェクトだろ。イミュータブルに作ったった」

「　👇　ViewModel　は　なんか複雑だな　説明を　よく読も」

📖　Create the About viewmodel

「　👆　ViewModel　は　Model　と　変更通知プロパティ　を紐づければいいんだろ？」

「　ビュー・モデルのデフォルト・コンストラクターは public 修飾にする必要があるぜ」

「　👆　View　は　ここまで書き足したぜ」

「　ボタンは　コマンドで書き直す必要があるんじゃない？」

「　👆　ViewModel　に　コマンドを取り付け。
ビュー・モデルは　MVVMアーキテクチャーの中で　雑用とか、アシスタント・ディレクターの役割を担当するんだな」

「　👆　View　も更新。
イベントハンドラを消し、コマンドを追加」

ユーザー・データをどこに保存するか？

「　👇　いろいろなフォルダーに　ユーザー・データは保存できるが、どこにするんだぜ？」

📖　特殊ディレクトリのパスを取得する

「　ユースケースによる。
２Ｄ　ＲＰＧ　を開発するような　アクターは、
いつも　同じ部屋で　同じ１台のパソコンを使って　１人で開発している、という状況設定を押し付けることにしようぜ？」

「　それ以上のものを要求するユーザーは　ネギラーメン　ではなく
もっと　金出して　高級な開発ツールを使えばいいのよ」

「　そりゃそうだぜ」

「　じゃあ　LocalApplicationData　だな」

「　あれっ？」

　　C:
　　└── 📂 Users
　　　　└── 📂 {ユーザー名}
　　　　　　└── 📂 AppData
　　　　　　　　└── 📂 Local
👉 　　　　　　　　└── 📂 Muzudho
　　　　　　　　　　　　└── 📂 2D RPG Negiramen

「　👆　他人のローカルＰＣに　わたしの名前のフォルダーが　ポコポコできるの　嫌なんだが……」

「　屋号、　サークル名、　ホームページ名など　いろいろあるけど」

「　仕事で金取ってないし　屋号もおかしいしな」

「　サークル名が　一番良いのでは？」

　　C:
　　└── 📂 Users
　　　　└── 📂 {ユーザー名}
　　　　　　└── 📂 AppData
　　　　　　　　└── 📂 Local
👉 　　　　　　　　└── 📂 Doujin Circle Grayscale
　　　　　　　　　　　　└── 📂 2D RPG Negiramen

「　👆　Grayscale だけだと　何だか分からないので、
かなり長いけど Doujin Circle Grayscale にしよう」

「　ひねりのない　名前にするからよ」

「　👇　あれっ！　MAUI　には　AppData 下の LocalFolder にアクセスする正式な方法が無い！」

📖　設定情報とデータの保存 (3/5)

「　マルチプラットフォームだから　Windows　のフォルダーにアクセスするのが　ナンセンスなんじゃないか？」

「　あっ、そうか～！」

「　MAUI　は他の手段を用意しているのかしら？　調べなさい」

「　👇　知らんことばっかりなら　調べればいいだけだぜ」

📖　File system helpers

                string mainDir = FileSystem.Current.AppDataDirectory;
                // Example: `C:\Users\むずでょ\AppData\Local\Packages\1802ca7b-559d-489e-8a13-f02ac4d27fcc_9zz4h110yvjzm\LocalState`

「　👆　UUID を含んだ文字の羅列になるらしい」

「　それは　ネギラーメンを何回実行しても同じディレクトリー名になるのかだぜ？」

string mainDir = FileSystem.Current.AppDataDirectory;
// Example 1回目: `C:\Users\むずでょ\AppData\Local\Packages\1802ca7b-559d-489e-8a13-f02ac4d27fcc_9zz4h110yvjzm\LocalState`
// Example 2回目: `C:\Users\むずでょ\AppData\Local\Packages\1802ca7b-559d-489e-8a13-f02ac4d27fcc_9zz4h110yvjzm\LocalState`

「　👆　同じだぜ」

「　今どき　合理的な解決方法　してんのねー」

「　👆　設定ファイルの保存の仕方は　覚え直した……。
やり方ぜんぜん変わってた……」

「　次は　そのファイルを読み取る方法を　覚え直せだぜ」

TOML形式ファイルを読み取ろうぜ？

「　👇　もう１回　Tomlyn　の調べ直し」

📖　Tomlyn　＞　Documentation

「　👆　これで　Toml　も読み込めるぜ」

「　👆　前に入力した内容も　フォームが覚えてくれるようになったから　楽になったぜ」

「　先送りにしていた　変数ｘ　は　どうすんの？」

「　絵を描くツールも　Windows Paint　と、　GIMP　しかないしな……
少し　ネットで調べる」

「　👇　特許が取られてるかどうか　分からん」

📖　WOLF Editor 公式　＞　【ﾏｯﾌﾟﾁｯﾌﾟ素材はどういう風に作ればいいの？】

「　👇　ゲームの特許なんか調べてられん。　ページ開いて出てくるの、こんなんだぜ？」

📖　特開2007-244536

「　じゃあ　訴えられて死ねだぜ」

「
真理は　避けられず
真実は　踏み込んだ者にしか見えず
真相は　勝手なものである」

「　ゲーム業界に首を突っ込みたかったら　死にましょう。
生きて帰るな。代わりに　徹底的に世界を破壊しなさい」

「　WOLF EDITOR のドキュメントが整理されているので、それ読む」

「　ピクセル・アートを描くのに　良い無料のツールって　どんなのだぜ？」

「　有料のフォトショップしか　選択肢　無いのに……」

「　👇　こんなサイトがあった。後で調べよう」

📖　www.pixilart.com

「　マップ・タイルは　16 x 16 ピクセル・サイズが単位のようだぜ」

「　それを　どれぐらいのサイズのキャンバスの中に　敷き詰めんの？」

「　マルチ・プラットフォームなのだから、答えはないぜ」

「　Nintendo Switch　は、　1080 x 720　だそうだぜ。
これを　参考に試算しよう」

📖　Nintendo　＞　Switch　＞　Technical Specs

「　タイル数で言うと、 67.5 x 45　枚だな。スクリーン上に　3037.5　枚のタイルがあるぜ」

「　一層で？」

「　オブジェクト数が　多い気がするけど、　ＲＰＧ　なら大丈夫なのかなあ？」

マップ・エディターの画面デザイン

「　👆　マップ・エディターって　こんなレイアウトで　いいのかだぜ？」

「　違うんじゃないか？」

「　👆　描画ツールが　いくつかあるんだぜ」

「　描画ツールって　どんなけ　あるんだぜ？」

「　👆　分からん。これぐらいから　始めればどうか？」

「　境界線ペンの仕様が　はっきり分かんないかしら？」

「　オート・タイルか。　説明が　よく分かんないんだよな」

「　👆　お父んに　分かりやすいように　まとめたぜ。
空間充填問題も　セル・オートマトンも　好きだろ」

「　うわっ　二ム計算みたいなの　出てきた」

「　あー、はいはい、分かりました」

「　👆　こんな役割なのよ」

「　接続時だけでなく、切断時の再計算も大変そうだ」

「　👆　でも　オート・タイルの仕様は　理解したな」

📅 2023-06-26 素材が何もない

「　👇　pixelart.com の使い方を練習する」

📖　www.pixilart.com

「　👆　あれっ？　64 x 64 pixel のつもりで描いたのに　でかいな……」

「　1216 x 1216 pixel あるわよ？」

「　じゃあ　使えないなあ」

「　👆　Save じゃなく、 Download すればいいのか」

「　じゃあ　これを最初のマップタイルとして　MAUI　の画面に表示してみようぜ？」

初期設定

「　👆　初期設定として　これだけ入力してくれないと　つらい」

「　ほとんどの人は　ディレクトリー・パスも入力できず　投げるんじゃないの？」

「　ファースト・ビューで　ユーザーが入力できるのは、
自分の名前と　メール・アドレスぐらいだぜ」

「　じゃあ　ファースト・ビューのボタンを　クリックするところまでは
設定無しで　行けるようにしよう。
そこで何か　ボタンを押したら　初期設定画面へ」

「　👆　パンくずリストで　どう表現したらいいんだぜ？」

「　サイト・マップのツリー構造を崩したくないから、
モーダル・ダイアログ・ボックス的に　ページ遷移せず出てくる　サブ・ウィンドウみたいにできないの？」

「　やり方分からん。調査だな」

📅 2023-06-27 モーダル・ダイアログボックスを作れるかだぜ？

「　👇　マイクロソフトのドキュメントって、スクリーンショットを使った説明が　圧倒的に足りないよな」

📖　.NET MAUI ウィンドウ

「　👇　じゃあ　まず　普通のサブ・ウィンドウを出して、閉じるところまで　やってくれだぜ」

📖 Opening a new window in MAUI

    /// 
    /// ［ウィンドウ表示テスト］ボタン押下時
    /// 
    /// このイベントを呼び出したコントロール
    /// この発生イベントの制御変数
    private void TestShowWindowButton_Clicked(object sender, EventArgs e)
    {
        var secondWindow = new Window
        {
            Page = new StartupConfigurationPage
            {
                // ...
            },
            Width = 1200,
            Height = 400,
        };

        Application.Current.OpenWindow(secondWindow);
    }

「　👆　これで　ウィンドウは　ポップアップされるけど、もっと簡単な書き方無いかなあ？」

    /// 
    /// ［ウィンドウ表示テスト］ボタン押下時
    /// 
    /// このイベントを呼び出したコントロール
    /// この発生イベントの制御変数
    async void TestShowWindowButton_Clicked(object sender, EventArgs e)
    {
        await Navigation.PushAsync(new StartupConfigurationPage());
    }

「　👆　こう書くと　同じウィンドウで　ページだけ　スライドする演出付きで　切り替わるぜ」

「　戻るボタンも　付いてるし、こっちの方が　かっこいいわよ」

「　ウィンドウを閉じるボタンは、どう書くんだぜ？」

「　👇　Navigation.PopAsync(); じゃないのかだぜ？」

📖　.NET MAUI (いろんな画面遷移)

「　ContentPage クラスを継承したコード・ビハインド　には　Navigation　書けるけど、
ViewModel のプロパティーである Command にはどこから　Navigation　持ってくるんだぜ？」

「　👇　Backwards Navigation があるんじゃないか？
await Shell.Current.GoToAsync(".."); を試せだぜ」

📖　Backwards navigation

「　おー、戻れたぜ」

「　戻ったはいいけど、次の画面に進みたかったんだけど」

「　グローバル変数で　進みたい画面を覚えさせとくかー」

「　構成設定の要求を　ページ間に挟むのは　でけた」

タイル・マップを Unity の Assets フォルダー下へコピーしろだぜ

「　👆　この画像を　Unity の Assets フォルダーへコピーしたいけど……」

「　この画像のファイル・パスって　どうやって指すんだぜ？
カレント・ディレクトリー　どこよ？」

「　指せるからこその Resources ディレクトリーなんじゃないの？
Special Directory に無いの？」

📖 Windowsの既定のイメージディレクトリ

「　Application.ImageDirectory を調べてみるかだぜ」

「　XAML の中にしか書けないらしい」

📅 2023-06-28 初期素材をどこに置くんだぜ？

「　👇　ワーキング・ディレクトリーの設定方法を調べた方がいいのでは？」

📖 How to change the Current Working Directory of Maui Blazor App

「　まず　AppDomain.CurrentDomain.BaseDirectory　が何を出力するか　調べてみてくれだぜ」

「　👆　bin ディレクトリーの方を向いていて、 Resources フォルダーなんか見にこないぜ」

「　じゃあ　マップ・タイル画像は　ネギラーメンの実行ファイルとは別に　配ったらいいんじゃないの？」

「　Git Hub にでも置いとけば　拾っていくかな？」

「　👆　とりあえず　ここに置いておくぜ」

「　👆　さらに調整」

「　ツクラーは　こんな設定　できないから　ＲＭＵは　全部入りのパッケージで売るのよ」

「　ソフトを自分で選んで　インストールして　設定するような
パソコンの正しい使い方をしたくないのが、　ツクラーだぜ」

「　ネギラーメンは　ツクラーの思想とは　おさらばだぜ。
ネギラーメンは　ただの食材を　ユニティーにコピーする　トッピング・ソフト　だぜ」

コピーしろだぜ

「　👆　さらに調整。
ハードコーディングしてしまったが、ただの Copy だぜ」

タイルを選ばせろだぜ

「　タイル・パレットを作ってみましょう。
この画像を　MAUI　に表示して、草原、砂漠、岩、海を　クリックできるようにしましょう」

「　👇　このポップアップというやつは　画面上に　画像が浮くやつじゃないか？
試してみようぜ？」

📖 マイクロソフト　＞　ポップアップ
📖 Microsoft　＞　Popup

「　👆　なんの説明も無いが、このパッケージが要るのでは？」

「　👇　全然　ビルド通らないなあ。調べるか」

📖 .NET MAUI Community Toolkit Popup PopupHandler is incompatible

「　👆　こんなん書く必要があるのかだぜ、分からんって」

「　👆　思ってるのと違って　モーダル・ダイアログボックスみたいなのが　出てきたぜ」

「　画面の真ん中じゃなくて、ボタンをクリックしたマウスの近くに　出せないの？」

「　分からん」

「　ポップアップではなく、サブ・ウィンドウにしろだぜ」

「　くそっ」

「　👆　サブ・ウィンドウを出すのは　前にやったんで」

「　そこに　タイルの画像を表示しましょう！」

「　👆　こんな風に　絶対パス書いたら　画像出てくるかな？」

「　さっさと　試せだぜ」

「　👆　出たけど　画像サイズが　さっぱり……」

「　そのサイズを　ぴったり　合わせてくれだぜ」

「　👆　ウィトス（WIdth；横幅）と　ハイト（Height；縦幅）を　指定すればいいのか」

「　なんか変なデバッグ用のツールバーと被ってるから　真ん中らへんに表示しましょう！」

「　👆　グリッドを使って真ん中へ」

「　画像にマウスカーソルを合わせたら、枠が出るようにしてみてくれだぜ」

「　オン・マウス・オーバー　みたいなイベントハンドラが無いか　探してみるかだぜ」

📖 Mouse hover detection in .NET MAUI

「　MAUI　は、スマホのようなタッチ・デバイスで使われることを想定していて、
デスクトップのようなマウス操作は　想定していないそうよ」

「　クソじゃないか」

「　マウス・カーソルの位置を取得できないか、調べてみてくれだぜ」

📅 2023-06-29 マウス・キャプチャーしてくれだぜ

「　👇　マウス・キャプチャー自体　どうやるんだぜ？」

📖 How to capture global touch events in MAUI app

「　MAUI には　マウス・キャプチャーは無いのよ」

「　じゃあ　Windows プログラミングかだぜ？」

「　👇　その前に　ジェスチャーを調べてくれだぜ」

📖 Recognize a tap gesture

「　👆　なんか　いっぱいある。
この PointerGestureRecognizer とか　それっぽくないかだぜ？
👇　調べるか」

📖 Recognize a pointer gesture

コマンドに引数をよこせだぜ

「　あれっ？　どうやって　コマンドに引数を渡すんだぜ？」

「　👇　調べろだぜ」

📖 Microsoft　＞　Commanding

「　👆　WPF みたいなものんか？」

「　👆　反応はしてるから、後は　引数を取りたいぜ。
もう少し調べるか」

📖 Microsoft　＞　PointerGestureRecognizer.PointerMovedCommandParameter Property

「　👆　パラメーターも　コマンドなんだ」

「　いや、取れない」

「　👇　何か無いか」

📖 .NET MAUI Custom control with command and parameters

「　👆　このコマンドから、何か引数にアクセスできないか？」

「　コマンドは　実行することしか　できないわねえ」

「　じゃあ　コマンドを使っちゃいけないんだ」

「　👆　コード・ビハインド　を使うと　画像上の座標を取ることはできるが……」

「　コード・ビハインドと　ビュー・モデルと　何の関係があるんだぜ？」

「　👇　WPFの依存関係プロパティみたいなものがないか　調べてみるぜ」

📖 How to use DependencyProperty in Maui?

📖 Microsoft　＞　Bindable properties

📖 How can I bind a property to a view model in MAUI?

「　👆　コード・ビハインドから、ビューにバインドされてる　ビュー・モデル　取れた……。
WPF の DataContext と同じ考えだ」

「　簡単ねえ」

「　画像上の座標　取れた……」

「　それを　いったん　ウィンドウ上の座標に変換して、
32 x 32 pixels サイズのタイルを囲む枠を　置いてくれだぜ」

「　👇　調べるか……」

📖 How to get MAUI UI element absolute coordinates

「　👆　画像の座標は取れるのか。だったら　それ使えばいいんじゃ……」

「　じゃあ　次は　枠を描こうぜ。
MAUI の画面上に　矩形を描く命令　あるかだぜ？」

「　👇　これを読めだぜ」

📖 Draw a rectangle

「　👆　canvas って　どっから出てきたんだぜ？
👇　調べるか」

📖 .net MAUI: how to draw on canvas

「　👆　赤い枠は出せたけど、位置調整が大変だ」

「　マウスカーソルは　１ピクセルずつ動いて欲しいけど、
赤い枠は　３２ピクセルずつ　動いて欲しい」

「　じゃあ　グリッド　が要るんだ」

「　センタリングされていて、座標計算が　めんどくさい」

「　左上が基準で　いいんじゃない？」

「　👇　なんで　Alignment じゃなくて Options って名前なんだ？」

📖 .NET MAUI コントロールの配置と配置

「　👆　例えば　こんな感じ？」

「　それっぽく　なったわねえ」

入力透過

「　タイル・マップを　クリックしたいのに、
その上のカーソルが　邪魔なんだが」

「　👇　入力透過を使えだぜ」

📖 VisualElement.InputTransparent プロパティ

「　よし、それでイケてるぜ」

マウス・クリックした座標から、カーソルの位置を算出しろだぜ

「　隣の砂漠をクリックしたら、タイル・カーソルがそこを指すようにしなさいよ」

「　👆　グリッドが　３２ピクセル固定で　ハードコーディングして　いけたぜ」

「　じゃあ　そのタイルを　マップ・エディター　で使いたいけど、
マップ・エディターが　まだ無いのよねえ」

「　じゃあ　明日から　マップ・エディター　だな」

📅 2023-06-30 ツール・アイコンが欲しいぜ

「　👇　ペンのアイコンの絵を描くぜ」

📖　www.pixilart.com

「　無くていいのに……」

「　気分が出る！」

「　👆　pixilart.com のツールに　グリッドのサイズ指定が無いから　枠線　引いてしまう」

「　どの画像の　何個目のタイルを表示するのか　名前で指定できるようにしたくない？」

tool_box.pen

「　👆　カテゴリー名と、そのメンバーを　ドット・シンタックスで指定して」

crop_image("tool_box.png", 0, 0, 32, 32)

「　👆　画像のロードまで　やってくれるような」

「　じゃあ　ＣＳＶ形式で記録したらどうだぜ？」

code           , file        ,  x,  y, width, height, comment
tool_box.pen   , tool_box.png,  0,  0,    32,     32, ペン
tool_box.eraser, tool_box.png, 32,  0,    32,     32, 消しゴム
tool_box.bucket, tool_box.png,  0, 32,    32,     32, 塗りつぶし

code                  , file               ,  x,  y, width, height, comment
adventure_field.grass , adventure_field.png,  0,  0,    32,     32, 草原
adventure_field.desert, adventure_field.png, 32,  0,    32,     32, 砂漠
adventure_field.rock  , adventure_field.png,  0, 32,    32,     32, 岩
adventure_field.sea   , adventure_field.png, 32, 32,    32,     32, 海

「　👆　例は　こうだぜ」

　　例：　C:\Users\むずでょ\Documents\GitHub\2D-RPG-Negiramen
　　└── 📂 Workspace
　　　　├── 📂 Assets
　　　　│ 　├── 📂 CSV
👉 　　│ 　│ 　└── 📄 tiles.csv
　　　　│ 　└── 📂 Image
　　　　│ 　　　└── 📄 tool_box.png
　　　　└── 📂 For Unity Assets
　　　　　　├── 📂 CSV
👉 　　　　│ 　└── 📄 tiles.csv
　　　　　　└── 📂 Images
　　　　　　　　└── 📂 Tile Set
　　　　　　　　　　└── 📄 adventure_field.png

「　👆　ツール・ボックスのアイコン・ファイルの置き場所は
ネギラーメンの　📄 Workspace/Assets/CSV/tiles.csv でいいかな？」

「　他のフォルダーも　けっこう　いじるんだな」

「　その　tiles.csv　を作るエディターが欲しいわよね」

「　タイル・パレット編集画面、みたいなやつかだぜ」

「　どんな画面レイアウトだぜ？」

タイル・パレット編集画面を作ろうぜ？

「　👆　コメントを入力することを考えると、横に広く使いたいしな」

「　👆　こんな雰囲気で　どうだぜ？」

「　配色が　ＲＯＣＫＭＡＮ　だな」

「　グリッドを引きなさいよ」

「　グリッド引くなら　ループ文を使うのが鉄板だと思うが
ＭＡＵＩで　ループ文があるのか　分からん……」

📖 MAUI equivalent to CSS background-repeat: repeat;

「　👆　Webみたいに　背景画像をタイルにしてリピートできるなら　グリッドが作れるかと思ったが
それも無いみたいだし」

「　動的に XAML の要素を追加・削除する方法も分からん」

「　透明なキャンバスに　罫線引いて　タイル・マップの上に　覆い被せりゃいいんじゃないの？」

「　それで行くか」

パンくずリストと、タイトル

「　👆　パンくずリスト付けたら　もっさり　したんだが、
ヘッダーと　パンくずリスト　を１つに　まとめる方法　無い？」

「　タイトルバーに見えるところ、自動で付くのよねえ」

「　👇　ナビゲーションじゃないか？　調べてみろだぜ」

📖 Microsoft　＞　NavigationPage

「　👇　ソースの中には　いじれそうなものは無かった。もっと探そう」

📖 How to customize the navigation title view of MAUI ContentPage

「　👆　初期状態は　こう書いてるのと　多分　おんなじらしい。
これをベースに改造してみようぜ？」

「　👆　パンくずリストと　ページ・タイトルを　同じ行に　まとめたぜ」

「　スマホの画面には　タイトル・バーが無いから、ページの中に作るのね」

「　ＰＣは　クローム（※）が付くんだな」

※クローム　…　ウィンドウの枠。タイトルバーなどを含む

グリッドの線、引こうぜ？

「　👆　ひとまず　ハードコーディングで　半透明の赤い色で　グリッドを置いてみたが　どうだろうか？」

「　まずは　いいんじゃないの？」

「　元画像の　横幅、縦幅も　表示してくれだぜ」

「　👆　さらに細かく調整」

「　タイル画像が大きかったとき、スクロールできんの？」

「　この画面は　ハリボテ　なんで……。
動きを付ける段階になったら　調べるぜ」

「　タイルＩｄを表示してくれだぜ」

画像サイズを調べようぜ？

「　その前に　１枚の画像にタイルが　１００枚ぐらいなのか、　１０００枚ぐらいなのか、　１００００枚ぐらいなのか、
規模を知りたいぜ」

📖 WOLF RPG エディター(ウディタ)でゲームを作る3　～マップチップとオートタイルを増やす～

「　👆　素材集の中を覗いてみないと　分からんな……」

📖 画像・音声素材データ集

「　👆　あれっ、思ってたより小さい……
横 332 × 縦 772 かだぜ？」

「　なんだ　その　中途半端な数は？」

「　あれっ？　枠が付いてある……　これは使用例のスクリーンショットか。
横 256 x 縦 608 のものもあるぜ」

「　なんだ　その　中途半端な数は？」

「　横 256 x 縦 544 のものもあるぜ」

「　決まってないのでは？」

「　横はニゴロ（２５６）のようだぜ」

「　じゃあ　縦長　になるんだ。ポートレートだ」

「　１つのタイル・サイズは　３２ｘ３２　を最小として、
６４ｘ６４　とか　９６ｘ６４　とか　自由気ままに配置されているぜ！」

「　６０８　は　３２　で割り切れるわねえ。１９よ」

「　素数だ」

「　どういうシステムなんだ」

「　じゃあ分かった、　256 × 608　を画面に表示してみようぜ？
👇　画像を作るぜ」

📖　www.pixilart.com

「　👆　ハリボテだが　スクロールバーは　付けれるぜ」

「　お父んの思想と　ウルフエディターの素材作成勢とで　相性が悪いの　わらう」

「　意匠は　相容れない方が　著作権を差別化できて有利なのよ」

「　明日は　このハリボテに　動きを付けていこうぜ？」

📅 2023-07-01 ページに引数を渡すにはどうやるんだぜ？

[http://www.example.com/index.html?name=banana](http://www.example.com/index.html?name=banana)
                                 ^^^^^^^^^^^^

「　👆　Ｗｅｂ系なら　ＵＲＬの後ろに　クエリー文字列を付けることができるが、
MAUI で画面遷移時に何かデータを渡すには　どうやるんだぜ？」

「　👇　調べろだぜ」

📖 MAUI：画面遷移時のデータの受け渡し

「　👆　parameters で　オブジェクトを渡せそうだな。
渡した先での　受け取り方も　調べるかだぜ」

「　👆　ビューモデルに　フィールドがあるとして……」

「　👆　フィールド名を使って、オブジェクトを渡せるみたいだな」

PNG 形式画像ファイルのサイズを取得してくれだぜ

「　PNG 形式画像ファイルのサイズを取得してくれだぜ」

「　あれっ？　やり方が分からん……
👇　調べるか……」

📖 [C#]PNGの幅，高さのみをファイルから高速に取得する方法について
📖 【C#】PNG画像サイズの取得方法

「　👆　渡せるものと、渡せないものとがある。
調べるか……」

「　👆　QueryParameter アトリビュート（属性）をクラスに１個１個すべて書くのが確実らしい」

「　MVVM 実装してるだけで　１日　終わりそうだ」

「　画面は　手戻り無しで　１発で作らないと　時間が　厳しそうねえ」

「　要らん画面　作ったら　１日は無駄になるな」

「　👆　変更通知プロパティの手順の順序を　間違えると　画面に出てこないから　正確にやるぜ」

「　👆　画像サイズに　動きを付けたぜ」

「　全部に動きを付けてくれだぜ」

「　つら」

GraphicsView はどうやってリフレッシュするんだぜ？

「　👆　グリッドは GraphicsView を使ってプログラム的に描画しているが、
これは　どうやって再描画するんだぜ？」

「　👇　調べろだぜ」

📖 Microsoft　＞　GraphicsView

「　👆　graphicsView.Invalidate(); を呼び出せばいいのか。やってみるかだぜ」

「　ビューモデルから　どうやって　graphicsView　にアクセスするんだぜ？」

📖 Binding from view to GraphicsView property in .NET MAUI
📖 How to databind imageview with drawable in viewmodel?
📖 .NET MAUI: Dynamic behaviour of graphic elements when using MVVM

「　👆　同じ悩みを持ってるやつらが　見つからんなあ」

「　Drawable に変更通知プロパティを　仕掛けられないの？」

「　👆　ビュー・モデルから　IDrawable 実装インスタンスの Draw をコールする方法も分からん」

「　ビュー・モデルから　ビューに　アクセスできないのかだぜ？」

「　調べてみるか」

「　ビュー・モデルは　変更通知プロパティ　をビューに仕込んで連携できるだけだな」

「　ビュー・モデルの方から　ビューのキャンバスを変更できないと　グリッド・サイズを更新できなくない？」

「　👆　リソースに　引数を渡す方法って　ある？」

「　👇　調べろだぜ」

📖 Resource dictionaries

「　リソースは　スタティックなんじゃない？」

「　じゃあ　GraphicsView　を使って　グリッドを描画するのが　そもそも間違ってる？」

「　そうなのでは」

「　伸縮自在なラインを　固定長で１０００本ぐらい　画面に持たせた方がいいのかだぜ？」

「　👆　GraphicsView の横幅、縦幅は　バインディングできるから、
ビューモデルから　縦幅、横幅の変更通知を送ったら　IDrawing 実装インスタンスの Draw メソッドを呼び出してくれないかな？」

「　試せだぜ」

「　👆　なんらかのタイミングで　Draw メソッドの dirtyRect 引数に矩形が入っているから、
あとは　ビュー・モデルから　任意のタイミングで Draw をコールできれば　うまくいきそうだが」

「　👆　画面を出した初回は　画像サイズが分かってるんで　グリッドも合わせられるぜ」

「　グリッド・サイズは途中からも　変えたいのよ」

「　👆　グリッドの横幅が変更されたタイミングで
グリッドの画像サイズの横幅を 1px 伸ばしたったら、再描画が呼び出されるけど」

「　イケてないわねえ」

「　再描画が呼び出されるトリガーのうち、もっとも無難なものって何だぜ？　タグの変更トリガーとか無いのかだぜ？」

「　タグだって　変えられたくないわよ」

トリック・コード

「　👆　今回のプログラミングで最初のトリック・コードだぜ。
画像の横幅が偶数のときは　横幅を１伸ばし、
画像の横幅が奇数のときは　横幅を１縮めて　無限に振動させるぜ」

「　わらう」

「　グリッドのサイズを変えるたびに
グリッドの右端が　１ｐｘ飛び出たり　元に戻ったりするんだけど」

「　トリックがバレないように修正する」

「　👆　トリック・コードのせいで　割り食って　おかしくなっている箇所は
キャンセル・コードを書いて　おかしなものを　隠すぜ」

「　不毛な戦い　わらう」

「　トリック・コードなんか書くからよ」

「　グリッド・サイズを変えれるようになった。今日はここまでだぜ」

「　ＭＶＶＭの実装　時間かかるんだな、作る画面は　最低限の数で済むように　全体を考えないとな」

📅 2023-07-02 タイル・パレット編集ページを作っていこうぜ？

「　👆　グリッドの全体も　ずらせるようにしたので、位相にも対応だぜ」

「　スクロールとかねえ」

「　線形代数の変換の王様、アフィン変換にも対応しろだぜ」

「　開発時間足りない。次へ」

「　👆　カーソルが　グリッドに　吸着するようになったぜ」

「　これだけで　日曜日が終わろうとしている。時間がかかるな」

「　下側の　タイル　０　０　０　０　のとこに　カーソルの位置を表示しなさいよ」

「　👆　はい」

「　お父ん。グリッド１ます　の　たて　に　50000　と入れたら強制終了したぜ？」

「　👆　確かに。あのグリッド、ただの縦線じゃなくて　画像だからな」

「　テキスト・ボックスに　バリデーション（妥当性検証）を入れなさいよ」

バリデーションを入れようぜ？

「　👇　何もかも　やり方が分からん。覚え直しだ。　調べるか……」

📖 Microsoft　＞　Validation

「　👆　説明の通りコードを書いても　IValidity　のところで　コンパイル・エラーになるの　分けわからんな」

「　この記事が　クソ　だということを伝えるボタンが無いぜ」

「　👇　文字数のチェックはできるみたいよ？」

📖 TextValidationBehavior

「　もっと　まともな方法を調べるぜ」

📖 RequiredStringValidationBehavior
📖 NumericValidationBehavior

「　👆　NumericValidationBehavior を調べてみるか」

「　👆　下ごしらえは　XAML　だけで終わるの　簡単だな」

「　１辺の上限が　16384　じゃなくて、
面積の上限が　16384　か？
ルート２　したら　128　で小さすぎないか？」

「　10000 x 10000 にしても動いているぜ？」

「　なんか限界　攻めたくないな。
グラフィック・カードの性能に依存するのかも知らん。
とりあえず　上限は　8192　にしよう！」

「　2 の 13乗に　意義を感じないわね」

「　👆　じゃあ　無難な　上限　2048　にして、
文句があるやつがでてきたときに　拡張用の設定ファイルを用意しようぜ？」　

「　設定できるんなら　それでいいよな」

「　👆　あれっ？　色が変わるだけで　入力できてしまう？」

「　入力を拒絶しなきゃ、意味なくない？」

「　ビュー・モデルの方で　2048　以上を入力したら　2048　として扱うような処理がいるかもしれないな」

「　あっ、 0 を入れても　フリーズしたぜ」

「　明日は　バリデーション　を　みっちり　やるぜ」

📅 2023-07-03 バリデーションを入れようぜ？

　　C:
　　└── 📂 Users
　　　　└── 📂 むずでょ
　　　　　　└── 📂 AppData
　　　　　　　　└── 📂 Local
　　　　　　　　　　└── 📂 Packages
　　　　　　　　　　　　└── 📂 1802ca7b-559d-489e-8a13-f02ac4d27fcc_9zz4h110yvjzm
　　　　　　　　　　　　　　└── 📂 LocalState
　　　　　　　　　　　　　　　　├── 📄 configuration.toml
👉 　　　　　　　　　　　　　　└── 📄 settings.toml

「　👆 settings.toml ファイルを作って、そこに　グリッドのタイル・サイズの一辺の上限は 2048 だという設定を
書いておこうぜ？」

「　両端に太さが 2px のグリッドの線があるから、1px ずつ食み出るとして 2048 から 2px 引いて 2046 にすべきだと思うが」

「　上限値の理由に　意義がないのよ」

「　じゃあ 2046 !」

[tile]

# 一辺が 2048 ピクセルのキャンバスを想定し、両端に太さが 2px のグリッドの線があって 1px ずつ食み出るから 2px 引いて 2046
max_width = 2_046
max_height = 2_046

「　👆　１辺が 2048 ピクセルのタイルを作りたいやつは　設定を変えろ」

「　👆　バリデーションというのは　ビューの色を変えるぐらいしか機能がないので、
ビューモデルでは　単に　リミット・チェックを入れた」

「　入力された値は（弾かず）とりあえず受け取る、という思想なのね」

「　入力を受け取らないフラグ　無いのかなあ？　もっと探してみろだぜ」

「　疲れたんで　とりあえず　次へ」

マウス・ドラッグに対応しろだぜ

「　お父ん。マウス・ドラッグして　タイルを連続選択できないのかだぜ？」

「　作ってない機能は　存在しないぜ」

「　作れ」

「　ドラッグ　アンド　ドロップなのかな？
プレス　アンド　リリースじゃないかな？」

「　ドラッグ　アンド　ドロップって、
ファイルをつかんで　アプリケーションの領域に落とすやつを言うのよ。
タイルの連続選択は　プレス・アンド・リリース　じゃないかなあ？」

「　今は　タップした時点で　カーソルの位置が決まっているが、
リリースした時点で　カーソルの位置を決めた方がいいのかだぜ？」

「　もっさりしない？」

「　操作感は　統一的になると思うが」

「　タップしたジェスチャーは　捕捉できるが、
リリースしたというジェスチャーは　どうやって捕捉するのかな？
調べるか」

📖 スワイプジェスチャを認識する

「　👆　スワイプは　向きだけかあ」

📖 ドラッグアンドドロップジェスチャを認識する

「　👆　ドラッグ　アンド　ドロップは　ファイルを落とすやつだしな」

📖 ポインタージェスチャを認識する

「　👆　ポインター・ジェスチャーには　入りと　出があるのか。これを調べてみるか」

「　エンターは　画像と重なったところで、
エグジットは　画像の外と重なったところか。
マウス・ボタン押下とか、マウス・ボタン・リリースではないんだ」

「　タップは　マウス・ボタン押下と　マウス・ボタン・リリースのペアか？」

「　そうだぜ。
それも　マウスを移動させずに　マウス・ボタン押下と　マウス・ボタン・リリースを
行わなければいけないぜ」

「　じゃあ　タップは　従来の　クリック　に対応してるんだ」

「　マウス・ボタン押下と、　マウス・ボタン・リリースを　別々に捕捉する方法を探せだぜ」

「　MAUI には無いようだぜ」

「　マウス・ダウンと　マウス・アップを検知する　何らかの方法はあるのかしら？」

「　タップで始まり、タップで終わるのでいいだろ」

「　ペン・タブレットで　必要になりそうな機能が　MAUI　に無いなんて
理解できないが　お父んは　そのような　理不尽や　意味不明を　越えていくのに長けているのだろう」

「　👆　カンペキは無いものだぜ。タイルの連続選択できあがり」

📅 2023-07-04 タイルを登録できるようにしろだぜ

「　タイルは　名前で管理するのか？　Ｉｄで管理するのか？」

「　現代は　UUID　が流行ってて　URL　は　わけの分からない数字、文字の羅列になってしまったが、
UUID　が真のＩｄなら　URL　無くして　UUID　にすればいいものの、
そうならないのは　名前　からイメージできる姿があるからだぜ」

「　名前は　アスキー文字にすんの？
ユニコードにすんの？」

「　こんな　ネギラーメンで　ユニコードが使えない環境のことを　本気で考えなくていいだろ。
ユニコードでいいんじゃないか？」

「　文字数は？」

「　本気で考えなくていいだろ。　６４文字でいいんじゃないか？」

「　１～４バイトのユニコード文字が　６４個であることの意義は？」

「　無いけど……」

「　ツクラーが　タイルに名前を付けようと思ったときの　文字数の分布は？」

「　データは無いけど……」

📖 Tiledによるタイルマップの作成とオブジェクトデータの取得を行う！：Cocos Creator
Tiled Cocos Creator

「　👆　誰も　タイルに名前なんか　付けないのでは？」

「　アマゾンの商品名の長さは？」

📖 KRAFT Macaroni & Cheese Easy Mac Cups (12 x 2.05 oz cups)クラフト　マカロニチーズイージーカップ　12パック　海外直送

「　👆　適当にクリックしたが　英語表記、日本語表記をつなげて　重さや個数、海外直送まで入っているぜ」

「　ざっくり　１００文字にしたら？」

「　そうするか……」

「　すると　みんな　タイル名に　検索のための情報を　詰め込みだすのでは？」

「　名前とは別に　タグを付けれるようにするかだぜ？」

「　１つのタイルに　タグは何個付けれて、１つのタグの長さは何文字までなの？」

「　これは再帰的な話しで、１つのタグに　たくさんの検索の情報を詰め込みだす……」

「　タイル名を付けるの　めんどくさくなって　タイル１、 タイル２、タイル３　みたいな名前を付けるやつが
蔓延したらどうする？」

「　連番付けられるぐらいだったら、　Ｉｄ　は　こっちで採番してやるかだぜ」

「　１つのタイル・セットに、何枚のタイルがあんの？」

「　データは持ってない」

「　Ｉｄ　だけ必須にして、それは自動で採番して、
１００文字のテキスト・フィールドに　半角カンマ区切りで　タグを自由入力させたらどうだぜ？」

「　４９個のアルファベットを　タグで登録するやつがいて　うざいかもしれない」

「　タグも　日本語で入力されたり、英語で入力されたり、表記揺れしたりするんじゃない？」

「　じゃあ　カテゴリー・ツリーを予め　こっちで定義して　そのノードを選ばせる方式にして、
それ以外に　固有名詞　を自由に入れれる欄を置けばどうか？」

「　Ｉｄ欄と、１００文字のコメント欄の２つにしましょう！
検索のための仕組みは　後回しで」

「　👆　こんな感じで　いいのかだぜ？」

「　動かしてみないと分かんないから　それで　作ってみましょう」

　　C:\Users\むずでょ\Documents\Unity Projects\Negiramen Practice\
　　└── 📂 Assets
　　　　└── 📂 Doujin Circle Negiramen
　　　　　　└── 📂 Negiramen Quest
　　　　　　　　└── 📂 Auto Generated
　　　　　　　　　　└── 📂 Data
　　　　　　　　　　　　└── 📂 CSV
　　　　　　　　　　　　　　└── 📂 Tile Set
👉 　　　　　　　　　　　　　　└── 📄 map-tile-format-8x19.csv

「　👆　ファイルは　ここに置いとくぜ？」

Id, Left, Top, Width, Height, Comment
 1,   96,  64,    64,     64, 草原

「　👆　保存内容は　こんな感じで　いいかだぜ？」

「　とりあえず　それで」

「　クエリー・パラーメーターで　ビュー・モデルへ　ＣＳＶファイルへのパスを渡したつもりなんだが、
コード・ビハインドの　Load　時には　ビュー・モデルに　ＣＳＶファイルへのパスが入ってないな」

📖 .Net Maui/XAML QueryParameter is NULL in the viewmodel Constructor but usable in XAML, how do I access it in the viewmodel?

「　👆　書かれてる通りにやってるんだが……、あっ、スペルミスだ！」

「　👆　とりあえず　ハリボテ　で、１行追加　できるようにしたぜ」

「　コメントの文字数のバリデーション、
Ｉｄの自動採番、
既に追加されているタイルは　コメントを表示、ボタンのラベルも［追加］から［上書］へ変更、
削除ボタンの実装、
ＣＳＶを固定レイアウトではなく、列名を見るように変更、
ＣＳＶのダブルクォーテーションのエスケープ、
少なくとも　これらは　残っているな」

「　気の遠くなる話しだぜ」

「　じゃあ　睡眠へ切り替えよ。寝ろ」

📅 2023-07-05 マウス操作が分かりづらいの何とかしろ

「　MAUI がタップ操作にＵＩを寄せていて、マウスダウン、マウスアップ　が検知できないの　クソなんだが」

「　最初の１回目のタップで　あんたが枠を出すから、これでいいんだと思っちゃって
そしたら　もう１回　タップしなくちゃいけないって分かって　分かりづらってなるのよ」

「　選択が未確定の間は　カーソルが　アニメーションしたらどうだぜ？」

「　画面が　チカチカ　動くのは　オフィス・ソフトの分野では　非常識だぜ」

「　半透明な枠なら　どうよ？」

「　👆　これぐらい　はっきりと分かるぐらい　半透明にしてみるか」

Ｉｄを自動採番しろ

「　ＣＳＶファイルの中で１番大きなＩｄより　１　だけ大きいのが　新しいＩｄだろ。
お父ん。実装しろ」

「　スキャンするのは　カッコ悪いから　行が追加されたタイミングで　最大のＩｄを常に更新するかだぜ」

「　👆　Ｉｄは　増えるようにしたぜ」

登録されているタイルは表示しろ

「　登録されているタイルは　表示してくれだぜ」

「　タイルが　１０００個　登録されていたら、
画面上には　タイル　１０００個　のスプライトを　表示しないと　いけないのかだぜ？」

「　画面を開いたときと、
タイルを追加・削除したときに　キャンバスを描きなおせばよくない？」

「　じゃあ　実際のタイル画像とは別に、
ワーキング（Working；作業中）なタイル画像を　内部的に持っておけばいいかな」

「　👆　Source に内部メモリーを指定できるのかだぜ？」

「　外部ファイルで十分なんじゃないの？」

「　作業中の画像は、
ネギラーメンのワーキング・スペース、
ユーザーの AppData、
ユニティの Assetsフォルダー、
どこに置くのがベスト・プラクティスだぜ？」

「　ユニティの Assets フォルダーには　資産じゃないものは　置きたくないわねえ」

「　ユーザーの AppData に　ゴミを置きたくないぜ」

「　じゃあ　ネギラーメンのワーキング・スペースかだぜ」

「　ネギラーメンを２重起動しなければ　問題ないんじゃない？」

　　例：　C:\Users\むずでょ\Documents\GitHub\2D-RPG-Negiramen
　　└── 📂 Workspace
　　　　├── 📂 Assets
　　　　├── 📂 For Unity Assets
　　　　└── 📂 Temporary
　　　　　　└── 📂 Images
👉 　　　　　　└── 📄 working_tile_set_canvas.png

「　👆　こんな感じで　テンポラリー（Temporary；一時的な）フォルダーを切ろうかな？」

第２の構成ファイル

「　ファイル・パスは　ハード・コーディングするのか？」

「　いーや。ソース・コードの中に設定が書かれているのは　メンテナンス　時の選択肢を狭めて良くない。
外部ファイルで全部　指定できるようにしたいぜ」

　　例：　C:\Users\むずでょ\Documents\GitHub\2D-RPG-Negiramen
　　└── 📂 Workspace
👉 　　└── 📄 configuration_2nd.toml

「　👆　第２の構成ファイルだから、こんな感じでどうだぜ？」

「　じゃあ　とりあえず　それで」

[paths]

# ネギラーメン・ワークスペースの作業中のタイル・セット・キャンバスPNG画像ファイルへのパス
working_tile_set_canvas = "{negiramen_workspace_folder}/Temporary/Images/working_tile_set_canvas.png"

「　👆　ファイルの中身は　こんな感じでどうだぜ？」

「　とりあえず　それで」

「　👆　厳密に行くなら　構成ファイルに　この１行を書き足しておきたいぜ」

「　そのファイル・パスは　MAUI から編集できるようにするのかだぜ？」

「　非表示でいいだろ、こんな細かいの」

「　ユーザーが　そのファイルに辿りつけなくない？」

「　AppData は　隠しフォルダー　なんで」

「　じゃあ　ネギラーメンを開発する　お父ん　や、
ネギラーメンを改造する人だけが　知ってればいいんだ」

「　configuration_2nd.toml は　隠さなくていいの？」

「　どこに　何が置いてあるかの　目録になるんで」

「　configuration_2nd.toml って名前だったら、じゃあ configuration_1st.toml は　どこにあるんだ？
って探さない？」

「　ぐぬぬぬぬ」

　　例：　C:\Users\むずでょ\Documents\GitHub\2D-RPG-Negiramen
　　└── 📂 Workspace
👉 　　└── 📄 user_configuration.toml

「　👆 user_configuration.toml にしよう！」

設定ファイルの中で変数展開

「　👆 設定ファイルの中で変数が使える仕組みを　簡易実装したところで　今日はここまでだぜ」

「　最初に作っとかないと　あとで困るやつだし、
本筋の作業が進んでないけど　いっか～」

「　なかなか　前に進まないな……」

📅 2023-07-06 タイル・パレット編集画面へタイル・セット画像ファイルへのパスを渡せだぜ

「　お父ん、タイル・セット画像へのファイル・パスをハードコーディングしてるだろ。
まず　これを　クエリー・パラメーターに置き換えて、
画面遷移元から　タイル・セット画像へのファイル・パスを受け取る形にしろだぜ」

「　わかったぜ」

（カタ　カタ　カタ　カタ　……）

「　でけたぜ」

「　次はその　タイル・セット画像へのファイル・パスを読込んで、
そして
C:/Users/むずでょ/Documents/GitHub/2D-RPG-Negiramen/Workspace/Temporary/Images/working_tile_set_canvas.png へ出力しろだぜ」

「　やってみるぜ」

（カタ　カタ　カタ　カタ　……）

「　👇　C# なら ImageIO 使えばいいのかだぜ？」

📖 画像ファイルを読み込み、Imageオブジェクトを作成する

using System.Drawing.Image;

「　👆　MAUI に System.Drawing.Image 無い」

「　マルチプラットフォーム化で　使えなくしているパッケージなのでしょう」

「　👇　現代では　こっち読むのか。インターネット上の大量の記事が　無駄になったかも知れないなあ」

📖 Microsoft　＞　Image（コントロール）
📖 Microsoft　＞　イメージ（メモリー）

        Assembly assembly = GetType().GetTypeInfo().Assembly;
        using (Stream stream = assembly.GetManifestResourceStream("GraphicsViewDemos.Resources.Images.dotnet_bot.png"))
        {
            image = new W2DImageLoadingService().FromStream(stream);
        }

「　👆　リソース・フォルダーの中の画像を取得する方法が　書いてるな。
今回は逆に　任意のディレクトリーの画像のメモリー・ストリームを取らないといけない」

📖 Microsoft　＞　Bundled files

public async Task ReadTextFile(string filePath)
{
    using Stream fileStream = await FileSystem.Current.OpenAppPackageFileAsync(filePath);
    using StreamReader reader = new StreamReader(fileStream);

    return await reader.ReadToEndAsync();
}

「　👆　このテキスト・ファイルの例を、画像に書き換えられないか？」

using Microsoft.Maui.Graphics.Win2D;

「　👆　このネームスペースが存在しないんだが？」

「　NuGet で取ってくるんじゃないの？」

「　👆　これかな？」

「　それはインストール済みだぜ」

「　👆　じゃあ　このエラーは何だぜ？」

「　プリプロセッサ・ディレクティブを使って　Ｗｉｎｄｏｗｓと　Ｍａｃを分ける必要があるんじゃないの？」

#if IOS || ANDROID || MACCATALYST
using Microsoft.Maui.Graphics.Platform;
#elif WINDOWS
using Microsoft.Maui.Graphics.Win2D;
#endif

// ... 中略 ...

#if IOS || ANDROID || MACCATALYST
                // PlatformImage isn't currently supported on Windows.
                TheGraphics.IImage image = PlatformImage.FromStream(inputFileStream);
#elif WINDOWS
                TheGraphics.IImage image = new W2DImageLoadingService().FromStream(inputFileStream);
#endif

「　👆　プラットフォームの違いを　メソッドが隠蔽してくれたらいいのに……」

        //
        // タイル・セット・キャンバス画像の読込
        //
        var task = Task.Run(() =>
        {
            try
            {
                // 読込元（ウィンドウズ・ローカルＰＣ）
                using (Stream inputFileStream = System.IO.File.OpenRead(tileSetImageFilePathAsStr))
                {
#if IOS || ANDROID || MACCATALYST
                    // PlatformImage isn't currently supported on Windows.
                    TheGraphics.IImage image = PlatformImage.FromStream(inputFileStream);
#elif WINDOWS
                    TheGraphics.IImage image = new W2DImageLoadingService().FromStream(inputFileStream);
#endif

                    //
                    // 作業中のタイル・セット・キャンバス画像の保存
                    //
                    if (image != null)
                    {
                        // 書出先（ウィンドウズ・ローカルＰＣ）
                        using (Stream outputFileStream = System.IO.File.Open(workingTileSetCanvasImagefilePathAsStr, FileMode.OpenOrCreate))
                        {
                            image.Save(outputFileStream);
                        }
                    }
                }
            }
            catch (Exception ex)
            {
                // TODO エラー対応どうする？
            }
        });

「　👆　MAUI から　Windowsのフォルダーにアクセスできるけど、
マルチ・プラットフォームというメリットが無くなってしまうよな」

「　じゃあ　Windows　の利便性を失わせるかだぜ？」

「　ユーザーに AppData フォルダー下を　いじらせるのは
隠しフォルダーの意義を失うわよ」

「　じゃあ　Windows依存で進めるか～」

「　👆　PNG画像の書出しまで　でけたぜ」

「　今は　タイル・セット画像の方を　MAUI　に表示してるだろ。
それを止めて、こっちの　作業中のタイル・セット画像の方を　MAUI　に表示してくれだぜ」

「　分かったぜ」

（カタ　カタ　カタ　カタ　……）

「　その差し替えも終わったぜ」

「　すでに登録済みのタイルは　半透明の青色で塗りつぶしておくと、
残作業が見えやすくなるんじゃない？」

「　やってみるぜ」

Microsoft.Maui.Graphics.IImage

Microsoft.Maui.Graphics.ICanvas

「　👆　あれっ？　描画ができるのは　IImage　じゃなくて、　ICanvas　の方だぜ？」

「　IImage　を　ICanvas　に変換する方法がないか、調べろだぜ」

「　ググっても出てこないから　デバッグライトするぜ。
IImage の実体は　W2DImage　らしいんだが、これも探しても出てこない」

「　Ｗｉｎｄｏｗｓの２Ｄイメージなんじゃないの？」

「　タイル・カーソルと同じように　IDrawable を実装したクラスを作って、
XAML の GraphicView 要素の Drawable 属性で指定したらどうだぜ？」

「　あっ、そうか！」

「　IDrawable　を実装したクラスと、ビュー・モデルが連携できないの
グローバル変数での連携が大変だぜ、どうにかならないの？」

「　👇　BindableObject というのが　あるそうだぜ」

📖 In .NET MAUI, how do I pass variables to a GraphicsView.Drawable in a ContentView
📖 How to pass variable data into .NET MAUI GraphicsView canvas

「　覚えてみるかだぜ」

📅 2023-07-07 ＩｄをＢＡＳＥ６４にしようぜ？

「　Ｉｄ　を　ＢＡＳＥ６４　にしようぜ？」

「　メリットは？」

「　人は　整数を見ると　１から順にソートしたくなる。
ＢＡＳＥ６４　なら　ソートしようとは思わない。
Ｉｄをソートしようとする悲しい人類を救うことができる」

「　エビデンスは？」

「　無い。本番環境で実験だぜ」

「　やってみろだぜ」

「　👇　Convert クラスを使ってみるか」

📖 Convert.ToBase64String メソッド
📖 Converting string to byte array in C#

「　👆　Ｉｄを　ＢＡＳＥ６４にしたぜ」

「　わらう」

「　👇　桁数が気になるわね。
1 は MQ== だけど、 1000 は MTAwMA== よ？」

📖 データ変換ツール

「　３桁ぐらいの文字なら　４桁ぐらいに変換されて気にならないが、
４桁ぐらいの文字は　８桁ぐらいに変換されて　メモリ効率は　２倍になって　悪くなるな。
だいたい、　１．３倍ぐらい　メモリ効率は悪くなるぜ」

「　メモリ効率が１．３倍に悪くなることと引き換えに
悲しい人類がＩｄをソートしようとすることを防ごうと言うのね」

「　👆　Ｉｄが１０００に達したとき、ＢＡＳＥ６４にすると　改行されてしまうのは　悪しと見るか、
コーナーケースに合わせるとキリがないので　これで良しと見るか」

「　１０００枚もタイルが含まれる　タイル・セット画像を　利用するやつ、
そんなとこ　気にするでもなく　ハードワーカーだろ」

「　９９９枚もタイルが含まれない　タイル・セット画像を　利用する人にとっては、
無駄なスペースが　空いていることの方が　きにするでしょう」

「　あっ、Ｉｄ　をマウスで選択できね。気になるな……。
選択可能なテキストで、かつ入力ができない　リード・オンリーな設定できるかな……？」

「　👆　でけた。
フォント・サイズは　きっかり　スタイルで決まっているようで　任意サイズにはできなかったので
Entry 要素を広げたぜ」

「　ラベルの　Ｉｄ と コメント の間に　パディング　入れられないの？」

「　👆　入れれるぜ」

「　良くなった。ラベルの文字は　隣のセルと　くっつかないようにしましょう」

「　👆　Ｉｄ だけだと　オーラル・コミュニケーションで困るだろうから
タイルＩｄ と書いといてやろう」

「　そのＩｄって、　ひだり、うえ、よこ、たて　から一意に決まらないの？」

「　例えば　128,32,96,32　を　ＢＡＳＥ６４に変換擦ると　MTI4LDMyLDk2LDMy　だぜ。
これだったら　ベクターを２つ　覚えておいた方がマシかも」

「　情報で構成されている　Ｉｄ　なんて、イケてないぜ。それは暗号だぜ」

「　あくまで　表示に　ＢＡＳＥ６４　を使っているだけで、内部的には　整数なんで」

「　このタイルＩｄは、プロジェクトの中で一意なの？
それとも　タイル・セット画像ファイルの中で一意なの？」

「　凝り出すと　ＵＵＩＤ　に行きついてしまう。
タイル・セット画像ファイルの中での　ローカルなＩｄだぜ」

「　じゃあ　タイルＩｄには　タイル・セット画像ファイルのＩｄも　表示しないと
本当のタイルＩｄにはならないんじゃない？」

「　タイル・セット画像ファイルに　Ｉｄを振ることが難しい。
プロジェクトの中での　ローカルなＩｄなら　振れるだろうけど、
そのＩｄは　別のプロジェクトへ使い回せない」

「　プロジェクトに　ＵＵＩＤ　振ればいいんじゃないの？」

「　ブランチして　開発が平行したら　ノー・コントロール　になってしまう」

「　じゃあ　なんで　タイルＩｄ　なんか採番するんだぜ？
ファイル名、ひだり、うえ、よこ、たて　が本当のＩｄなんじゃないのかだぜ？」

「　あるファイル内の中だけで使える、
ひだり、うえ、よこ、たて　の情報を　３桁程度の整数に集約するのが　タイルＩｄ　だぜ」

「　その情報を　ユーザーに提示する理由は？」

「　タイル１、 タイル２ のような タイル名 を　ユーザーに入力させないこと、
1、 2 のような連番を　ユーザーに入力させないこと、
これらの代替が　タイルＩｄ　だぜ」

「　意義はあるんだ」

「　しかし　それは　Ｉｄ　の働きを持っていないのでは？
何かと言えば　コード　なのでは？」

「　内部的には　Ｉｄ　なんだが、表示上は　コード　だな。
じゃあ　オーラル・コミュニケーションを考えて　ラベルを変えるかだぜ」

「　👆　確かに　タイル・コード　にすると　しっくりしたな」

「　しかし　そもそも　ＢＡＳＥ６４　は、　オーラル・コミュニケーション　には向いていないのでは？」

「　諫言だぜ」

「　じゃあ　ＢＡＳＥ６４の　６４文字に対して　Apple とか、 Banana とか
プロナウンサブル（Pronounceable；発音可能）な単語を当てたらどう？」

「　インターナショナル（International；国際的）に通用するフォニックス（Phonics；発音）ってある？」

「　軍事か通信、航空あたりを調べれば　何か規格があるのでは？」

「　調べるか～」

「　👇　ナトー　のがあったぜ」

📖 NATOフォネティックコード

「　はっきり　西側に寄り添うの　わらう」

「　大文字と小文字は　区別しないのか～」

「　英語のフォネティックコードが人名なんで、大文字にかこつけて　大文字は英語にしたらいいんじゃないの？」

「　じゃあそれで。作ってみるか～」

「　大文字も　小文字も　X-ray　になるんだが」

「　違う所から　持ってきなさい」

BASE64  英単語       読み
------  ---------   -------
A   Alice       アリス
B   Boart       ボート
C   Castle      キャッスル
D   Drink       ドリンク
E   Elf         エルフ
F   Forest      フォレスト
G   Gold        ゴールド
H   Hotel       ホテル
I   Island      アイランド
J   John        ジョン
K   King        キング
L   Level       レベル
M   Madam       マダム
N   News        ニュース
O   Ork         オーク
P   Pond        ポンド
Q   Queen       クイーン
R   Room        ルーム
S   Soup        スープ
T   Talk        トーク
U   Uncle       アンクル
V   Video       ビデオ
W   Wolf        ウルフ
X   Xmas        クリスマス
Y   Yogurt      ヨーグルト
Z   Zebra       ゼブラ
a   and         アンド
b   big         ビッグ
c   clean       クリーン
d   damage      ダメージ
e   evil        イーブル
f   fake        フェイク
g   get         ゲット
h   hit         ヒット
i   ice         アイス
j   jump        ジャンプ
k   kick        キック
l   love        ラブ
m   magic       マジック
n   no          ノー
o   oily        オイリー
p   poison      ポイズン
q   quiz        クイズ
r   rain        レイン
s   solty       ソルティー
t   trendy      トレンディー
u   up          アップ
v   victory     ビクトリー
w   wind        ウィンド
x   xrated      エックスレーテド
y   your        ユワ
z   zenith      ゼニス
0   0           （数字）
1   1           （数字）
2   2           （数字）
3   3           （数字）
4   4           （数字）
5   5           （数字）
6   6           （数字）
7   7           （数字）
8   8           （数字）
9   9           （数字）
+   +           （プラス）
/   /           （スラッシュ）
=   =           （イコール）

「　👆　ゲームに出てきそうな　短い英単語を　持ってきたぜ」

「　趣向を変えたんだな」

「　単語の先頭だけ切り取れば　BASE64　に戻るぜ」

「　動かしてみましょう」

「　Madam get = = になるぜ」

「　BASE64 より　さらに　６倍近く　長くならない？」

「　なりそう」

「　Ｉｄ　１０００　で試しなさい」

「　👆　今の３倍ぐらいの長さにすれば　入りそう」

「　ユーザーは　何だこれは？　と思わないだろうか？」

「　思う」

「　あと、 BASE64 は、文字列連結しないのであれば　桁のプレースホルダーの = は省いていいそうよ」

「　ちょっと考えるぜ」

「　👆　欄外に書いたぜ」

「　ぜったい　なんのこっちゃ　なんだよなあ」

「　それがタイルの名前としての働きを持つと　認識できないのよね」

「　名前という文化は廃止だぜ」

「　ディーエックス」

「　👆　どうしても　名前を書きたいやつは　コメント欄に書け、と親切に　書いておくぜ」

「　（任意） も付けておいた方がよくない？」

「　任意 の意味が分からん人も　いるそうだぜ」

「　あんまり　書きすぎると　デザインの敗北……」

📅 2023-07-08 タイルを選択したら、照会しろだぜ

「　タイル・パレット上で　範囲選択したら、
そのタイルは　すでに登録済みか、まだ登録されていないか、判定しろだぜ」

「　わかったぜ」

（カタ　カタ　カタ　カタ）

「　前のトリック・コードは　奇数回実行すると働くが、偶数回実行すると働かないというバグを踏んだので
対応中」

「　トリックなんかに頼るからよ」

「　👆　登録したタイルの情報を　読み込むようにしたが、
全体的に動きが　怪しいので　調整中だぜ」

「　👆　タイル・コードと　コメントの入出力は　動きが付いたぜ」

「　もう寝ろ」

📅 （2023-07-09 sun）タイルが登録されているとき、ボタンのラベルを追加から上書へ変更してくれだぜ

「　日曜日は　昼まで寝た」

「　タイルが登録されているとき、ボタンのラベルを追加から上書へ変更してくれだぜ」

「　分かったぜ」

「　👆　タイルが登録されているときは、ボタンのラベルを 上書 に変えるようにしたぜ」

国際化

「　その 上書 を、 Overwrite にしても　ボタンの中に収まるの？」

「　多言語化か……。試してみるぜ」

「　👆　収まらないぜ」

「　じゃあ　このアプリは　国際化に耐えられないわよ」

「　横幅が長い……。　海外人、どんな　ＵＩ　使ってるんだぜ？」

「　日本人が　ビューにたくさん項目を詰めるの　こだわるの、
チャイニーズ・キャラクター文化だからなのかな？」

「　欧米の　アイコン　が、漢字相当なんじゃない？」

「　じゃあ、アイコンか　漢字かを選べるようにしたらいいのか……？」

「　👇　ガイドラインを読めだぜ」

📖 Microsoft　＞　Visual Studio のイメージとアイコン

「　👆　欲しいアイコンが無いし、似たようなアイコンばっかり　いっぱいある」

「　👆　ペンが無難だと思う」

「　👆　しかし　MAUI　にも最初から　ちょびっとだけ　リソースが入ってるな」

「　MAUI 用のリソース集も　どっかで配られてんじゃないの？」

「　👇　フォントでやるのが　いいのか～？」

📖 .NET MAUI アプリアイコンを変更する

📖 .NET MAUIで、Emoji(絵文字)やIcon(アイコン)を打とう

📖 Segoe Fluent Icons font

📖 Google Fonts　＞　Material Symbols And Icons

「　👇　ボタンに　アイコン・フォントを表示させるのは　どうやるんだぜ？　画像の方法はあるが」

📖 [.NET MAUI][Button] ボタンにイメージを表示する

「　👇　画像も　文字も　アイコン・フォントも　方法を統一してくれたらいいのに……」

📖 Font Icons in Shell Tabs not showing

「　👆　あれっ？　文字化けだ。 Windows 11 には Segoe Fluent Icons フォントは最初から入ってると　読んだが……」

「　お父んのＰＣ、 Windows 10」

「　マルチ・デバイスのプログラミングが　ホストＯＳに依存したら　悪いんじゃない？」

「　👇　どこから Segoe Fluent Icons フォントを入手するんだぜ？」

📖 Microsoft　＞　fluentui-system-icons

「　👇　情報ではなく、フォントが欲しい」

📖 Microsoft　＞　Segoe UI font family

「　👇　ずっと前から　シーゴーは　Windows に入っているみたいだけど」

📖 Wikipedia　＞　Segoe

「　👇　シーゴーは　日本語フォントではない、という話しもあるわね」

📖 Segoe UIフォントは日本語フォントなのか

「　日本語の設定のまま　シーゴー　を使えないのかだぜ？」

「　👆　フォントのような不確定要素を使うのは諦め、ビジュアル・スタジオ２０２２イメージ・ライブラリーから
ザムルを取ってくることにするぜ」

📖 Microsoft　＞　リソースディクショナリのマージ

「　👆　リソース・ディクショナリーとして　マージすれば　使えるか？」

「　👆　リソース・ディクショナリーの書き方を忘れたので　調べるぜ」

「　👆　あのＸＭＬタグに挟めばいいのか」

「　👆　ビジュアル・スタジオ２０２２イメージ・ライブラリーの　Edit.xaml　の Viewbox を、貼り付けるぜ」

「　そういう手間が要るんだな」

「　👆　ダメだ　仕様が旧い」

「　SVG形式にしたらいいんじゃないの？」

「　👇　SVG は、画像じゃなくて　アイコン扱いなのか？」

📖 I can't set a .svg file as a maui app icon

「　📂 Resources/Images フォルダーは　何か特別な管理下にあるみたいで　ふつうのフォルダーのようには扱えなさそうだぜ」

「　MAUI は、ファイル・パスという概念を　無くしたいのでは？」

「　スマホ・デバイスへの対応のために？」

「　👆　MAUI の最初に出てきた　ロボット、あいつ　SVG画像らしい。
あいつは　表示されて、
ペンを　ボタンの上に表示できないの、何故だぜ？」

「　👆　なんで　ペン　がでかい？
そして　SVG　なのにラスタライズされてる？」

「　👆　さらに　なぜ　.svg　ではなく　.png　にしないと画像が出てこない？」

「　自動で　ラスタライズ　されているのでは？」

「　👆　フォルダーを切って　その中に入れると、パスでアクセスできなくなるのは　何故だぜ？」

「　👇　これを読めだぜ」

📖 Add images to a .NET MAUI app project

「　Android アプリがこうしてるから、 MAUI もこうしてる、というような　腰抜けの話しが　書かれているぜ。
クソじゃないか」

「　なんで Android アプリに迎合するのかしら？」

「　Microsoft が腰抜けだからだろ」

「　👇　これを読めだぜ」

📖 Images in subfolders not showing up on Windows but do on Android #8628

「　👆　なんか　こういうタグをどこかに書くと　そのフォルダーがプロジェクトに認識されるらしいぜ」

「　それは　どこに書くんだぜ？」

「　ファイルを開けまくって　消去法をしている途中で　2D RPG Negiramen.csproj　に　それっぽいコードを発見したぜ」

「　書き足してみましょう！」

「　👆　\*　を、　\**\*　に変えると、
直下フォルダーの任意のファイルではなく、
サブフォルダ―も下りて行って任意のファイルを　見てくれるようだぜ」

「　👆　また、 Android に迎合して、ディレクトリー名、ファイル名に　大文字や空白は使えず、
小文字英字、ハイフン、数字だけを使うようにするぜ」

「　👆　そして　ディレクトリーは無視されるという　クソ仕様により、
ファイル名だけで指定することになるぜ。拡張子は、ファイル名に .png と付いていても XAML には .png と指定するクソ仕様」

「　MAUI は、プラットフォームごとに　異なる画像ファイル形式で用意されても、
XAML には .png と書こうという　MAUI の開発者の頭が残念なことに　なってるのね～」

「　ラスター画像と　ベクター画像の特性の違いも理解できないぐらい　知能が下がってるのかだぜ？」

「　👆　ファイル名が被りたくないので　プレフィックス（Prefix；接頭辞）を付けるぜ」

「　インフラの出来が悪いと　要らんテクニックが使われてしまうな」

「　フォルダー下に、別の命名システムを持ったフォルダーを　ぶらさげたいこともあるのに、
それが考慮されていないのは
MAUI の開発者が　開発の現場経験が未熟だろうから　全員クビになっても　不思議ではないわねえ」

「　👆　SVG形式画像を PNG形式画像に変換した後のものが　ボタンの上に描かれるから、
テキスト・カラーを　白　にしても　白くならないぜ！」

「　当然だな」

「　MAUI　お前　コンピューター・グラフィックスという　自覚　無いのかだぜ？」

「　MAUI の開発者も　いずれ全員　クビになるでしょう」

「　👇　代替策を探さな」

📖 Specify the color of a SVG image in .NET Maui

「　👆　TintColor も効果なし」

「　MAUI の出来が悪いんじゃないの？　あんまり　期待できないんだから
トリックを使っていくことに　なるんじゃない？」

「　じゃあ　ツールチップ・ヒント　の使い方を調べるか」

「　👆　ボタンは　横に広く使うように　妥協。
ツールチップ・ヒントも　組み合わせたので、
国際化は　少々横長のボタンと　ツールチップ・ヒントで　なんとかしてくれだぜ」

「　タイル名、または　コメントを自由入力　というメッセージが　ダサいから　タイル名　だけでよくない？」

「　👆　すっきりさせたぜ」

多言語化

「　英語版、日本語版と　どうやって切り替えるんだぜ？」

「　調べるか……」

📖 .NET MAUI : Write multilingual apps easily

「　👆　Xamarine　の方法がそのまま使えるらしいが、それでいいのか　もっと調べるか……」

「　👇　昔の Windows のやり方も　冴えてないしなあ」

📖 How to implement .NET MAUI localization

「　👇　この動画の人　センス有るな　調べてみるか」

📺 Localization in .NET MAUI - Adding Multi-Language to Your Apps

「　👇　サンプルまで　用意されてる」

📖 .NET MAUI Localization Sample

「　👆　サンプルは動くが、どうやって　📂 Languages フォルダーを作ったのか
手順が分からんな」

「　👇　ResXManager は　多言語化の鉄板ソフトなんで　インストールしておこうぜ」

📖 ResXManager

「　しかし　ResXManager　の画面は　どこから出すんだぜ？」

「　👆　このリンク　クリックしたら　何か出てくるかな？」

「　👆　昔ながらの場所に作られたが、そこじゃなくて
📂 Resources/Languages フォルダ―の下に置いてほしいんだぜ」

「　👆　サンプル見ると、単に　ファイルを移動しただけに見えるな……
やってみるか」

「　👆　自動で　ネームスペースも調整してくれるのかな？」

「　👆　ファイル名も Resources から AppResources に変えたろ」

「　👆　LocalizationResourceManager クラスを真似して　自分用に設定」

「　👆　アプリケーション起動直後に　文化を日本に設定。
わたしが日本語しか確認しないから　日本がデフォルトでいいだろ」

「　👆　TranslateExtension も真似て作り、自分に合わせて編集」

「　👆　ビューのコード・ビハインド、つまり ContentPage の継承クラスには
ローカライゼーション資源管理へのアクセッサ―を書いておくぜ」

「　👆　とりあえず　AppResources.resx へ、　１件だけ　文字列リソースを　記入するぜ」

「　👆　MainPage.xaml に xmlns:app="～" を追加し、
Text プロパティへ {app:Translate LayoutTheScreen} と書いてみるぜ」

「　👆　実行すると、文字列リソースが　使われているな」

「　カルチャーを変更するドロップダウン・リストみたいなものが欲しいわねえ」

外国語を入力してくれだぜ

「　試しに　英語と　中国語のリソースも　作ってみてくれだぜ」

「　👆　ResXManager がインストール済みなのは確認できるんだが、
どこから実行するんだぜ？」

「　👆　あっ、いた！」

「　👆　ここまでくると　あとは　わかる」

「　👆　ニュートラル・リソース・ランゲージを　英語から　日本語へ　変えるぜ。
理由は　開発者が　わたし１人だから」

「　悲しい話しだぜ」

「　👆　言語を追加するボタンがあるぜ」

「　👆　とりあえず　イーエヌ・ユーエス（en-US；英語（米国））は　必須だろ」

「　👆　とりあえず　３つも足しておけば十分だろ」

「　アジアに寄ってんな」

「　👆　ばばばっと　翻訳して　空いてるとこ　埋めてくれる機能があるから
使おうぜ？」

「　👆　なぜか　英語しか　対応してくれなかった。　寄付が足りないとか？」

「　👆　AppResources.en-US.resx ファイルが増えてるぜ」

「　👆　ＩＳＯ言語コードを変えると」

「　👆　翻訳が完了だぜ」

「　📂 Languages フォルダーの中をサーチして、翻訳できる言語を調べて
言語を選べるリスト・ボックスが欲しいわねえ」

「　そのフォルダーに　アクセスする方法が　見当つかないんだが」

「　👆　実行環境を見にいってしまうので、開発環境のプロジェクト・フォルダーの中とか見れないのでは？」

「　👇　じゃあ　ビルド前のイベント　を書いたらいいんじゃない？」

📖 Pre build Events in Visual Studio

「　そこで　ベッタリ　Windows　依存しそうだしな」

「　じゃあ　ＩＳＯ言語コードは　ハード・コーディングかな」

「　国旗って　フリー素材であるの？」

「　👇　同じ問題に突き当たっている人がいるぜ」

📖 Is there a way to get a flag image from a C# CultureInfo?

「　👇　WPF で作った人はいるみたいだな」

📖 famfamfam-flags-wpf

「　こういう　センシティブな素材は　デジタル庁　が作って欲しいものだぜ」

「　国旗は後回しにし、ＩＳＯ言語コードのドロップダウン・リストを
ハードコーディングする方向で　次回　考えようぜ？」

📅 （2023-07-10 mon）日本語か、英語かを選べるドロップダウン・リストボックスを置いてくれだぜ

「　日本語か、英語かを選べるドロップダウン・リストボックスを置いてくれだぜ」

「　まず　MAUI　に　ドロップダウン・リストボックスがあるのかどうかも　分からないしな。
調べないとな」

「　👇　マイクロソフトの記事、映像がなくて　どんな画面が出てくるのか　分からん」

📖 Microsoft　＞　Picker

「　👇　ユーチューブで探せばいいのよ」

📺 How To Create Custom Picker Control (Dropdown Button) In .NET MAUI

「　👇　作ってみるのが早いか」

📖 ピッカー

「　👆　こう書けば」

「　👆　ドロップダウン・リストボックスが出てきて……」

「　👆　選べるぜ」

「　それが欲しかったのよ」

「　初期状態で　ja-JP　を選んでおいてくれだぜ」

「　👆　ピッカーに　最初に選択されている値を表示することは　できないぜ」

「　じゃあ、値が最初に選択されていることを　ピッカーでどう表現するんだぜ？」

「　マイクロソフトの社員の知能が欠如していて　それはできないぜ」

「　👇　初期値を表示するのって　HTML の Select タグの Option 要素の Selected 属性でも指定できるのに、
MAUI で　何でできないの？」

📖 HTML selected Attribute

「　マイクロソフトの社員が欠陥だからだぜ」

「　マイクロソフトの社員が欠陥だというところまでは　事実と認めましょう。
それは置いておいて　わたしたちは　ピッカーに初期値を表示したいのよ。どうしたらいいのよ？」

「　ピッカーを使ってはいけないのでは？」

「　👆　ContentPage 要素に Loaded 属性を追加して……」

「　👆　コード・ビハインドで picker.SelectedItem = "ja-JP"; とでも書いておけば……」

「　👆　ページの表示完了時には　ピッカーで　ja-JP　が選択されている、という状態にできるぜ」

「　XAML だけでは　モックアップも作れないんだな」

「　MVVM に対応できんの？」

「　トップページは　MVVM　にまだ対応してないんで、これから対応させるぜ」

（カタ　カタ　カタ　カタ）

「　あの　１．５日　ぐらい　工数かかったやつ」

「　でけた。　さっきのイベントハンドラも　コード・ビハインドも要らんかった。
MVVM　だけでいけるぜ」

「　マイクロソフトの社員は欠陥じゃなかったんだな」

「　まだ　首の皮一枚つながったぐらいだな」

📅 （2023-07-10 mon）タイル・パレット編集画面も多言語化しなさいよ

「　タイル・パレット編集画面も多言語化しなさいよ」

「　あとから　多言語化しようとして　レイアウトの変更が必要になったりしたら　大変だしな」

ramen-tabero-futsu2.png
「　👆　この　アイテム・リソースも　ハード・コーディングじゃなくて
どこかのファイルにまとめて、一元化したいんだが」

「　App.xaml に　リソース・ディクショナリーを作って、それを読み込んだらどうだぜ？」

「　👇　テンプレートは　リソースにできるが、　データは　リソースにできないんじゃないか？」

📖 データテンプレート
📖 リソースディクショナリ

「　ItemSource の使い方が分からん。調べても出てこないぜ」

「　この前の多言語化のときの　おっさんの　You Tube　に　なんか　まとまってんじゃないの？」

「　👇　このおっさんは　MAUI を作ったチームの中の人らしいぜ」

📺 Gerald Versluis

「　じゃあ　その動画を　しばらく視聴する！」

📅 （2023-07-11 tue）寝てた

Zzz

📅 （2023-07-12 wed）動画観るか～

「　動画　観るか～」

📅 （2023-07-13 thu）分かんね

「　👇　英語で　何言ってるか　分かんないんだが」

📺 Monkey クラス作成

「　猿を１匹記録するクラスを作るんだけど、例が JSON なのよ」

「　じゃあ　真似して　言語を１つ記録するクラスを作るかだぜ」

Name,
ja-JP,
en-US,

「　👆　📂 Releases/Raw フォルダーの中に 📄 languages.csv ファイルを作ろうぜ？」

「　その１行に対応する Language クラスを 📂 Models フォルダーの下に作りましょう」

「　なんか無駄臭いクラスだな……」

「　👆　プロパティ１個　置いとけばいいのかだぜ？」

「　C# に、 CSV をシリアライズする仕組みなんか　あるのかだぜ？」

「　👇　人気があるのは　これかしらねえ？」

📖 CsvHelper

「　使い方を覚えるか……」

「　👆　NuGET でインストール」

「　Resources/Raw フォルダーの中にあるファイルって　どうやって読取るんだぜ？」

「　👇　調べろだぜ」

📖 Microsoft　＞　Bundled Files
📖 Get Resources\Raw Path in .NET Maui

「　👆　None とか Remove って何だぜ？　無いことになってんの？」

「　👆　ビルド・アクションを何か変えたらいいのかだぜ？」

「　👇　ビルド・アクションの説明はこれだが」

📖 Build actions

「　CSVファイルは　どう配置すりゃいいんだぜ？」

「　👆　出力ディレクトリーにコピー　を　新しい場合はコピーする　に変えたら、何が起こるんだぜ？」

「　👆　なんで２つあるんだ？」

「　コピーをしなければ bin フォルダーの下に languages.csv はなく、コピーすると２つある」

「　Visual Studio のコンフィグ・ファイルは無いの？
インストール時に　作業ディレクトリーを設定できなければ、
設定ファイルの置き場所も　定まらなくない？」

「　アプリケーション・フォルダーに置いてくれないのかだぜ？」

ItemSource 分からん

「　じゃあ　いったん、言語のリストは　ハード・コーディングするものとしようぜ？」

「　ItemSource って　何を設定できるの？」

「　恐らく、ビューモデルの　変更通知プロパティじゃないか？」

「　👆　変更通知プロパティを　ふつうに作って」

「　👆　ItemSource に　バインドすれば　うまくいくぜ」

「　どのページにも　言語ピッカー　を置きたいときは、
どのページにも　LanguageCollection　変更通知プロパティーを作ることになるの？」

「　そうじゃないか？」

「　👆　ロケールＩｄのリストなんか　途中で変わらないだろ。
セッターのないプロパティとして、グローバル変数のように利用できるように App クラスに定義しようぜ？」

「　👆　変更できない変更通知プロパティなら、グローバル変数を取得してても　不整合は起こらないだろ」

「　これを　ビューモデルに置きまくるのか」

配色変更

「　👆　テキストボックスの白が目立つように　配色を変更し、
ロケールＩｄのピッカーを　右上に置いたぜ」

「　色を使いすぎてんじゃないの？　青だけでも３色もある」

「　タイトルバーの色を　減らしてみるか……」

「　MAUI のスタイルシート的なものは　どこにあんの？」

「　👆　📂 Resources/Styles フォルダーの下にあるぜ」

「　👆　色の主張を　抑えたぜ」

「　テキストボックスの白と黒も　きつい　気がするのよね」

「　👆　ダーク・モードのことを考えずに　いじってしまった。
どこか　壊してしまったかも知れないが　分からない。
勘弁しろだぜ」

「　👆　トップページの配色も　白が無くなるように　ゲインズボロ　という色をベースに敷いたが
ダークモードにしたら　どうなるのか　知らん」

「　もう寝ろ」

📅 （2023-07-14 fri）登録済みタイルがどれか分かるようにしてくれだぜ

「　登録済みタイルがどれか分かるようにしてくれだぜ。　例えば……」

「　👆　こんなふうに」

「　タイルは　重なって登録されることは　あるのかだぜ？　例えば……」

「　👆　上図　４～９」

「　あるある。　タイル・セットは　それ自体が　パレットのような配置をしているのよ」

「　タイル・セットと　パレットは　意義を分けたいな……」

「　👆　ロジカルには　こうなるはず」

「　上図の　７　を範囲選択するの　難しくない？」

「　ゲリマンダー（Gerrymander）みたいな形や、飛び地が必要かどうかも　洗い出したいぜ」

「　ひとまず　矩形だけでいいのではないか？」

「　じゃあ　被りは有りで　話しを進めるかだぜ」

「　👆　なんか　ファイルにいっぱい保存されているぜ」

「　同じ矩形を　何個も登録してるわねえ」

「　ファイルのバリデーターを作るべきだが、とりあえず　手作業で直せだぜ」

「　👆　Excel で　CSVファイルを開いたら　文字化けしてるんだが……」

「　BOM付きの UTF-8 じゃないと Shift-JIS と判定されてるわよ」

「　👆　BOM 付きの UTF-8 にしたら　文字化けが直った！」

「　👆　こういう感じのデータを、エディター上で　どう表示するかだよな」

IDrawableインターフェース実装クラスの Draw関数にビューモデルからどうやって値を渡すんだぜ？

「　👆　IDrawableインターフェース実装クラスの Draw関数にビューモデルからどうやって値を渡すんだぜ？」

「　👇　これを読めだぜ」

📖 In .NET MAUI, how do I pass variables to a GraphicsView.Drawable in a ContentView
📖 How to pass variable data into .NET MAUI GraphicsView canvas

「　👆　なんだか分からないが　束縛可能プロパティ　の書き方のパターンを　なぞろうぜ」

「　👆　さっきの IDrawing 実装クラスは、リソースとして　ContentPage　に読み込まれて……」

「　👆　GraphicsView 要素で使われているな」

「　👆　それを　いったん、こう書きかえるぜ」

「　これでいいなら　ビュー・モデルの変更通知プロパティを、
IDrawable クラスの束縛可能プロパティに　渡すことができそうねえ」

「　👆　ビュー・モデルに　変更通知プロパティを書いて……」

「　👆　ビューで　変更通知プロパティを束縛」

「　👆　IDrawing 実装クラスは　束縛可能プロパティに値が入ってくるんで
グローバル変数を１つ　取り除くことに成功だぜ」

「　IDrawing 実装クラスから　グローバル変数を取り除いていきましょう！」

「　つら……」

（カタ　カタ　カタ　カタ）

「　ヌル参照例外が出て　動かなくなった　つら……」

「　さらに　まずいことに　線の太さが　０　になり、
for 文で　横に　０　移動しながら　縦線を引く　無限ループに陥った……」

「　束縛プロパティの初期化が始まる前に　Draw　メソッドが呼び出されているのでは？」

「　どっちが頭で　どっちが尻尾問題で、
IDrawable 実装クラスのプロパティが、ビュー・モデルのプロパティーを上書きしてくることはないだろうか？」

「　Way　を指定したらいいんじゃないの？」

「　👆　そもそも　変更通知が届いてないぜ」

「　グローバル変数が　いつ変更されたとか、ビューモデルには　分からないからな」

「　グローバル変数を　使わないようにしたが、束縛プロパティが　渡せていないぜ」

束縛プロパティを練習しようぜ？

「　👇　GraphicsView の Drawable クラスの Draw 変数へ、プロパティを渡すだけのサンプル・プログラムを組んでみようぜ？」

📖 Git Hub　＞　Muzudho　＞　MAUI-BindableProperty-Practice

「　👆　しばらく　練習するぜ」

「　👆　Binding したら　動かないぜ」

「　Bindable なプロパティなのに Binding したら動かないなんてことが　あるのかしら？」

「　👇　よく読んでくれだぜ」

📖 Bindable properties

「　👆　確かに　変更前と、変更後の値を取れて　気が利くが、
そういうの　自動でやってくれるわけじゃないのかだぜ？」

「　いや、取れてないぜ。 Binding したものは　取れてない」

「　👇　もっと調べろだぜ」

📖 Binding not working on custom BindableProperty

「　GraphicsView はビュー・モデルを持ってないから Simple30 を Binding しようとしても持ってないんで、
親コンポーネントのビュー・モデルを指せ、ということらしい」

「　どうやって」

「　👇　もっと調べろだぜ」

📖 .NET Maui Binding a contentview to parent ViewModel MVVM
📖 ContentView

「　ContentPage 使ってるのに、 ContentView の説明されても　利用できないぜ」

（カタ　カタ　カタ　カタ）

「　よし、分かった！」

「　👆　ビューの　コード・ビハインドに、
バインディング・コンテキストを公開する　パブリック・メソッドを書くぜ」

「　そんなことをしていいのかだぜ？」

「　ＭＶＶＭが　崩壊したんじゃないの？」

「　👆　ビューの　ContentPage　要素に、 x:Name 属性を付けて、その値を thisContentPage とでもしておくぜ」

「　👆　これで　MainPageVM　プロパティが公開されてるんで、そのメンバーにアクセスできるぜ」

「　この記事の　２回目の　トリック・コードだな」

「　👆　ViewModel はこんな感じ」

「　👆　線も引けてるぜ」

「　バインディング・コンテキストを公開しているのが　気になるなあ」

「　👆　グローバル変数を減らし、 BindableProperty　を使って　GraphicsCanvas の Drawable 属性のクラスの
Draw メソッドに　プロパティ値を渡すことに成功したぜ」

「　ViewModel を public にするのは心理的抵抗がある。
公開するのは　interface　にして、プロパティだけ公開しろだぜ」

「　かしこいな」

📅 （2023-07-15 sat）タイル・セット上を矩形で塗りつぶしてくれだぜ

「　タイル・セット上を矩形で塗りつぶしてくれだぜ」

「　キャンバスで描画するのか、画像オブジェクトでピクセルを直接描画するのがいいのか」

「　インプレース（In-place）で　クロップ（Crop）と　コピー（Copy）を１ステップでできないと
実行速度が遅くなるんじゃないの？」

「　画像は　Microsoft.Maui.Graphics.IImage　というインターフェースに抽象化されていて、
とても　高速に画像を描画することを指向しておらず、
マルチ・プラットフォームで一番性能の低いマシンで動くように考慮されてる護送船団方式の雰囲気を感じるぜ」

「　性能　上げたけりゃ　MAUI　なんか使うなだぜ」

「　ぐぬぬぬぬ！」

「　この　IImage　インスタンスは　あくまで　画像ファイルを指さしているだけで、
描画をするときは　GraphicsCanvas　を使えという思想なのかもしれない」

「　画面の描画前に　画像の前処理を　終わらせておきたいことなんて
いっぱいあると思うのに
キャンバスを用意してから　画像処理しなくちゃいけないのね」

「　画像処理　したけりゃ　MAUI　なんか使うなだぜ」

「　ふむむむむ！」

「　じゃあ　画面上に　キャンバスを２層に重ねて表示することにして、
元画像を下レイヤーに、作業用レイヤーを上レイヤーに置いて
作業用レイヤーに　いろんな加工をしていくことにしようぜ？」

「　キャンバスの練習を先にしておいた方が　いいんじゃない？」

「　👇　リポジトリ―は作っておいたぜ」

📖 GitHub　＞　Muzudho　＞　MAUI-IDrawable-Practice

「　変更通知プロパティを　バインディング　しただけでは
Draw は呼び出されないのか」

「　GraphicsView に Draw メソッドの呼び出しを要求するの、どうやればいい？」

「　👇　読めだぜ」

📖 GraphicsView

「　👆　GraphicsView 要素に x:Name 属性を使って名前を付けて……」

「　👆　コード・ビハインドで　GraphicsView 要素の　Invalidate( )　メソッドを呼び出せば　いいわけかだぜ」

「　ビューモデルで　Invalidate( )　メソッドは呼び出せないのかだぜ？」

「　画面の更新は　ビューモデルの仕事では　無いのでは」

「　👆　よっしゃ　２Ｄ描画にも　慣れてきたぜ」

１つのキャンバスで何でも描画するのと、複数のキャンバスに分けるの、どっちが得？

「　お父んは　タイル・カーソルと　グリッドと　タイル・セット画像を　分けて　置いているが、
そのようにするのと、１つのキャンバスの上に全部描くのとでは、どっちが得なんだぜ？」

「　何も考えなければ　１つのキャンバスの上に全部描くのが　お得だぜ」

「　グリッドを分けた理由は？」

「　グリッドは　ヴィジブル（Visible；可視性）を　オン・オフ　したいときがあるだろ。
フラグ１個だけで　できるというメリットを生かしたい」

「　ライフ・サイクルに似た考え方か」

「　じゃあ　カラード・マップ（Colored Map）のキャンバスも　１つ用意したいわねえ」

Draw が呼び出されるのが Loaded より早い

「　GraphicsView の初期設定をする前に Draw が呼び出されているぜ」

「　👇　イベントの呼び出し順序の話しは　書いてないなあ」

📖 グラフィカルオブジェクトを描画する

「　あっ、違うぜ」

「　束縛プロパティの　返り値の型の指定を　間違えていた」

「　設定ミスは　エラー・メッセージを出してくれないからなあ」

「　👆　薄いグレーを被せてみたが、
どうやっても　視認性が悪くならないか？」

「　もとの画像の　明度を下げてみたら？」

「　👇　明度を下げるとか　上げるとか　説明無いぜ？」

📖 Microsoft　＞　Image

「　ピクセルに　アクセスする手段　無いの？」

「　👇　スキア・シャープ（Skia Sharp）というものが　あるそうだぜ？」

📖 .Net Maui - Create ImageSource from pixel data

「　何だぜ　それ　まだまだ勉強か……」

SkiaSharp を調べようぜ？

「　👇　リポジトリは作っておいたぜ、勉強しろ」

📖 GitHub　＞　Muzudho　＞　MAUI-SkiaSharp-Practice

「　👆　とりあえず　SkiaSharp　をインストールするか」

「　👇　スキア・シャープの使い方の説明が無いぜ」

📖 GitHub　＞　SkiaSharp

「　👇　サンプル・プログラムを直接読めだぜ」

📖 SkiaSharp/samples/Basic/Maui/SkiaSharpSample/MainPage.xaml.cs

「　GraphicsView じゃないんだ」

「　👇　画像処理っぽいことしてるが、学習コストが高そうだ」

📖 Understanding SkiaSharp and Maui Coordinates

「　👇　ここに　ピクセル単位でのアクセスの仕方が書いてあるのでは？」

📖 SkiaSharp ビットマップピクセルビットへのアクセス

「　まあ、午前中に独習してきた GraphicsView は使わないというのは　分かったが……」

「　将来的にやろうとしていることを考えると、　GraphicsView　では限界がくるんじゃない？」

「　👆　SkiaSharp.Views.Maui.Controls　をインストールしてみようぜ？」

「　👆　xml の namespace として
xmlns:skia="clr-namespace:SkiaSharp.Views.Maui.Controls;assembly=SkiaSharp.Views.Maui.Controls"
を書き足すぜ」

「　👆　これで　skia:SKCanvasView　を使えるようになったはずだぜ」

「　使えなかった。エラーが出た」

「　👇　SkiaSharp.Views.Maui.Core　はインストールしてんの？」

📖 SkiaSharp.Views.Maui.Core

「　👆　どれをインストールすりゃいいのか　分からんな」

「　👇　コマンドラインからやってみるか」

📖 SkiaSharp.Views.Maui.Core

dotnet add package SkiaSharp.Views.Maui.Core --version 2.88.3

「　👆　なぜ文字化けする？」

.NET Core の文字化けに対応しろ

「　👇　ダメ元で　試してみるか」

📖 .NET Coreのコンソールで日本語が文字化けする

        // NuGET のパッケージ・マネージャー・コンソールの文字化けに対応を期待したが効果なし
        Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

「　👆　ダメだった」

📖 パッケージマネジャコンソールにおける dotnet コマンド出力の文字化け

dotnet --help

「　👆　ヘルプも文字化けしている」

PM> chcp
現在のコード ページ: 932

「　👆　マイクロソフトの S-JIS ではダメだ」

PM> chcp 65001
Active code page: 65001

「　👆　コードページを　65001　に変えたったが　ダメだ」

マイクロソフトのスキアを入れてみようぜ？

「　👆　方法も無いし、　Microsoft.Maui.Graphics.Skia　でもインストールしてみようぜ？」

「　もう　思考が停止してるの　わらう」

「　インストールしたところで　何も起こらん」

「　思考をしなさい！」

キャンバスではなく、イメージの方を調べようぜ？

「　👇　描画回りは　対応が遅れてるのかも知らん」

📖 .NET MAUIによるクロスプラットフォーム2D描画(その1)

「　👇　MAUI は SkiaSharp をベースに使ってるんだろう」

📖 SkiaCanvas Class

「　👇　キャンバスではなく、イメージの方に　ピクセルにアクセスするメソッドがあるんじゃないの？」

📖 SkiaImage Class

「　👆　イメージは　バイトに分解できるのか」

「　じゃあ　バイトは　イメージに　構成できるのかだぜ？」

「　👇　調べろだぜ」

📖 ByteArrayToImageSourceConverter
📖 MAUI: How to draw image from byte[] on MAUI

「　画像は　バイトに分解できるけど、　バイトは　画像に構成できないのか」

「　👇　じゃあ　バイト配列を　直に　PNG画像として出力すればいいんじゃないの？」

📖 Create a PNG from an array of bytes

「　ファイルの書出しと　読込みたいな　重い処理やるんだったら　なんのための画像処理か　分からんが……」

「　MAUI で画像処理しようとするのが　間違いなのでは？」

アホな記事ばかり

「　👇　公式の記事を　なぞってるだけじゃないか。アマチュアのコピー記事が」

📖 Handling Images With .NET MAUI Graphics

「　真実に対して　怒るなだぜ」

「　明度を下げたいとか、特定の色だけを抽出したいとか、そういう知能はないのかだぜ、記事を書くやつは？
知能だけではない　意志も無い。
インターネット上のアマチュア記事は　公式のダウングレードばかり　情報を増やさない。
筆を折れだぜ」

「　スキアシャープのエラーを取るしかなくない？」

再び SkiaSharp を調べようぜ？

「　👆　とりあえず、NuGET で　正しい　SkiaSharp　をパッケージ単位でダウンロードして
アセンブリを使えるようにするところからだぜ」

「　👆　だから　この　SkiaSharp　パッケージを入れておくだけで　充分なはずなんだが」

「　👆　だから　この　SkiaSharp　に　SkiaSharp.Views　は入ってないようだぜ」

「　👆　SkiaSharp.Views　パッケージもインストールしてみるかだぜ」

「　👆　だから　この　SkiaSharp.Views　には　SkiaSharp.Views.Maui　は入ってないようだぜ」

「　👆　似たような名前のパッケージが並んでいて困るが
とりあえず　SkiaSharp.Views.Maui.Core　パッケージを　インストールしてみるかだぜ」

「　👆　SkiaSharp.Views.Maui.Core　には　SkiaSharp.Views.Maui.Controls　は入ってないようだぜ」

「　👆　じゃあ　SkiaSharp.Views.Maui.Controls　パッケージを　インストールしてみるかだぜ」

「　👆　ビルドは通ったぜ」

「　👆　実行すると　立ち上がる前にエラー」

「　その理由を調べなさいよ」

「　UnhandledException　というのは　ライブラリが　例外が起こっているのにキャッチせずに終了したということだぜ」

「　だから、その理由」

「　カタストロフィック（Catastrophic；大災害的）な　フェイラー（Failure；失敗）だぜ」

「　なんのことだが　分からんな……」

「　👇　同じ不具合に突き当たっている人がいるわよ」

📖 [BUG] MAUI: SKCanvasView crash, unable to display SKBitmap directly #2139

「　👆　どこにも説明が無いが　謎のコードを書き……」

「　👆　実行するとこまでは　イケた」

「　ようやく　画像処理のスタートラインに経ったな」

「　じゃあ　SkiaSharp　のサンプル・プログラムを真似たろ」

（カタ　カタ　カタ　カタ）

「　👆　文字が出た」

「　じゃあ　文字の代わりに　画像を表示してみなさいよ」

SkiaSharp で画像を表示しろだぜ

「　👇　画像の用意の仕方が分からん」

📖 Microsoft　＞　SKImage Class

「　👇　SKBitmap なら、ストリームから作れるんじゃないか？
SKImage は、SKBitmap を読込むメソッドを持っているだろ」

📖 Microsoft　＞　SKBitmap

📖 Microsoft　＞　Decode(Stream)

「　そのサンプル・プログラムが欲しい」

「　👇　Xamarine の利用者は　SkiaSharp　に詳しいらしいぜ」

📖 Bitmap Basics in SkiaSharp

「　知らん世界だ。真似するかあ」

「　👆　おー、描画できたぜ。
基本的にラスター画像は　SKBitmap　で記憶しておいて、
表示するときは　SKBitmap を SKImage でラッピングすればいいわけだぜ」

「　じゃあ　あとは　ラスター画像の容量で　画像処理できるな」

「　もう寝なさい」

📅 （2023-07-16 sun）画像の明度を下げてくれだぜ

「　画像の明度を下げてくれだぜ」

「　愚直に　１ピクセルずつ　変更するコードなら　すぐ書けそうだが、
並列処理に有利な　コードの書き方が　分からんな……」

「　👇　これを読みなさい」

📖 SkiaSharp ビットマップピクセルビットへのアクセス

「　マイクロソフトの記事の　コード・サンプルのリンク　クリックしても
コード・サンプルが置いてないの　何でなんだろな？」

「　実行速度の検証は　iOS、 Android、 UWP で行われていて、 Windows が含まれていないのは何でだぜ？」

「　Windows 上で Windows 向けのプログラム書いたら有利なの明らかだからよ。
UWP というのが Windows なのよ」

「　unsafe 使って uint のポインター型を使うのが　そら早そうだが、
unsafe を使いだしたら C# というより C言語だしな」

「　画像処理の高速化というのは　アンセーフなものでは？」

SKBitmap FillBitmapUintPtrColor(out string description, out int milliseconds)
{
    description = "GetPixels SKColor";
    SKBitmap bitmap = new SKBitmap(256, 256);

    stopwatch.Restart();

    IntPtr pixelsAddr = bitmap.GetPixels();

    unsafe
    {
        for (int rep = 0; rep < REPS; rep++)
        {
            uint* ptr = (uint*)pixelsAddr.ToPointer();

            for (int row = 0; row < 256; row++)
                for (int col = 0; col < 256; col++)
                {
                    *ptr++ = (uint)new SKColor((byte)col, 0, (byte)row);
                }
        }
    }

    milliseconds = (int)stopwatch.ElapsedMilliseconds;
    return bitmap;
}

「　👆　先頭から末尾まで　色を置き換えながら　シーケンスしてるだけだ　やってることは簡単だ
真似るか」

「　👆　じゃあ今後、ネギラーメンでは　アンセーフなものも　使っていくことにするぜ」

「　int 型のメモリ・レイアウトは　red, green, blue, alpha　で確定かだぜ？
環境により異なるかだぜ？」

「　ビッグ・エンディアン、リトル・エンディアンが関わってくるかどうか　知らないぜ？」

ここでのコードでは、バイトが赤、緑、青、アルファの順序であり、色の SKColorType.Rgba8888 種類と一致していることを前提としています。 これは iOS と Android の既定の色の種類ですが、ユニバーサル Windows プラットフォームでは使用されないことを思い出してください。

「　👆　環境によって異なるそうよ」

namespace MauiApp1;

using SkiaSharp;

/// 
///     明度を下げる
/// 
internal static class ReduceBrightness
{
    // - インターナル静的メソッド

    /// 
    ///     そうする
    /// 
    internal static SKBitmap DoItInPlace(SKBitmap bitmapInPlace)
    {
        IntPtr pixelsAddr = bitmapInPlace.GetPixels();
        int width = bitmapInPlace.Width;
        int height = bitmapInPlace.Height;

        unsafe
        {
            uint* ptr = (uint*)pixelsAddr.ToPointer();

            for (int row = 0; row < height; row++)
                for (int col = 0; col < width; col++)
                {
                    // ビッグ・エンディアンか、リトル・エンディアンかの違いを吸収してくれることを期待して
                    SKColor color = new SKColor(*ptr);

                    // RGB値が減れば、暗くなるだろ
                    *ptr++ = (uint)new SKColor(
                        red: (byte)(color.Red * 0.7),
                        green: (byte)(color.Green * 0.7),
                        blue: (byte)(color.Blue * 0.7));
                }
        }

        return bitmapInPlace;
    }
}

「　👆　なるほど、
ビッグ・エンディアンか、リトル・エンディアンか、環境の違いを吸収しようとすると
ちょっと　遅くなるのか、まあいいか」

「　👆　明度を下げることはできたが、再描画のたびに　どんどん暗くなって　真っ黒になる。
コードを書く位置を　ミスった」

タイル・パレット編集画面のタイル・セット画像の明度も下げてくれだぜ

「　タイル・パレット編集画面のタイル・セット画像の明度も下げてくれだぜ」

「　GraphicsView　と、　SKCanvasView　の結局どちらも　用途に応じて使い分けることになるの
学習コストと、脳への負荷が高いな」

「　フォルダーの整理も大変だ。
MAUI のフレームワークに従うものと、
SkiaSharp という異質なものを　どう配置しよう」

「　FeatSkia　みたいなフォルダーを作って
そこに放り込めば？」

「　ミュージシャンみたいだな。
そもそも Skia って何だ？　調べるか」

📖 Wikipedia　＞　Skia

「　👆　元は　会社名らしい」

「　👆　SkiaSharp.Views.Maui.Controls パッケージをインストールすれば、必要なものは　自動的にインストールしてくれるようだぜ」

「　👆　MauiProgram.cs に builder.UseMauiApp().UseSkiaSharp(); って書く必要があるの、
探さないと見つからない　分からんと思う」

「　👆　画像処理は　とりあえずお試しに　FeatSkia フォルダーを作って　そこへ入れよう」

「　👆　ビューに　ネームスペース
xmlns:skia="clr-namespace:SkiaSharp.Views.Maui.Controls;assembly=SkiaSharp.Views.Maui.Controls"
を追加して」

「　👆　SKCanvasView 要素を配置」

「　今回、Touch イベントは要らないんじゃない？」

「　👆　ビューモデルには、 SKBitmap　を格納できるようにしておくぜ」

「　👆　描画処理は、ただビットマップを描画するだけにするぜ」

「　コード・ビハインドに　画像処理をベタ書きするのが、 MVVM の思想では　イケてないんだろうな」

「　👆　ページの読込完了時に、画像読込と、明度を下げるのを　済ませてしまおう」

「　👆　そして実行。　位置とサイズが合ってないな」

「　👆　位置とサイズを調整」

「　明度を下げたタイル・セット画像の上に、
半透明のグレーの画像を置いているけど、
その２枚は　MAUI　によって　どうブレンドされているの？
加算合成なのか、乗算合成なのか」

「　👇　これを読めだぜ」

📖 ブレンドモード

「　半透明のときの説明は無いな」

「　選択領域か、そうでないかが　明確に見分けられなければ　いけなくない？」

「　👆　角丸の矩形でどうだぜ？」

「　暗い場所が残ってると　残差業が残ってるみたいに感じるじゃない。
選択されていないところを　暗くして、選択されているところは　元の色調にしたら　いいんじゃないの？」

「　じゃあ　元画像　は　どこかに残しておかないといけないのかだぜ」

「　カラード・マップ（Colored Map）　は色分けだろ。
色で分けろよ」

「　👆　青が　暗くなってしまうなあ」

「　青値は　多めになるよう　補正を掛けたら？」

登録タイルの削除ボタンを作れだぜ

「　登録タイルが　こんな　ぐちゃぐちゃ　しているのが悪いんだ。　削除できるようにしよう」

「　追加ボタンと　削除ボタンが　こんなに近くにあるのは　悪いデザインでは？」

「　👆　これぐらい　離したらいいかだぜ？」

「　削除ボタンだけ　左に持っていったら？」

「　削除したいときに　不便なのでは……」

ボタンに押した感じを付けれないの？

「　MAUI のボタンって　反応しないから　押した感じがしないけど
ボタンを押したという演出を　付けれないの？」

「　そんなものは　ボタンには最初から付いているものと　思っていたぜ」

「　👇　記事を読めだぜ」

📖 【.NET MAUI】Buttonにアニメーションを付けて表示をカスタマイズする

📖 Microsoft　＞　AnimationBehavior

「　👆　名前空間を書いて」

「　👆　ボタンに　ビヘイビアを書いたが、アニメーションする様子は無いぜ」

「　👆　この書き方で　いけてないのかだぜ？」

「　👆　チェーンにした方がいいのか？」

「　ダメだ　ボタンは　アニメーションしないぜ」

「　👆　XAML をどう書いても　ボタンはアニメーションせず　クソだったので
コード・ビハインドに　コードを書くことにしたら　アニメーションしたぜ」

「　なぜ　XAML　の設定では　アニメーションしなかったのか　謎のままだぜ」

ボタンの上をマウスがホバーしたときに、ボタンの色を変えれないの？

「　ボタンの上をマウスがホバーしたときに、ボタンの色を変えれないの？」

「　👇　ご存じの通り　MAUI　は　マウス操作ではなく　タップ操作を前提とした設計なんで　マウス・ホバーなんて無いぜ」

📖 Mouse hover detection in .NET MAUI

「　デスクトップ・アプリとしての　体験が　悪い……」

「　👇　ジェスチャーでなんとかならないのかだぜ？」

📖 Implement PointerGestureRecognizer #9592

「　ボタン毎に　ジェスチャー付けるの　クソ　めんどくさいが　やってみるかだぜ」

Colors.xaml に定義されている primary という名前の Color インスタンスはどうやって取得できるんだぜ？

「　Colors.xaml に定義されている primary という名前の Color インスタンスはどうやって取得できるんだぜ？」

「　👇　これを読めだぜ」

📖 How to find a resource with key in code behind? [MAUI]

「　いくつかあるディクショナリーのどこかにあるから　探索しろということかだぜ」

namespace _2D_RPG_Negiramen.Models
{
    /// 
    ///     リソース・ヘルパー
    /// 
    internal static class ResourcesHelper
    {
        /// 
        ///     探す
        ///     
        ///     
        ///         TODO ★ 実装をもっと書いてほしい
        ///     
        /// 
        /// リソースのキー
        /// 見つけたもの
        /// 見つかった
        internal static bool TryFind(string key, out object resource)
        {
            if (App.Current==null)
            {
                resource = 0;
                return false;
            }

            // 愚直な探索
            foreach (var resourceDictionary in App.Current.Resources.MergedDictionaries)
            {
                if (resourceDictionary.TryGetValue(key, out resource))
                {
                    return true;
                }
            }

            resource = 0;
            return false;
        }
    }
}

「　👆　じゃあ　これでいいだろ」

「　👆　マウスのホバーで色変えるぐらいのことで　ジェスチャーのコード　書くことになるの　うんざりするが
仕方ない」

「　👆　イベントハンドラは　こんなもんでいいだろ」

「　そういえば　ボタンにマウスカーソルが被さった時の　カーソルの見た目の変更も　やり方が分からないな」

「　👆　マウス・ホバー時の色味を落ち着かせて、　画面の配色のコントラストも落とすように　変更したぜ」

「　ネギラーメンという名前なのに　青が基調でいいのかだぜ？」

「　青は　集中力を高める色という俗説もあるし、　まあいいだろ」

「　👆　マウスカーソルが　ボタンに被さると　ボタンが少し　明るく見えるとか　１個１個　設定しないといけない
これは大変だ」

"Tile Set" ではなくて "Tileset" なのでは

「　Tileset は　１単語として　よく使われているようだぜ」

「　じゃあ　リネームするか～」

「　タイル・パレット編集画面　という名前は　実態に合ってんの？」

「　タイル切り抜き画面だよな」

「　英語にすると　Tile Crop Page　ぐらいかだぜ？」

「　意味が伝わるだろうか？」

「　まだ　タイル・パレット本体も無いし、
タイル・パレット編集　と言われても　分かんなくない？」

「　とりあえず　文字数が減るのは嬉しいから　リネームするか」

TilePaletteEditPage ----> TileCropPage

文字列リソースにはどうやってアクセスすんの？

「　あれっ？　C# スクリプトから　文字列リソースを取得するには　どうやったらいいんだぜ？」

「　LocalizationResourceManager を直で呼び出したらどう？」

var text = (string)LocalizationResourceManager.Instance["Add"];

「　👆　こんな感じで　いけたぜ」

「　👆　ローカライズしたら　　という改行コードが　そのまま表示されてしまった！」

「　インジェクション対策だろう」

「　👆　\n　でも　　でもダメ」

「　しゃーない　いい感じのところで改行するのは　諦めよう」

ウィンドウ・サイズってどうやって設定するんだぜ？

「　MAUI って　デスクトップ上のウィンドウの位置　という概念も無いよな」

「　デスクトップ・アプリではないんで」

「　👇　記事を読みなさい」

📖 .NET MAUI でウインドウサイズを指定する方法(Windowsで実行した場合)

「　そんな　Win32　みたいなコード　書くのかだぜ？」

（カタ　カタ　カタ　カタ）

「　書いた。　うまくいった」

画面遷移から戻ってきたときに呼び出されるイベントハンドラはあるかだぜ？

「　Loaded は最初の１回しか呼び出されないらしい。
画面遷移で　戻ってきたときに呼び出されたいときは　どうすんだぜ？」

「　とりあえず　いろんなイベントハンドラ実行したら　NavigatedTo　が　それっぽいかな」

（カタ　カタ　カタ　カタ）

「　よし、いけた」

「　ブログの編集画面が　なんか重くなってきたので　次の記事へ飛ぶかだぜ」

「　よっしゃ」

📖 次の記事：　2D RPG 制作ツールを作ろうぜ（＾～＾）？＜その2＞

「2D-RPG」の記事 - Crieit

2D RPG 制作ツールを作ろうぜ（＾～＾）？ ＜その2＞

2D RPG 制作ツールを作ろうぜ（＾～＾）？

2D RPG 制作ツールを作ろうぜ（＾～＾）？　＜その2＞