堕天使の煉獄

やっぱり頭の中だけで考えるもの限界～
ってことで、とりあえずＧＵＩ周りで作るべきクラスを
とりあえず羅列してみるテスト。


基本方針:
マウスオンリーでしか操作出来ないものは避けるべし。
ゲームパッドorキーボードでの操作が最低限可能なものとして考える。
なので、常にフォーカスのある単一のコントロールに対してのみ
操作を受け付ける形にするべき。


DxGui　　　　　// モーダルなＧＵＩとモードレスなＧＵＩを登録して実行＆描画
　　　　　　　// シーンクラスはこのクラスをメンバに持つ
　　　　　　　// モーダルなＧＵＩはスタック構造で最上部のコントロールのみ操作可能
　　　　　　// 例：ＲＰＧとかの戦闘シーンでのコマンド選択　ＡＤＶの選択肢　etc...
　　　　　　// モードレスなＧＵＩは描画専用で、操作に対するイベント処理は行わない
　　　　　　// 例：ＨＰ表示とか
　　　　　　// モードレスなＧＵＩはプライオリティを指定して登録する。

DxGuiResource　　　// GUIで使う共用リソースを保持

DxGuiObject　　　　// GUIのrect情報とイベント発行機能を持つ基本クラス
　　　　　　　　　// ここにない独自のコントロールもDxGuiObjectから派生させれば
　　　　　　　　　// DxGuiに登録可能になる

DxWindow　　　　　　　// ウィンドウ
DxRectWindow　　　　　// 画像を使わないウィンドウ　基本描画メソッドのみで描画
DxGraphWindow　　　　　// 単一画像使用 サイズ固定ウィンドウ
DxVariableGraphWindow　// 複数画像使用 サイズ可変ウィンドウ 枠画像と背景画像用意
　　　　　　　　　　　// クライアント領域（ウィンドウサイズ）と、
　　　　　　　　　　　// ドキュメント領域（ウィンドウ内の利用領域）を持つ
　　　　　　　　　　　// ドキュメント領域に、レイアウトやGuiObjectを登録して使う
　　　　　　　　　　　// 特殊なウィンドウ（タイトルバーのようなものを追加等）
　　　　　　　　　　　// は派生クラスで対応？

DxTabControl　　　　// タブ切り替え可能なコントロール

DxLayout　　　　　　// 登録したguiの表示位置をレイアウトする
DxHorizontalLayout
DxVerticalLayout
DxGridLayout

DxSpacer　　　　　　// レイアウト用の空白（何もしない）コントロール
DxHorizontalSpacer　// rect情報だけ持つ感じ？
DxVerticalSpacer

DxButtonGroup　　　// ボタングループ(メニュー選択や選択肢などでも使う)
DxButton　　　　　// ボタン
DxTextButton　　　// 文字のみのボタン
DxGraphButton　　　// 画像ボタン

DxTextEdit　　　　// KeyInputStringあたりのラッパ

DxLabel　　　　　// tstring + pos + fontHandle + color + DrawStringの複合クラス
DxText　　　　　// Labelにもっと複雑な表示機能　htmlタグ拡張　ハイパーリンク的なのとか追加したの
　　　　　　　　// LabelもTextも単一行のみ扱う。

DxLabelBox　　　// DxLabelの複数行版 あらかじめ行数を指定して利用
DxTextBox　　　　// DxTextの複数行版 禁則処理なども行う
　　　　　　　　// 行数指定を超えた分の文字は無視される？（未定）
　　　　　　　　// 行数指定無しは次のDxTextScrollAreaを使う

DxScrollArea　　　　// スクロール表示
DxGraphScrollArea　// 画像用
DxTextScrollArea　　// テキスト用

DxListView　　　　// リストビュー　DxScrollAreaとの違いは、行単位でボタンとして機能なところ？
DxTableView　　　// テーブルビュー

DxProgressBar　　// プログレスバー

DxSlider　　　　　// スライダ
DxHorizontalSlider
DxVerticalSlider


DxScrollBar　　　　　　// スクロールバー
DxHorizontalScrollBar　// 主に他のコントロールに複合的に利用されるコントロール
DxVerticalScrollBar




// ############　以下は棚上げ中もしくは使わないとおもわれ
TreeView　　　// たぶん使わない？　作るのも面倒くさそうなのでパスする方向でｗ

// 以下は操作がゲームパッドでは扱いづらそう。
// 操作がマウスオンリーになってしまうのは避けたい

RadioButton　　　// bool値で画像変わるだけのコントロールなかんじ？
CheckButton　　　// 使うような使わないような……

ComboBox　　　　// 実際のゲーム画面ではなくコンフィグ設定画面とかの特定画面の特定用途では
SpinBox　　　// マウスオンリーな操作でも許される気がするので
　　　　　　// あった方がいいかも？
　　　　　　// 特定用途では便利なコントロールではある。
　　　　　　// キーボードorゲームパッドでも、フォーカスを与えてから
　　　　　　// プルダウンメニュー表示など段階踏めば使えるかな。
　　　　　　// と言うことでとりあえず保留

Menu　　　　// コレも操作がゲームパッドでは扱いづらそう
　　　　　　// 画面の縦横比がまちまちな昨今ではフルスクリーンモードは使わないので
　　　　　　// どしてもメニュー使いたい場合は
　　　　　　// 普通にＯＳのＧＵＩ機能(DxLibから利用可能)を使った方がよさそう。


やっぱ書き出してみると整理しやすいな。
大まかに脳内でイメージしてたものが
ちゃんと形として見えてきたかも。

てかほとんど、QT createrのＧＵＩ作成画面の
埋め込みコントロール一覧をなぞって
取捨選択した感じなのだけどもｗ

それぞれのクラスの中身の設計は
だいたい出来てる感じなので

あとはひたすら組んでいくだけ。

とはいえ、実際に組んでみたら、
いろいろと問題も出てくるんでしょうけど。

まだまだその辺は、修行がたらんです。


昨日のＧＵＩのスタイル案は全面却下な方向で。
ＧＵＩリソース管理クラスに共用画像は全部持つことにして
ＧＵＩのスタイル（見た目）は派生クラスで分けて
がっつりハードコーディングな方向で。

やっぱ、スタイルを別にクラスとして外に持って
汎用的なスタイルを～ってのは無駄が多すぎるという結論に落ち着いたり。
スタイル自体も、よくよく考えてみれば
わりとコントロール毎の独自項目が多くて共通部分が少ない感じだし。


実際のコーディングで問題になりそうなのは
やっぱ入力装置にたいする反応の書き方でしょうか。
基本方針にもあるとおり、
マウスオンリーではない操作系にしたいので
（でも、マウスオンリーでも操作出来る形。
あくまでもユーザーに、ある単一のデバイスの利用を強要させない
というのが本来の目的。
ここの操作だけはマウスでしか出来ないよ。みたいなのがあると
そこだけゲームパッドから手をはなしてマウスに持ち替えなければならない。
みたいのを無くしたい）

コンフィグ画面のような場合、
複数のコントロールをならべていると
スタックでのフォーカス管理は無理があるような気もしている。
その場合はマウスオンリー操作モードのようなものを用意するべきかなぁ。
とか、その辺はまだ思案中。
リストでもって、「現在フォーカスを持っている」という
状態を示すメンバを持つってのは
毎回フォーカスを持っている物をチェックする必要があって
なんか無駄だし。

むうん。

すでにDxButton、DxButtonGroupなんかは
一度、昔のゲームＰＧ内で実装しているのですが
（んでも以前のはDxButtonのなかで
画像ボタンとテキストボタンをフラグで切り替えてて……
switch分岐とかがいぱーいな、スパゲティコードだったｗ）

そのころ組んでたときに思ってた問題点が
「入力デバイスの状態はシステム側で持っている感じにしないとだめだなー」
ていうのが、現在の入力関係クラスの設計にフィードバックされてる
感じになっていたりする。

ＧＵＩクラスから、
たとえば矢印キーの上下が押されているかをチェックとか
直接はできないので（キーコンフィグに対応できない）
（マウスは直接問い合わせても問題なしですが。
もともとシステム依存だし、キーコンフィグも必要がない
せいぜいあるとすれば、左右のボタンの位置を変えれるぐらい？）

そこでシステム側で仮想のコントローラを用意する。
その仮想コントローラは各入力デバイス内でキーコンフィグされた後の
入力情報を単一のインターフェースに落とし込むのが最大の目的で

そうすることでＧＵＩクラスから
システム側の機能である仮想コントローラに問い合わせることで
キーコンフィグ後の入力情報の問い合わせが出来ると言う感じ。

これをしないと、ＧＵＩ操作にはキーコンフィグされた操作が利用できない。
もしやろうとするとＧＵＩクラス内にキー入力の問い合わせのコードを
ハードコーディングで埋め込むことが出来ず、その部分は外から設定できる様に
しなければならなくなるため。

そんな感じで、その外部の設定を
入力クラスに最初から委託しているの前提な設計、
という感じになっている。

で、もう入力関係クラスはすでに実装済みなので
あとは実際の運用で上手く動くかなーといったところ。


しかしＭＭＯみたいな画面をかんがえると
コントロールに直接ショートカットキーを与えるみたいな機能も
必要か。

仮想コントローラの入力チェックできるボタン数は固定なので
その数を超えるような大量のショートカットは
直接キーボード入力の入力情報をチェックする必要があるだろうし。

んまあその場合は、そのゲーム特有の拡張ってことで
ショートカットキーのキーコンフィグなんかは
自前で組んで、ライブラリでサポートする部分ではないかな。

んーその場合は、
「ショートカットキーを登録出来る」
「マウスのクリック監視」
「フォーカスを持たない」
という機能を持つ個別のＧＵＩオブジェクトとして定義するべきかな。


むう。
いろんなケースを考え出すと、
やっぱ複数の入力デバイスに対するＧＵＩ操作のあたりは
ネックになりそうな予感……。