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

新しいコメント
 

...コンテンツといえば（「将来のアイデア」のために）．

現在、ターミナル・オブジェクト（ボタンとテキスト・ラベル）から直接パネルをデザインすることに「挑戦」しています、

で、こんな状況に出くわしました。

--> 自分自身」のために - ボタンの混乱を避けるために - ボタン自体に「詳しく」署名することにしました。
そのため、ボタン自体ではなく、ボタンにテキストを「重ね合わせる」 形にする必要がありました：

というわけで、将来、GUI の ボタンに 2 行から 3 行のキャプションを表示する方法を「発明」した場合に備えて、この状況を説明することを前提にした。

 
Vitaliy Kostrubko #:

ベータテスターになりたいよ。）

イニシアチブをありがとう！

技術的な実装の質を向上させるのに役立つことは間違いない。しかし、デザイナーやエディターのコードは議論の対象にはなりません。機能性とユーザー要求への適合性のみです。これが前提条件だ。あなたが同意すれば、すべては「レールの上」に進むでしょう。:)
 
Vitaliy Kostrubko #:

...GUIのボタンに同じような2-3行のキャプションを付けるにはどうすればいいか。

ウィル
 
慎重に検討した結果、ビジュアルエディターの機能回復に完全に集中することを戦略的に決定した。大まかな見積もりによると、今後3週間以内に最低限の完成度と実用的な適用が可能になる。さらなる開発と改善のみ。

この決断の理由については、さらに説明します。
 
Vitaliy Kostrubko #:

...コンテンツといえば（「未来へのアイデア」のために）...：

現在、ターミナルオブジェクトから直接パネルをデザインすることに "挑戦 "しています：ボタンとテキストラベルです、

そして、こんな状況に遭遇しました。


--> 自分自身」のために、ボタンの混乱を避けるために、ボタンの「詳細」自体に署名することにしました。
そのため、ボタン自体ではなく、ボタンに "重ね合わせた "形（！）で署名 する必要があった。 そのため、署名は2行になった：

というわけで、将来、GUI の ボタンに 2～3 行のキャプションを表示する方法を「発明」した場合に備えて、この状況を説明する前提になりました。

ですよね？:-)

GUIエディタなしで。）

あるいはこんな感じ。

あるいはこんな感じ。

:-)

念のため、10分ほど時間があったので...。

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

1.参入障壁が高い。

ユーザーが複雑なパネルを作るには、その言語のルールを知る必要がある。しかし、私が今後6～7ヶ月の間に書かなければならないチュートリアルを20個も勉強して初めて、彼らはそれを知ることになる。

2.言語ルールの知識なしにGUIテンプレートを完全に使いこなすことは不可能である。

知識はチュートリアルから得て、その教材は記事に印刷される。記事は月に1、2本の間隔で掲載される。全課程を修了するためには、少なくとも7～10本の記事を掲載する必要があり、このペースだと半年はかかる。

以上の議論から導き出される結論は、記事の出版後に初めてテンプレートを公開するのが理にかなっているということである。言語に関する実践的な知識がなければ、ユーザーはkib-codeテンプレートを自分のニーズに合わせて修正することができず、その有用性は著しく低下する。その結果、ユーザーは私に説明や助けを求めるようになる。一人か二人なら助けられるが、それ以上になると行き詰まる。




では、なぜビジュアル・エディターを開発することに大きな意味があるのか。

1.ユーザーの敷居が低い。

ビジュアル・エディターには、直感的に操作できるという利点がある。その機能と限界は、グラフィカル・インターフェースを 探索することで容易に認識できる。ツールチップを追加することで、複雑な内容を理解するのに役立ちます。

2.ビジュアルエディタを始めるために必要なトレーニング教材は少量です。

全体のコースは3-5記事に収まることができます。しかし、それらがなくても、ユーザーはシンプルで複雑なパネルの作成方法をすぐに学ぶことができます。

3.エディタはGUI作成を可能な限り単純化し、スピードアップします。

マークアップ言語での作業とビジュアル・エディタでの作業の労力の差は非常に大きい。この要因によって、最終的にビジュアル・エディタに軍配が上がった。必要な労力の少なさは、GUIトレーディング・アプリケーションの作成に対するユーザーの関心に好影響を与える。

4.ビジュアル・エディタのコンセプト・ベースはよく練られており、技術的なベースは4年前に書かれテストされている。客観的に見て、このエディターは最初のリリースの入り口に立っていると言えます。
 
Maxim Kuznetsov #:

そうだろう？:-)

これはGUIエディターなしの場合です :-)

といった感じです。

あるいは

:-)

ただ、10分ほど時間があったので...。

もちろん、サードパーティのプログラムを使ってGUIを構築し、DLL経由で接続したい人もいるだろう。

それは皆の自由だ。
 
Реter Konow #:
...
4.vis.editorの概念的基礎はよく練られており、技術的基礎は4年前に書かれテストされました。このエディタは最初のリリースの入り口に立っていると言える。
この点は詳しく述べる価値がある。

ビジュアル・エディター（VE）は必要最小限の機能を実装する必要がある。それが何であるか、一般的に考えてみよう。

VEの機能的基礎

1.編集要素と編集可能要素の相互作用。

2.グラフィカル・コアのスタッフ・エリアとユーザー・エリアへの分離。編集要素と編集可能要素はカーネルの異なる部分にあるべきで、前者はスタッフ・エリアに、後者はユーザー・エリアにある。

3.エレメントやウィンドウを作成したり削除したりする機能は、カーネルのユーザー部分で動作し、標準部分のエレメントから呼び出されるようにする。

4.GUI編集後にカーネルのカスタム部分を保存する機能。

5.保存したカーネルの一部（プロジェクト）をファイルからロードし、プロジェクトの再設計や改良を行うこと。


これは動作するエディタとして最低限必要なものです。


すでに実装されているもの

1.エディターと編集可能な要素の相互作用。

エディターには、Target_objectとTarget_propertyの2つのプロパティがあります。ユーザーが編集可能な要素をクリックすると、その要素に特別なフォーカスが当たります。その瞬間、エディタ要素はTarget_propertyプロパティに従って編集可能要素のプロパティ値をパラメータに取り込み、もう一つの特別なプロパティであるOutput_propertyを通して出力します。つまり、Target_propertyが要素の色である場合、Output_propertyは編集可能要素の色の名前を表示するテキストか、エディタ要素のベースカラーになり、それに応じて変化します。

これらの要素の相互接続には多くのバリエーションがありますが、技術的な実装は難しい作業ではなく、非常に簡単です。

2- コンストラクタは独自の内部APIファイルを持つようになり、ラッパー関数やGUIイベントを使用して、独自のカスタマイズウィンドウの機能を簡単に使用できるようになりました。

3.また、コンストラクタは、kib-code解釈プロセスをバイパスしてカーネルから直接ロードする方法と、kib-code解釈プロセスを経由して標準的にロードする方法の2つの方法でロードできます。このおかげで、チャート上でコンストラクタをロードする時間は〜1.5秒から〜16〜32ミリ秒に短縮された。また、カーネル・ファイルからのロードのおかげで、kib-codeに関連する警告を取り除くことができた。しかし、おそらくこれは展望に比べればほんの些細なことだろう。レディ・カーネルからロードする主な利点は、他のファイルからレディ・カーネル部分を「トップ・オフ」できる可能性である。これは一歩先の話である。

4.コンストラクタのフォルダとファイルは完全に英語に翻訳されています。アーキテクチャーは大きく変わった。

私の主な目標は、マークアップ言語をバイパスして、内部からエディタを構築できるエディタの最小限の機能を作ることです。

 
先に、次回リリースの期限を11月28日とお知らせしました。ビジュアルエディターへの方向転換のため、アップデートの公開を12月10日に延期しなければなりません。それ以外は、以前承認されたプログラムに変更はありません。エディターがkodobaseにアップロードされ、テンプレート・ブランチが開設され、最初の記事が書かれます。

最後の2点について説明しておきます。

1) UI window templates branch は意図したとおりにオープンされますが、GUI 画像と kib-code フラグメントの代わりに、GUI 画像と、エディタでテンプレートを再現するために必要な技術情報とカーネルフラグメントを含む UIDATA ファイルが掲載されます。

2) リリース後、エディタについての記事を書きたいと思っています。その中で、始めるために必要な情報を紹介します。将来、エディターの話題が出尽くし、興味と需要があれば、グラフィカル・インターフェイスを 持つトレーディング・アプリケーションに関する記事を公開することができるだろう。

このように、計画に変更はほとんどない。日付とトピックだけである。

追伸：私の決断は正しかったと思う。

私の主な目標は、需要を喚起し、エディターを人気のあるツールにすることだ。これはマークアップ言語では達成するのがはるかに難しい。私はすでにこのスレッドのページでそれを見る機会を得た。コード、画像、チュートリアルを公開し、さらに努力し、結果が変わって、人々がこの言語を学ぶために殺到することを期待する......。いや、意味がない。

エディターがもっと便利になることを願っている。いずれわかるよ。:)

 
Реter Konow グラフィカル・インターフェイスを 持つトレーディング・アプリケーションに関する記事を公開することができるだろう。

このように、計画に変更はほとんどない。日付とトピックだけである。

追伸：私の決断は正しかったと思う。

私の主な目標は、需要を喚起し、エディターを人気のあるツールにすることだ。これはマークアップ言語では達成するのがはるかに難しい。私はすでにこのスレッドのページでそれを見る機会を得た。コード、写真、チュートリアルを公開し、さらに努力して、結果が変わって、人々がこの言語を学ぶために殺到することを期待する......。いや、意味がない。

エディターがもっと便利になることを願っている。いずれわかることだ。）

エディターの方がより多くの人に使ってもらえると思います。ほとんどの人は技術的なことは分からないし、結果を出すための簡単な方法を求めている。

エディターは素晴らしいアイデアだと思う。ライブラリとして市販することもできるだろう。あなたが多くの時間と労力を費やしているのだから、そのようなものを無料で利用できるようにするのは犯罪的だと思う。

私は、あなたがエディターになるという決断を全面的に支持する
1...676869707172737475767778798081...83
新しいコメント