MQLで書かれたUIのギャラリー - ページ 79

[Aleksey Vyazmikin]

Реter Konow #:
大体において、このエディタでは長い説明やチュートリアルを必要とするものはほとんどなく、その習得には1時間もかからないだろう。そして、それはマークアップ言語に対する否定できない利点です）。

良い目標本当にゼロから機能を使いこなすテスターを募集する必要がある。そうすれば、インターフェイスの人間工学で何に注意を払うべきか、より明白になるだろう......。

[Реter Konow]

Aleksey Vyazmikin #:

良い目標だ！そうすれば、インターフェイスの人間工学において、何に注意を払うべきかがより明白になる。

同感だが、そこまで到達する必要がある。ブランチのページですでに1人がベータテスターに志願してくれている。来月にはエディターの初期テストが必要になるだろう。まだ多くのルーチンワークがあり、かなり遅くなっています。すべてのプロパティ・テーブル、テンプレート・グループ、タブとグループの割り当て、デザインの決定、小さなバグ......しかし、誰もそれが簡単だとは言っていない）。

[Aleksey Vyazmikin]

Реter Konow #:
私もそう思うが、そこまで到達する必要がある。スレッドページのベータテスターに志願した人がすでに1人いる。来月中にはエディターの初期テストが意味を持つようになるだろう。まだ多くのルーティンワークが残っており、作業スピードはかなり落ちている。すべてのプロパティ・シート、テンプレート・グループ、タブとグループの割り当て、デザインの決定、小さなバグ...。）

いずれにせよ、あなたはその目的を果たす製品に時間を費やしているのであって、ここにいる他の多くの人たちが結果の保証もない同じEAを書いているのとは違います。

[Kuzma Shevelev]

Реter Konow #:

マークアップ言語の方向性をこれ以上発展させる意味がない理由：

1.参入の敷居が高い。

ユーザーが複雑なパネルを作るには、その言語のルールを知る必要がある。しかし、私が今後6-7ヶ月の間に書かなければならない20のチュートリアルを勉強した後でなければ、それらを知ることはできないだろう。

結局のところ、開発された基盤を使うのは普通のユーザーではないし、開発者にとって、技術適用の原理を学ぶ必要性は普通の現象だ。

[Реter Konow]

Aleksey Vyazmikin #:

いずれにせよ、あなたはその目的を果たす製品に時間を費やしているのであって、ここにいる他の多くの人たちが、結果の保証もなく同じアドバイザーを書いているのとは違う。

そう、私の製品はその役目を果たしているが、結果の保証のないEAを書く人がいなければ意味がない。だから、彼らを批判することはできない。）

[Aleksey Vyazmikin]

Реter Konow #:
そう、私の製品はその役目を果たすが、結果を保証しないアドバイザーを書く人がいなければ意味がない。だから、私は彼らを批判することはできない。）

批判ではなく、目に見える結果を出すことの喜びが大事なのだ。

[Реter Konow]

Kuzma Shevelev #:

結局のところ、開発された基盤を使うのは普通のユーザーではないし、開発者にとって技術適用の原理を学ぶ必要性は普通の現象である。

開発者にとってはそうだ。しかし、記事やGUIライブラリの作者たちの経験を客観的に見ると、彼らが直面した普及の難しさを感じずにはいられない。私にはよくわからない何らかの理由で、このトピックは一般の人々の関心を引いていない。おそらく、強力な開発者の割合が高くないからだろうが、大規模なライブラリや記事の複雑さが誰かを怖がらせている可能性もある。正直に言おう-OOPは単純な抽象化ではないし、それが邪魔になるとき、人のやる気が試されるのだ。

私のマークアップ言語は、もちろんOOPの概念よりもずっとシンプルだが、部分的に分割されたプレゼンテーションを数ヶ月にわたって行う必要がある。何かを普及させるという点では、これは非常に非効率的なアプローチだ。だから私は、マークアップ言語がグラフィカル・ライブラリと同じ運命をたどるのはほぼ避けられないという結論に達した。

対照的に、取引プラットフォーム内のビジュアル・エディターは新しい方法だ。これまでになかった方法です。だから、違う運命をたどるという希望がある。

[Реter Konow]

Aleksey Vyazmikin #:

それは批判ではなく、目に見える結果を達成する喜びなのだ。

この点では私も同感だが、需要がなければこの喜びは一瞬にして消え去り、虚しさが残る。だから今、私は結果を保証せずにアドバイザーを書いている人たちと同じ状況にいる。いわば同じ船に乗っているのだ。

[Kuzma Shevelev]

Реter Konow #:
もちろん開発者にとっては。しかし、記事やGUIライブラリの作者たちの経験を見ると、彼らが直面しなければならなかった大衆化のある種の難しさを感じずにはいられない。私にはよくわからない何らかの理由で、このトピックは一般の人々の関心を引いていない。おそらく、強力な開発者の割合が高くないからだろうが、大規模なライブラリや記事の複雑さが誰かを怖がらせている可能性もある。率直に言おう-OOPは単純な抽象化ではないし、それが邪魔になるとき、人のやる気が試されるのだ。

私のマークアップ言語は、もちろんOOPの概念よりもずっとシンプルだが、部分的に分割したプレゼンテーションを数ヶ月にわたって行う必要がある。何かを普及させるという意味では、これは非常に非効率的なアプローチだ。だからこそ私は、マークアップ言語はグラフィカル・ライブラリの運命をほぼ必然的に繰り返すという結論に達したのだ。

対照的に、取引プラットフォーム内のビジュアル・エディターは新しい方法だ。これまでになかった方法だ。だから、違う運命をたどるという希望がある。

現在、先進的なインターフェースのほとんどはプログラムで開発されており、非常に良い結果を出しています。ライブラリを書くことは、完全なグラフィカル・エディターを開発するよりもはるかに時間がかかりません。

[Реter Konow]

Kuzma Shevelev #:

最近では、先進的なインターフェースのほとんどはプログラムで開発されており、それは非常に良い結果をもたらしている。ライブラリを書くことは、完全なグラフィカル・エディタを開発するよりもはるかに時間がかからない。

議論するつもりはない、ただの意見だ。

GUI開発の進化において、クラスライブラリや関数ライブラリは、グラフィカルライブラリ、マークアップ言語、ビジュアルエディタという既存の3つのうち、最初のステップを占めている。

ライブラリは、開発者が最も時間のかかる方法でコントロールを作成することを可能にしますが、最大の創造的自由を可能にすることは注目に値します（非常に経験豊富な開発者のためだけに設計されています）。

マークアップ言語は、このチェーンの中間リンクです。マークアップ言語は、利便性と簡単さ、そして幅広い機能を兼ね備えています。しかし、ライブラリの主な欠点の1つである、わずかな変更もチェックするためにプログラムを完全にコンパイルする必要がある、という欠点を引き継いでいます。要素の色を変えたらコンパイルし、何かをチェックしたければ再コンパイルする。フォントを変えた？- 再コンパイルする。位置を移動した？違うテキストを書く？- リコンパイル、リコンパイル、リコンパイル。

しかし、マークアップ言語は、複数の要素からなる大きなグループを作成し、プロパティを一括で設定するときには欠かせない。この作業をとても便利にしてくれる。ライブラリよりもずっと簡単だ。さらに、構文が少なく、直感的で、ルールが単純でないため、ライブラリの場合よりもはるかに理解が早い。

ビジュアルエディタは最高レベルです。マークアップ言語のすべての利点を兼ね備えていますが、ライブラリの域を超えた新しいレベルにまで高めています。エディタで作業するとき、すべての変更は一度に見ることができます。再コンパイルは必要ありません。マークアップ言語に劣るのではなく、マークアップ言語を凌駕する能力を持っています。トップ。

そして客観的に見て、この頂上まであとわずかしか残っていない...。これまでの移動距離に比べれば。