Canvasでクラウドソーシングのプロジェクトを作る - ページ 13 1...67891011121314151617181920...45 新しいコメント --- 2016.11.28 15:00 #121 Igor Volodin:私にとっては、製品開発チームを作り、そのメンバーが製品の売り上げからある程度利益を得る方が簡単です（誰かがプロジェクトの思想家で、誰かが資金を出し、誰かがプログラマーかもしれません）。 そして、みんな金銭的なモチベーションが高いので、インターフェイスに必要なライブラリもプロジェクトの一部として実装することです。 は賛成ですが、ライブラリ自体はクラウドソーシングでオープンにすべきです ) Alexey Volchanskiy 2016.11.28 15:08 #122 o_O:イーゴリ・ヴォロディン私にとっては、製品開発チームを作り、そのメンバーが製品の売り上げから一定の利益を得る方が簡単です（誰かがプロジェクトの思想家で、誰かが出資し、誰かがプログラマーかもしれません）。 そして、すべてが財政的に動機づけられているので - プロジェクトとインターフェイスに必要なライブラリの中で実装することです。 私もそう思いますが、ライブラリ自体はオープンソースのクラウドソーシングであるべきです）。 スレッドを読みましたが、Canvas上にボタンを一から描画する必要があるのかがわかりませんでした。感情を抜きに説明できますか？ --- 2016.11.28 15:26 #123 Alexey Volchanskiy: スレッドを読ませていただきましたが、なぜCanvasに一からボタンを描く必要があるのか、未だに理解できません。感情を抜きに説明できますか？ ObjectCreateとResourceCreateの どちらかを選択します。 MTの開発者は全能ではないので、些細な要求で彼らを悩ませるのは時間がかかるからです。 Igor Volodin 2016.11.28 17:06 #124 なぜ便利なのか1.ビットマップ上のインターフェイスが高速である。システムのものとほとんど見分けがつかないほど高速です。例えば、半透明のグラデーションを持つエレメントを実装しましたが、それらが動いても、他の半透明グラデーションを持つオブジェクトのカラーミキシングやアルファチャンネル計算を考慮して、目に見える遅延なくスムーズにレンダリングされます。 2.インターフェイスがスケーラブルであること。アプリケーションをより複雑にしても、大量のグラフオブジェクトの削除や作成が原因で動作が遅くなることはないでしょう。再描画のコストはごくわずかで、1000分の1秒の間に絵を入れ替えるだけです。 3. 既製のコントロールが作成でき、独自のイベントプールを提供できるため、新しいコントロールが作成できる。OnMouseDown - LKMが押されました。OnMouseUp - LKMが押されました。OnMouseHoverOn - マウスカーソルをオブジェクトの上に移動させます。OnMouseHoverOut - マウスカーソルをオブジェクトから遠ざける．OnMouseClick - 押して、オブジェクトの境界内でクリックします。OnMouseDblClick - オブジェクトの境界内でマウスをダブルクリックします．OnDragStart - マウスの左ボタンが押された状態で、移動の開始時に1度だけ発生するイベントOnDragMove - マウスの左ボタンで移動するときに発生するイベント．OnDragEnd - LKMで移動した後に発生するイベント．OnPut - オブジェクトが別のオブジェクトにキャストされます。OnGet - オブジェクトが別のオブジェクトにダンプされます。OnFocus - オブジェクトにフォーカスが当たったOnBlur - オブジェクトがフォーカスを失うOnResize - オブジェクトのサイズが変更されました。OnParentResize - 親オブジェクトのサイズが変更されました。OnKeyPress - キーが押されたOnChange - フィールドの値が変更されました。など Making a crowdsourced project Alexey Volchanskiy 2016.11.28 17:09 #125 Igor Volodin:なぜ便利なのか1.ビットマップ上のインターフェイスが高速である。そのため、システムインターフェースとほとんど見分けがつかないほど高速です。例えば、半透明のグラデーションを持つエレメントを実装しましたが、それらが移動しても、他の半透明グラデーションを持つオブジェクトのカラーミキシングやアルファチャンネル計算を考慮し、目に見える遅延なくスムーズにレンダリングされます。 2.インターフェイスがスケーラブルであること。アプリケーションをより複雑にしても、大量のグラフオブジェクトの削除や作成が原因で動作が遅くなることはないでしょう。再描画のコストはごくわずかで、1000分の1秒の間に絵を入れ替えるだけです。 3. 既製のコントロールが作成でき、独自のイベントプールを提供できるため、新しいコントロールが作成できる。OnMouseDown - LKMが押されました。OnMouseUp - LKMが押されました。OnMouseHoverOn - マウスカーソルをオブジェクトの上に移動させます。OnMouseHoverOut - マウスカーソルをオブジェクトから遠ざける．OnMouseClick - 押して、オブジェクトの境界内でクリックします。OnMouseDblClick - オブジェクトの境界内でマウスをダブルクリックします．OnDragStart - マウスの左ボタンが押された状態で、移動の開始時に1度だけ発生するイベントOnDragMove - マウスの左ボタンで移動するときに発生するイベント．OnDragEnd - LKMで移動した後に発生するイベント．OnPut - オブジェクトが別のオブジェクトにキャストされます。OnGet - オブジェクトが別のオブジェクトにダンプされます。OnFocus - オブジェクトにフォーカスが当たったOnBlur - オブジェクトがフォーカスを失うOnResize - オブジェクトのサイズが変更されました。OnParentResize - 親オブジェクトのサイズが変更されました。OnKeyPress - キーが押されたOnChange - フィールドの値が変更されました。など 網羅的に、ありがとうございました Igor Volodin 2016.11.28 17:34 #126 スレッドを読むと、面白い。3年ほど前、インターフェースについてこれほどの騒動がなかったのが残念です。私のコードを投稿しても、怠慢や参加者間のコミュニケーションの難しさ（そしてそれらはすでに観察されています）により、この取り組みが衰退する可能性が高いので、私のコードは地下室に引きずり込まれ、自分のために修正され、私（そしてコミュニティ）は全くそこから利益を得られないと思います。しかし、プロジェクトに 参加するためには、必要な機能の議論から始まり、具体的な実装内容を仕込むことができ、そのような、仮にフレームワークと呼ぶことにした場合のメリットもあります。そのメリットは、最初の数回の投稿でAlexが声を上げたように、シンプルなものです。コミュニティは、MQLプラットフォームに修正を導入するために端末の開発者に影響を与えることができます。私が望む改善点（プログラミングインターフェイスに直接関係すること）は、以下の通りです。MQLアプリケーション-他をキャンセルしない別タイプのプログラムとして（onTickもなく、デフォルトシンボルを参照する可能性もない-過去の遺物だが、すべてがマルチカレンシーなので、任意のシンボルの取引環境を取得して取引する可能性がある）、アプリケーションは特定のシンボルのチャート上ではなく、それ自身のウィンドウで起動する必要があります。このようなプログラムをチャートの上にドラッグすると、新しいウィンドウが開かれます。また、ドラッグ＆ドロップは必要なく、ナビゲーターで2クリックすると、新しいウィンドウが開きます。これは、他言語での開発用に端末のAPIを提供してほしいという要望があるのと似ています。開発中のトピック - このようなプログラムは、特別にコンパイルされ、端末なしで実行することができると仮定することができます（と安全上の理由から、市場を通じてのみ、このコンパイルを許可します）。乱暴に聞こえるかもしれませんが、もしもの話です。別ファイルとして提示されるサードパーティ製ベクターフォントのサポートとリソースとしてコンパイルする機能（ドキュメントに記載されていますが、実装されていません。）マウススクロールイベントの取得右クリックメニューのロック右ボタンが処理されるようになったが、使い物にならない。システムのクリップボードを処理し、独自のテキスト編集コントロール（複数行のエディタを含む）を作成するには、スペースバーとエンターは、すでにロックすることができます - 良い。 --- 2016.11.28 19:34 #127 Igor Volodin、Combinator、Anatoli Kazharski。まずは痛いところから（笑) 私が最も懸念しているのは、レンダリングパラメータを保存するためのある種の普遍性/抽象化です。----私たちは、すべてのコントロールが等しくフォント、背景色、文字色を使用するなどと理解しています。 これらのパラメータがすべてのコントロールで同じである場合、インターフェースは単一のコンセプトで共通の外観を持つことになる。しかし、どのように保存するかというと、コントロールは常にすべてのパラメータを使用するとは限らないからです。+ 要素が異なる状態を持ち、フォントと背景色を使い分ける必要があるため、システムが複雑になっています。Active、Disable、Over、Selectなどである。 + コントローラには、レリーフ（ボタンなど）と入力フィールド（編集、リストなど）のグループがあり、それらをレンダリングする背景はいつなのか？----現在のアイデアでは、GAttribBase クラスの最小限の属性要素を持っていて、5つの基本パラメータ（フォント/サイズ、背景/ボーダーカラー、ボーダーサイズ）を含んでいます。これらの基本要素は、GAttributribut クラスの 状態（Active/Disabvle/Over/Select など）を表す配列を形成するために使用されます。そして、GAttributは、Relief、Editableなど、さまざまな要素タイプに対応するように入力されます。そのため、レンダリングパラメータを一度入力すれば（xmlに格納）、異なるデザインを作成するために編集することができ、コントローラごとに定義することなく、グローバルに使用することができます。もちろん、あるコントローラに独自のレンダリングパラメータを定義する必要がある場合は、コントロール内に独自のGAttributributオブジェクトを作成し、必要な色を指定するだけです。----このモデルはうまくいき、統一されたデザインをあっという間に実現し、すべてのコントロールは共通の配列から色を取り出します。 しかし、私の考えでは、それは普遍的なものではありません。ユーザーは、ベースとなるGAttribBaseのどのパラメータが、このコントロールやこのコントロールのレンダリングに使用されるかを理解していない。 コーダーがどの色を変更しなければならないかを正確に知るためには、コントロールのレンダリング機能を調べなければなりません。 これは本当に面倒なことです。-----とにかく、コーダーがカラーマネジメントから解放される（あらかじめ定義された色をそのまま使い、最初から悩まない）ためのアイデアがあれば教えてください。一方、画面上の一部のコントロールの色を変えたい場合、どのGAttribBaseがどのような場合に使われるかを調査する必要はないそうです。 Igor Volodin 2016.11.28 20:26 #128 o_O:Igor Volodin、Combinator、Anatoli Kazharski。一般的に - コーダーが一方では色の作業から解放されるために、どのようなアイデアがありますか（敷き詰められた色をすぐに使い、初めから気にしないようにする）。また一方で、画面上の一部のコントロールの色を変えたい場合、描画関数の迷路に入り込んで、どのGAttribBaseがどのような場合に使われるかを探さなくても、そのようなことができる。OK、テーマ例えば、アプリケーションのメインオブジェクト（仮にAppと呼ぶ）は、ConcreteThemeオブジェクトと関連付けられている。テーマオブジェクトとは。 色（背景色、前景色、無効、有効など）、ベースサイズ、標準的な場合のフォントサイズ：titlesize、commonsizeなど。パネル、ボタン、チェックボックスなどのスプライト。新しいテーマとは、値が変更された新しいクラス/構造体のことです。しかし、テーマは特定のパラメーターだけをオーバーライドして継承できる方が良い。 残りの部分 - コントロールの階層で、各コントローラはデフォルトでオブジェクトテーマの必要な値のいずれかを使用します。これをオーバーライドする必要がある場合は、新しい値を指定して、そのプロパティを操作するメソッドを呼び出します。例えば SetBgColor(XRGB(255,0,128)) です。CView - 基本的なイベントベースのインタラクションを提供する基本的なクラスです。- CRect - 座標- Cpanelでは、bgcolor- CButtonはstateオブジェクトを持ち、各stateはbgを持つ。- CTextは、テキストカラーとフォントのプロパティを持ちます- CCサークル といった具合に。xmlで要素を記述したい場合。そして、各クラスのコントロールやプリミティブに対して、属性 (bgcolor="(255,0,128)") をクラスの対応するメソッド (SetBgColor(attrValue)) にマップする生成クラスを作成する必要があります (これを "build-container" と呼びましょう)。このようなビルドコンテナは、XMLパーサーによって解析され、必要な値で初期化されたオブジェクトが出力されます（値が指定されていない場合はデフォルトの値）。 Making a crowdsourced project --- 2016.11.28 20:52 #129 ここでは、私のテーマと 同じ、さまざまな種類のコントロールとその状態のためのGAttributorsの セットです。しかし、あなたはすでにコーダーのための透明化への道のりの最初のステップを示唆している - 特定のコントロールに関数を追加し、そのレンダリングプロパティを変更する（SetBgColorなど）。基本的には賛成ですが、どんな色を持っていて、何が変えられるのかが明確になります。では、「テーマ」は未使用のパラメーターの冗長性を意味するのでしょうか？ 例えば、私の基本的なGAttribBaseで、あるコントロール（例えばボタン）に対して、背景色と サイズだけを使用し、他のパラメータ（境界線の太さなど）は、このコントロールでは使用しないとします。つまり、すべてのコントロールのベースとなる要素を持っているか、「すべての場合」の情報がどこに格納されているか、すべてのコントロールが普遍性のオーバーヘッドなしにそのパラメータだけを持っているか、ということです。 Anatoli Kazharski 2016.11.28 21:17 #130 o_O:...一般的に、コーダーが色を扱わないようにするためのアイデアはありますか（デフォルトの色を使用し、最初から色を気にしないようにする）。一方、画面上のあるコントローラの色を変えたいとき、レンダリング関数の荒野に飛び込んで、どのGAttribBaseがどんな場合に使われるかを調べる必要がないようにします。各項目にデフォルト値を設定する。ユーザーが何かを変更する必要がある場合、各項目のプロパティに新しい値を設定するメソッドを用意する必要があります。今はこうやってやってもらっています。まだ持っていないんです。もし、「2カウント」で全ての要素のプロパティを変更する必要があるのなら、全てのインターフェース要素にアクセスできるそのクラスに、（デザインに関連し、全ての要素に適用できる共通のプロパティ用の）別のメソッドを作ればよいのです。原理的には、私のスキーマでどのように実装できるかは、すでに見えています。例えば、イベントを通じて。しかし、そうすると各要素のイベントハンドラで、このイベントを処理する必要があります（コードは肥大化します）。第二の選択肢は、一般的なGUIイベントを処理するクラス、あるいはさらに上位の、GUI要素へのすべてのポインタが格納されるクラスに、特別なパブリックメソッドを作成することです。どちらもカスタムMQL-applicationクラスのベースクラスであり、ユーザーはそれらに直接アクセスすることができます。MQLのオーバーロードされた ObjectSet メソッド（例えばElementSet）のようなもので、（1）プロパティと値、または（2）プロパティとモディファイアと値を指定する必要があります。しかし、これらはすべて、私のスキームに関する推論です。移行を始めると、やはり大きく変化することは否定しません。だから、上に書いたことは、もはやここで議論されているテーマとは関係ないかもしれない。) 1...67891011121314151617181920...45 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
私にとっては、製品開発チームを作り、そのメンバーが製品の売り上げからある程度利益を得る方が簡単です（誰かがプロジェクトの思想家で、誰かが資金を出し、誰かがプログラマーかもしれません）。
そして、みんな金銭的なモチベーションが高いので、インターフェイスに必要なライブラリもプロジェクトの一部として実装することです。
私にとっては、製品開発チームを作り、そのメンバーが製品の売り上げから一定の利益を得る方が簡単です（誰かがプロジェクトの思想家で、誰かが出資し、誰かがプログラマーかもしれません）。
そして、すべてが財政的に動機づけられているので - プロジェクトとインターフェイスに必要なライブラリの中で実装することです。
スレッドを読ませていただきましたが、なぜCanvasに一からボタンを描く必要があるのか、未だに理解できません。感情を抜きに説明できますか？
MTの開発者は全能ではないので、些細な要求で彼らを悩ませるのは時間がかかるからです。
なぜ便利なのか
1.ビットマップ上のインターフェイスが高速である。システムのものとほとんど見分けがつかないほど高速です。例えば、半透明のグラデーションを持つエレメントを実装しましたが、それらが動いても、他の半透明グラデーションを持つオブジェクトのカラーミキシングやアルファチャンネル計算を考慮して、目に見える遅延なくスムーズにレンダリングされます。
2.インターフェイスがスケーラブルであること。アプリケーションをより複雑にしても、大量のグラフオブジェクトの削除や作成が原因で動作が遅くなることはないでしょう。再描画のコストはごくわずかで、1000分の1秒の間に絵を入れ替えるだけです。
3. 既製のコントロールが作成でき、独自のイベントプールを提供できるため、新しいコントロールが作成できる。
OnMouseDown - LKMが押されました。
OnMouseUp - LKMが押されました。
OnMouseHoverOn - マウスカーソルをオブジェクトの上に移動させます。
OnMouseHoverOut - マウスカーソルをオブジェクトから遠ざける．
OnMouseClick - 押して、オブジェクトの境界内でクリックします。
OnMouseDblClick - オブジェクトの境界内でマウスをダブルクリックします．
OnDragStart - マウスの左ボタンが押された状態で、移動の開始時に1度だけ発生するイベント
OnDragMove - マウスの左ボタンで移動するときに発生するイベント．
OnDragEnd - LKMで移動した後に発生するイベント．
OnPut - オブジェクトが別のオブジェクトにキャストされます。
OnGet - オブジェクトが別のオブジェクトにダンプされます。
OnFocus - オブジェクトにフォーカスが当たった
OnBlur - オブジェクトがフォーカスを失う
OnResize - オブジェクトのサイズが変更されました。
OnParentResize - 親オブジェクトのサイズが変更されました。
OnKeyPress - キーが押された
OnChange - フィールドの値が変更されました。
など
なぜ便利なのか
1.ビットマップ上のインターフェイスが高速である。そのため、システムインターフェースとほとんど見分けがつかないほど高速です。例えば、半透明のグラデーションを持つエレメントを実装しましたが、それらが移動しても、他の半透明グラデーションを持つオブジェクトのカラーミキシングやアルファチャンネル計算を考慮し、目に見える遅延なくスムーズにレンダリングされます。
2.インターフェイスがスケーラブルであること。アプリケーションをより複雑にしても、大量のグラフオブジェクトの削除や作成が原因で動作が遅くなることはないでしょう。再描画のコストはごくわずかで、1000分の1秒の間に絵を入れ替えるだけです。
3. 既製のコントロールが作成でき、独自のイベントプールを提供できるため、新しいコントロールが作成できる。
OnMouseDown - LKMが押されました。
OnMouseUp - LKMが押されました。
OnMouseHoverOn - マウスカーソルをオブジェクトの上に移動させます。
OnMouseHoverOut - マウスカーソルをオブジェクトから遠ざける．
OnMouseClick - 押して、オブジェクトの境界内でクリックします。
OnMouseDblClick - オブジェクトの境界内でマウスをダブルクリックします．
OnDragStart - マウスの左ボタンが押された状態で、移動の開始時に1度だけ発生するイベント
OnDragMove - マウスの左ボタンで移動するときに発生するイベント．
OnDragEnd - LKMで移動した後に発生するイベント．
OnPut - オブジェクトが別のオブジェクトにキャストされます。
OnGet - オブジェクトが別のオブジェクトにダンプされます。
OnFocus - オブジェクトにフォーカスが当たった
OnBlur - オブジェクトがフォーカスを失う
OnResize - オブジェクトのサイズが変更されました。
OnParentResize - 親オブジェクトのサイズが変更されました。
OnKeyPress - キーが押された
OnChange - フィールドの値が変更されました。
など
網羅的に、ありがとうございました
Igor Volodin、Combinator、Anatoli Kazharski。
まずは痛いところから（笑)
私が最も懸念しているのは、レンダリングパラメータを保存するためのある種の普遍性/抽象化です。
----
私たちは、すべてのコントロールが等しくフォント、背景色、文字色を使用するなどと理解しています。
これらのパラメータがすべてのコントロールで同じである場合、インターフェースは単一のコンセプトで共通の外観を持つことになる。
しかし、どのように保存するかというと、コントロールは常にすべてのパラメータを使用するとは限らないからです。
+ 要素が異なる状態を持ち、フォントと背景色を使い分ける必要があるため、システムが複雑になっています。Active、Disable、Over、Selectなどである。
+ コントローラには、レリーフ（ボタンなど）と入力フィールド（編集、リストなど）のグループがあり、それらをレンダリングする背景はいつなのか？
----
現在のアイデアでは、GAttribBase クラスの最小限の属性要素を持っていて、5つの基本パラメータ（フォント/サイズ、背景/ボーダーカラー、ボーダーサイズ）を含んでいます。
これらの基本要素は、GAttributribut クラスの 状態（Active/Disabvle/Over/Select など）を表す配列を形成するために使用されます。
そして、GAttributは、Relief、Editableなど、さまざまな要素タイプに対応するように入力されます。
そのため、レンダリングパラメータを一度入力すれば（xmlに格納）、異なるデザインを作成するために編集することができ、コントローラごとに定義することなく、グローバルに使用することができます。
もちろん、あるコントローラに独自のレンダリングパラメータを定義する必要がある場合は、コントロール内に独自のGAttributributオブジェクトを作成し、必要な色を指定するだけです。
----
このモデルはうまくいき、統一されたデザインをあっという間に実現し、すべてのコントロールは共通の配列から色を取り出します。
しかし、私の考えでは、それは普遍的なものではありません。ユーザーは、ベースとなるGAttribBaseのどのパラメータが、このコントロールやこのコントロールのレンダリングに使用されるかを理解していない。
コーダーがどの色を変更しなければならないかを正確に知るためには、コントロールのレンダリング機能を調べなければなりません。 これは本当に面倒なことです。
-----
とにかく、コーダーがカラーマネジメントから解放される（あらかじめ定義された色をそのまま使い、最初から悩まない）ためのアイデアがあれば教えてください。
一方、画面上の一部のコントロールの色を変えたい場合、どのGAttribBaseがどのような場合に使われるかを調査する必要はないそうです。
Igor Volodin、Combinator、Anatoli Kazharski。
一般的に - コーダーが一方では色の作業から解放されるために、どのようなアイデアがありますか（敷き詰められた色をすぐに使い、初めから気にしないようにする）。
また一方で、画面上の一部のコントロールの色を変えたい場合、描画関数の迷路に入り込んで、どのGAttribBaseがどのような場合に使われるかを探さなくても、そのようなことができる。
OK、テーマ
例えば、アプリケーションのメインオブジェクト（仮にAppと呼ぶ）は、ConcreteThemeオブジェクトと関連付けられている。
テーマオブジェクトとは。
色（背景色、前景色、無効、有効など）、ベースサイズ、標準的な場合のフォントサイズ：titlesize、commonsizeなど。パネル、ボタン、チェックボックスなどのスプライト。
新しいテーマとは、値が変更された新しいクラス/構造体のことです。しかし、テーマは特定のパラメーターだけをオーバーライドして継承できる方が良い。
残りの部分 - コントロールの階層で、各コントローラはデフォルトでオブジェクトテーマの必要な値のいずれかを使用します。これをオーバーライドする必要がある場合は、新しい値を指定して、そのプロパティを操作するメソッドを呼び出します。
例えば SetBgColor(XRGB(255,0,128)) です。
CView - 基本的なイベントベースのインタラクションを提供する基本的なクラスです。
- CRect - 座標
- Cpanelでは、bgcolor
- CButtonはstateオブジェクトを持ち、各stateはbgを持つ。
- CTextは、テキストカラーとフォントのプロパティを持ちます
- CCサークル
といった具合に。
xmlで要素を記述したい場合。
そして、各クラスのコントロールやプリミティブに対して、属性 (bgcolor="(255,0,128)") をクラスの対応するメソッド (SetBgColor(attrValue)) にマップする生成クラスを作成する必要があります (これを "build-container" と呼びましょう)。このようなビルドコンテナは、XMLパーサーによって解析され、必要な値で初期化されたオブジェクトが出力されます（値が指定されていない場合はデフォルトの値）。
ここでは、私のテーマと 同じ、さまざまな種類のコントロールとその状態のためのGAttributorsの セットです。
しかし、あなたはすでにコーダーのための透明化への道のりの最初のステップを示唆している - 特定のコントロールに関数を追加し、そのレンダリングプロパティを変更する（SetBgColorなど）。
基本的には賛成ですが、どんな色を持っていて、何が変えられるのかが明確になります。
では、「テーマ」は未使用のパラメーターの冗長性を意味するのでしょうか？
例えば、私の基本的なGAttribBaseで、あるコントロール（例えばボタン）に対して、背景色と サイズだけを使用し、他のパラメータ（境界線の太さなど）は、このコントロールでは使用しないとします。
つまり、すべてのコントロールのベースとなる要素を持っているか、「すべての場合」の情報がどこに格納されているか、すべてのコントロールが普遍性のオーバーヘッドなしにそのパラメータだけを持っているか、ということです。
...
一般的に、コーダーが色を扱わないようにするためのアイデアはありますか（デフォルトの色を使用し、最初から色を気にしないようにする）。
一方、画面上のあるコントローラの色を変えたいとき、レンダリング関数の荒野に飛び込んで、どのGAttribBaseがどんな場合に使われるかを調べる必要がないようにします。
各項目にデフォルト値を設定する。ユーザーが何かを変更する必要がある場合、各項目のプロパティに新しい値を設定するメソッドを用意する必要があります。今はこうやってやってもらっています。
まだ持っていないんです。
しかし、これらはすべて、私のスキームに関する推論です。移行を始めると、やはり大きく変化することは否定しません。だから、上に書いたことは、もはやここで議論されているテーマとは関係ないかもしれない。)