キャンバスがカッコいい! - ページ 55 1...484950515253545556575859606162...93 新しいコメント Реter Konow 2020.01.22 12:18 #541 Roman: Borlandを思い出すと、GUIはビジュアルエディターで組み立て、コントロールのレイアウトをパネルに追加し、ハンドラを書くという流れでした。 もし、MEにこのようなビジュアルモードでレイアウトを構築する機能があれば、グラフィカルなアプリケーションの構築がより容易になるはずです。 GUI構築を学んだ現代のプログラマの大半は、ビジュアルなGUIエディタに慣れた（と教えられた）。 また、純粋なC言語スタイルのコードでグラフィカルなアプリケーションのレイアウトを構築することは、彼らにとってはほとんど興味のないことなのです。もう筋金入りのCスタイルなので。 グラフィカルなアプリケーションを構築するためには、ビジュアルエディターが必要です。そうすれば、人々はそれを習得しようとするでしょうし、VSやRadStudioで仕事をしていた人たちは、すぐにビジュアルエディターを使いこなせるようにさえなるのです。 ここで、すでにMQLにそのようなビジュアルエディタのプロトタイプがあった。しかし、人々は猛烈に反対した。トレーディングでは必要ないとのことでした。 総じて、精一杯の戦意喪失であった。そのため、地域が本当に必要としているものがわからないのです。 Реter Konow 2020.01.22 12:34 #542 Алексей Барбашин:回収能力の必要性を全面的に支持します...。それが必要なのかどうかは別問題です。開発者自身は、ターミナルをトレーディングツールと捉えているのか、それともプログラミングツールと捉えているのか、気になるところです。この時点で間違っているかもしれませんが、私はいつも、MEはユーザーが取引に必要とする機能を正確に実装するために設計されていると考えています。まさにトレーディングでも、最近のMEのプログラミングの深さは、本当にサイコロを「作る」能力が必要な領域まで行っていて、プログラミングに対する理解もかなり本格的になってきています......。そして、それが最終的に何につながるのか。それは、高度な取引ツールは経験豊富なプログラマーにしか使えないということにつながるのですつまり、プログラマーでなければ、トレーディングでやることがない...。しかし、これは無茶な話だ。MEはあくまで足りない機能を補うためのアシスタントであり、本来は端末自体に組み込むべきもの（別のウィザード）なのです。そして実際、MEは今、新しい開発環境として進化しており、ユーザーにはより多くの知識が要求されるようになっています。この結論から、可視化ツールは必要だが、その利用はプログラミングの深い知識を持たないユーザーでも可能であるべきだ。この場合のみ、需要があることになります。これはあくまで私の意見であり、誰かに押し付けるものではありません。 CCanvasクラスで 考えると、グラフィカルプリミティブを描画する機能が20個ほどあります。ユーザーがそれらをすべて知っていて、OOPのルールとシンタックスを知っているとします。しかし、彼のデータを最もシンプルに視覚化するには、あまりにも少なすぎる。ボタンという最もシンプルなコントロールの作成は言うまでもありません。つまり、キャンバス上にプリミティブを描くのは比較的簡単ですが、それを使ってビジュアライゼーションやGUIを作るのは、かなり難しいのです。そして、知識がなければ、ここではできない。開発者の才能がなければ、ここではできないのです。しかし、どれだけの人が持っているのでしょうか？それが重要な問題なのです。 Kanvas クラスの可能性を利用するには、グラフィカルプリミティブをより複雑なオブジェクト（コントロール）に組み合わせ、その操作をイベントドリブンモデルと結合し、関数を用いて関係を記述できるようにする必要があります...。あるいは、数値データをさまざまなグラフ曲線に変換する...。これは、才能があり、非常に勤勉なユーザー向けの仕事です。実は、ユーザーではなく、開発者なんです。 Roman 2020.01.22 12:44 #543 Реter Konow:ここで、すでにMQLにそのようなビジュアルエディターのプロトタイプがあった。しかし、人々は猛烈に反対した。トレーディングでは必要ないとのことでした。総じて、精一杯の戦意喪失であった。そのため、地域が本当に必要としているものがわからないのです。 へぇー、原型があるんですね。 では、開発者はコミュニティの浅はかな意見を再考すべきなのでは？そして、ビジュアルモードの開発計画を復活させること。 もちろん、本来は高い人気を誇る機能を萎縮させるのは、ちょっと変な話です。 C言語でグラフィカル・インターフェースを 構築する方法を教えているところは、今はまだほとんどないでしょう。 今や誰もがビジュアルモードのIDEで作業することを教わり、MT5が単なる取引プラットフォームを越えて久しいので、 グラフィカルなアプリケーションを構築するビジュアルモードが大いに求められているのでしょう。 正直、開発者が短絡的な反対意見に耳を傾けたことにショックを受けています。 Алексей Барбашин 2020.01.22 12:53 #544 Реter Konow: CCanvasクラスで考えると、グラフィカルプリミティブを描画するための関数が20個ほど用意されています。ユーザーがそれらをすべて知っていて、OOPのルールや構文も知っているとします。しかし、そのデータを最もシンプルに可視化することまでは、あまりにも少ない。ボタンという最もシンプルなコントロールの作成は言うまでもありません。つまり、キャンバス上にプリミティブを描くのは比較的簡単ですが、それを使ってビジュアライゼーションやGUIを作るのは、かなり難しいのです。そして、知識がなければ、ここではできない。開発者の才能がなければ、ここではできないのです。でも、どれくらいの人が持っているのでしょうか？それが重要な問題なのです。 Kanvas クラスの可能性を利用するには、グラフィカルプリミティブをより複雑なオブジェクト（コントロール）に組み合わせ、その操作をイベントドリブンモデルと結合し、関数で関係を記述できるようにする必要があります...。あるいは、数値データをさまざまなグラフ曲線に変換する...。これは、才能があり、非常に勤勉なユーザー向けの仕事です。実は、ユーザーではなく、開発者なんです。 ピーター、いいこと言うね〜。 そこで、OOPに詳しくないプログラマーにも直感的に理解できるようなライブラリの作成を提唱しています。 また、これはGUIに限ったことではありません。 標準のライブラリでも、アナトリーのライブラリでも、簡単なフォームを作るのにかなりの労力が必要ですマジかよ！？例の右に一歩、左に一歩、それだけで何も動かない、細部まで理解しなければならないのです。 どの言語でも、もちろんGUIもライブラリで構築されているのですが、ひとつだけ重要なBUT!コントロールの初期セットがあり、ライブラリのコアレベルでは完全に「結びついて」おり、すべての基本的なイベントハンドラは「配線されて」おり、あとは動作やプレゼンテーションを変更したい場合に、それらをサブスクライブするだけでよいのです。 実際、標準ライブラリのアーキテクチャは非常によく考えられており、より高度なライブラリのベースとして使用することができます。 Алексей Барбашин 2020.01.22 13:03 #545 Roman: ワー、だから試作品があるんですね。 では、開発者はコミュニティの浅はかな意見を再考すべきなのでは？そして、ビジュアルモードの開発計画を復活させること。 もちろん、本来は高い人気を誇る機能を萎縮させるのはおかしい。 結局、C言語でグラフィカル・インターフェースを構築する方法を教えているところは、今でもほとんどないのです。 MT5はもはや単なる取引プラットフォームではないので、ビジュアルモードでIDEで作業することを教えています。 となると、グラフィカルなアプリケーションを構築するビジュアルモードが非常に求められることになります。 正直、開発者が短絡的な反対意見に耳を傾けたことにショックを受けています。 他にも、インジケータは100％ビジュアル、EAは80％ビジュアル、スクリプトは20％ビジュアルと、意外な要素もありますね。どう呼ぼうと、すべてが視覚的であり、その理解は表面にある。しかし、他の開発環境との連携に関する開発があり、表面上はどうなっているのか......。 どうやら他のターミナルユーザーは皆、pythonとsqlを要求しているようです。 ローマン、ピーター、ニコライ...端末の開発者は自分たちのビジョンを持っており、ソフトウェア製品の著者であり所有者である。ME機能や端末全体の開発は、市場調査に基づいているのでしょうね。 でも、私たちが話すのを止める人は誰もいませんよ :) Реter Konow 2020.01.22 13:24 #546 Алексей Барбашин: 他にも、インジケータは100％ビジュアル、EAは80％ビジュアル、スクリプトは20％ビジュアルと、意外な要素もありますね。すべてのものに視覚性があり、その理解は表面にある。しかし、他の開発環境との連携に関する開発があり、表面上はどうなっているのか......。 どうやら他のターミナルユーザーは皆、pythonとsqlを要求しているようです。 ローマン、ピーター、ニコライ...端末の開発者は自分たちのビジョンを持っており、ソフトウェア製品の著者であり所有者である。ME機能や端末全般の開発は、市場調査に基づいて行われていると思います。 でも、私たちが話すのを止める人は誰もいませんよ :) そうなんです。 私の意見は、EAのビジュアルインターフェースは、一つのアプリケーションに戦略を蓄積することを可能にし、それは市場の販売に悪影響を与えるということです。エキスパート・アドバイザーを誰でも簡単に、しかもダイナミックに作成できるようになれば（GUIで作成可能）、現在のマーケットでの回転率が下がり、売上に影響する。内部でストラテジーを統合・修正するExpert Advisorが前面に出て、設定やいくつかの条件だけが異なるクローンを排除していくでしょう。これはマーケットプレイスにとって良いことなのでしょうか？どうだろう。しかし、Expert Advisorのレベルが上がり、店頭で検証することがより面白くなるはずです。 Dmitry Fedoseev 2020.01.22 13:37 #547 Реter Konow: おそらく、ほとんどのユーザーは、CCanvas、CGrafic、CCanvas3D が、OOP の原則と構文の知識を必要とするクラスではなく、必要な視覚化を生成するアプリケーションであることを望んでいるはずです。そして、ただ知るだけでなく、ニコラスのように独自の可視化システムを構築することが本質です。 クラスを知っているだけでは不十分です。ライブラリから独自のソリューションを "低レベル "で構築できるようになる必要があります。自分自身が開発者である必要があります。そして、これはユーザーの1％に与えられるものです。 すぐに使えるビジュアライゼーション・アプリケーションが与えられれば、ユーザーは学ぶ必要がなくなりますが、その数は増えます。 必要なのか？どうだろう。 知っておきたいopの原理とは？ドットを付けて、リストからメソッドを選ぶ？ Dmitry Fedoseev 2020.01.22 13:40 #548 aleger: 続いての質問：「最もパワフル」で「最もシンプル」なMQL関数のうち、いくつとどれを使えばいいのか のエキスパートアドバ イザーを作成するのに十分な機能です。 世界の主要通貨ペアの？ そして、ここにいる誰もが頭を悩ませているRやPythonの関数って、何を書けばいいんだろう...？それにほら、あなたが座っているスツールは、それにふさわしいものですか......？ Dmitry Fedoseev 2020.01.22 13:41 #549 Roman: まあ、Borlandを思い出せば、GUIはビジュアルエディタで組み立てて、パネルにコントロールレイアウトを載せて、ハンドラを書いていくものでした。 もし、MEにこのような視覚的にレイアウトを構築する機能があれば、グラフィカルなアプリケーションの 構築を大幅に簡略化できるだろう。 GUI構築を学んだ現代のプログラマの大半は、ビジュアルなGUIエディタに慣れた（と教えられた）。 また、純粋なC言語スタイルのコードでグラフィカルなアプリケーションのレイアウトを構築することは、彼らにとってはほとんど興味のないことなのです。もう筋金入りのCスタイルなので。 グラフィカルなアプリケーションを構築するためには、ビジュアルエディターが必要です。そうすれば、人々はそれを習得しようとするでしょうし、VSやRadStudioで仕事をしていた人たちは、すぐにビジュアルエディターを使いこなせるようにさえなるのです。 なぜ、ここで必要とされるのか？ Roman 2020.01.22 13:49 #550 Реter Konow: そうなんです。 私の意見は、EAのビジュアルインターフェースにより、1つのアプリケーションにストラテジーを蓄積することが可能になり、マーケットでの販売に悪影響を与えるということです。エキスパート・アドバイザーを誰でも簡単に、しかもダイナミックに作成できるようになれば（GUIで作成可能）、現在のマーケットでの回転率が下がり、売上に影響する。内部でストラテジーを統合・修正するExpert Advisorが前面に出て、設定やいくつかの条件だけが異なるクローンを排除していくでしょう。これはマーケットプレイスにとって良いことなのでしょうか？どうだろう。でも、これからEAのレベルが上がって、ショーケースで見るのがもっと面白くなるはずです。 絶対に遠回しに言っている問題です。 戦略収集のためのビジュアルインターフェースは不要で、サイコロが必要ならtslabへ。 また、ビジュアルモードでキューブを使ったストラテジーを収集するmqlコードを生成するプログラムも見たことがあります。 取引戦略やインジケーターの開発にはビジュアルモードは必要ありません。 しかし、モジュール化されたグラフィカルなアプリケーションには、gifで示したようなビジュアルモードが有効でしょう。 1...484950515253545556575859606162...93 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
Borlandを思い出すと、GUIはビジュアルエディターで組み立て、コントロールのレイアウトをパネルに追加し、ハンドラを書くという流れでした。
もし、MEにこのようなビジュアルモードでレイアウトを構築する機能があれば、グラフィカルなアプリケーションの構築がより容易になるはずです。
GUI構築を学んだ現代のプログラマの大半は、ビジュアルなGUIエディタに慣れた（と教えられた）。
また、純粋なC言語スタイルのコードでグラフィカルなアプリケーションのレイアウトを構築することは、彼らにとってはほとんど興味のないことなのです。もう筋金入りのCスタイルなので。
グラフィカルなアプリケーションを構築するためには、ビジュアルエディターが必要です。そうすれば、人々はそれを習得しようとするでしょうし、VSやRadStudioで仕事をしていた人たちは、すぐにビジュアルエディターを使いこなせるようにさえなるのです。
ここで、すでにMQLにそのようなビジュアルエディタのプロトタイプがあった。しかし、人々は猛烈に反対した。トレーディングでは必要ないとのことでした。
総じて、精一杯の戦意喪失であった。そのため、地域が本当に必要としているものがわからないのです。
回収能力の必要性を全面的に支持します...。
それが必要なのかどうかは別問題です。
開発者自身は、ターミナルをトレーディングツールと捉えているのか、それともプログラミングツールと捉えているのか、気になるところです。
この時点で間違っているかもしれませんが、私はいつも、MEはユーザーが取引に必要とする機能を正確に実装するために設計されていると考えています。まさにトレーディング
でも、最近のMEのプログラミングの深さは、本当にサイコロを「作る」能力が必要な領域まで行っていて、プログラミングに対する理解もかなり本格的になってきています......。
そして、それが最終的に何につながるのか。それは、高度な取引ツールは経験豊富なプログラマーにしか使えないということにつながるのです
つまり、プログラマーでなければ、トレーディングでやることがない...。しかし、これは無茶な話だ。
MEはあくまで足りない機能を補うためのアシスタントであり、本来は端末自体に組み込むべきもの（別のウィザード）なのです。
そして実際、MEは今、新しい開発環境として進化しており、ユーザーにはより多くの知識が要求されるようになっています。
この結論から、可視化ツールは必要だが、その利用はプログラミングの深い知識を持たないユーザーでも可能であるべきだ。
この場合のみ、需要があることになります。
これはあくまで私の意見であり、誰かに押し付けるものではありません。
CCanvasクラスで 考えると、グラフィカルプリミティブを描画する機能が20個ほどあります。ユーザーがそれらをすべて知っていて、OOPのルールとシンタックスを知っているとします。しかし、彼のデータを最もシンプルに視覚化するには、あまりにも少なすぎる。ボタンという最もシンプルなコントロールの作成は言うまでもありません。つまり、キャンバス上にプリミティブを描くのは比較的簡単ですが、それを使ってビジュアライゼーションやGUIを作るのは、かなり難しいのです。そして、知識がなければ、ここではできない。開発者の才能がなければ、ここではできないのです。しかし、どれだけの人が持っているのでしょうか？それが重要な問題なのです。
Kanvas クラスの可能性を利用するには、グラフィカルプリミティブをより複雑なオブジェクト（コントロール）に組み合わせ、その操作をイベントドリブンモデルと結合し、関数を用いて関係を記述できるようにする必要があります...。あるいは、数値データをさまざまなグラフ曲線に変換する...。これは、才能があり、非常に勤勉なユーザー向けの仕事です。実は、ユーザーではなく、開発者なんです。
ここで、すでにMQLにそのようなビジュアルエディターのプロトタイプがあった。しかし、人々は猛烈に反対した。トレーディングでは必要ないとのことでした。
総じて、精一杯の戦意喪失であった。そのため、地域が本当に必要としているものがわからないのです。
へぇー、原型があるんですね。
では、開発者はコミュニティの浅はかな意見を再考すべきなのでは？そして、ビジュアルモードの開発計画を復活させること。
もちろん、本来は高い人気を誇る機能を萎縮させるのは、ちょっと変な話です。
C言語でグラフィカル・インターフェースを 構築する方法を教えているところは、今はまだほとんどないでしょう。
今や誰もがビジュアルモードのIDEで作業することを教わり、MT5が単なる取引プラットフォームを越えて久しいので、
グラフィカルなアプリケーションを構築するビジュアルモードが大いに求められているのでしょう。
正直、開発者が短絡的な反対意見に耳を傾けたことにショックを受けています。
CCanvasクラスで考えると、グラフィカルプリミティブを描画するための関数が20個ほど用意されています。ユーザーがそれらをすべて知っていて、OOPのルールや構文も知っているとします。しかし、そのデータを最もシンプルに可視化することまでは、あまりにも少ない。ボタンという最もシンプルなコントロールの作成は言うまでもありません。つまり、キャンバス上にプリミティブを描くのは比較的簡単ですが、それを使ってビジュアライゼーションやGUIを作るのは、かなり難しいのです。そして、知識がなければ、ここではできない。開発者の才能がなければ、ここではできないのです。でも、どれくらいの人が持っているのでしょうか？それが重要な問題なのです。
Kanvas クラスの可能性を利用するには、グラフィカルプリミティブをより複雑なオブジェクト（コントロール）に組み合わせ、その操作をイベントドリブンモデルと結合し、関数で関係を記述できるようにする必要があります...。あるいは、数値データをさまざまなグラフ曲線に変換する...。これは、才能があり、非常に勤勉なユーザー向けの仕事です。実は、ユーザーではなく、開発者なんです。
ピーター、いいこと言うね〜。
そこで、OOPに詳しくないプログラマーにも直感的に理解できるようなライブラリの作成を提唱しています。
また、これはGUIに限ったことではありません。
標準のライブラリでも、アナトリーのライブラリでも、簡単なフォームを作るのにかなりの労力が必要ですマジかよ！？例の右に一歩、左に一歩、それだけで何も動かない、細部まで理解しなければならないのです。
どの言語でも、もちろんGUIもライブラリで構築されているのですが、ひとつだけ重要なBUT!コントロールの初期セットがあり、ライブラリのコアレベルでは完全に「結びついて」おり、すべての基本的なイベントハンドラは「配線されて」おり、あとは動作やプレゼンテーションを変更したい場合に、それらをサブスクライブするだけでよいのです。
実際、標準ライブラリのアーキテクチャは非常によく考えられており、より高度なライブラリのベースとして使用することができます。
ワー、だから試作品があるんですね。
では、開発者はコミュニティの浅はかな意見を再考すべきなのでは？そして、ビジュアルモードの開発計画を復活させること。
もちろん、本来は高い人気を誇る機能を萎縮させるのはおかしい。
結局、C言語でグラフィカル・インターフェースを構築する方法を教えているところは、今でもほとんどないのです。
MT5はもはや単なる取引プラットフォームではないので、ビジュアルモードでIDEで作業することを教えています。
となると、グラフィカルなアプリケーションを構築するビジュアルモードが非常に求められることになります。
正直、開発者が短絡的な反対意見に耳を傾けたことにショックを受けています。
他にも、インジケータは100％ビジュアル、EAは80％ビジュアル、スクリプトは20％ビジュアルと、意外な要素もありますね。どう呼ぼうと、すべてが視覚的であり、その理解は表面にある。しかし、他の開発環境との連携に関する開発があり、表面上はどうなっているのか......。
どうやら他のターミナルユーザーは皆、pythonとsqlを要求しているようです。
ローマン、ピーター、ニコライ...端末の開発者は自分たちのビジョンを持っており、ソフトウェア製品の著者であり所有者である。ME機能や端末全体の開発は、市場調査に基づいているのでしょうね。
でも、私たちが話すのを止める人は誰もいませんよ :)
他にも、インジケータは100％ビジュアル、EAは80％ビジュアル、スクリプトは20％ビジュアルと、意外な要素もありますね。すべてのものに視覚性があり、その理解は表面にある。しかし、他の開発環境との連携に関する開発があり、表面上はどうなっているのか......。
どうやら他のターミナルユーザーは皆、pythonとsqlを要求しているようです。
ローマン、ピーター、ニコライ...端末の開発者は自分たちのビジョンを持っており、ソフトウェア製品の著者であり所有者である。ME機能や端末全般の開発は、市場調査に基づいて行われていると思います。
でも、私たちが話すのを止める人は誰もいませんよ :)
そうなんです。
私の意見は、EAのビジュアルインターフェースは、一つのアプリケーションに戦略を蓄積することを可能にし、それは市場の販売に悪影響を与えるということです。エキスパート・アドバイザーを誰でも簡単に、しかもダイナミックに作成できるようになれば（GUIで作成可能）、現在のマーケットでの回転率が下がり、売上に影響する。内部でストラテジーを統合・修正するExpert Advisorが前面に出て、設定やいくつかの条件だけが異なるクローンを排除していくでしょう。これはマーケットプレイスにとって良いことなのでしょうか？どうだろう。しかし、Expert Advisorのレベルが上がり、店頭で検証することがより面白くなるはずです。
おそらく、ほとんどのユーザーは、CCanvas、CGrafic、CCanvas3D が、OOP の原則と構文の知識を必要とするクラスではなく、必要な視覚化を生成するアプリケーションであることを望んでいるはずです。そして、ただ知るだけでなく、ニコラスのように独自の可視化システムを構築することが本質です。
知っておきたいopの原理とは？ドットを付けて、リストからメソッドを選ぶ？
続いての質問：「最もパワフル」で「最もシンプル」なMQL関数のうち、いくつとどれを使えばいいのか
のエキスパートアドバ イザーを作成するのに十分な機能です。
世界の主要通貨ペアの？
そして、ここにいる誰もが頭を悩ませているRやPythonの関数って、何を書けばいいんだろう...？それにほら、あなたが座っているスツールは、それにふさわしいものですか......？
まあ、Borlandを思い出せば、GUIはビジュアルエディタで組み立てて、パネルにコントロールレイアウトを載せて、ハンドラを書いていくものでした。
もし、MEにこのような視覚的にレイアウトを構築する機能があれば、グラフィカルなアプリケーションの 構築を大幅に簡略化できるだろう。
GUI構築を学んだ現代のプログラマの大半は、ビジュアルなGUIエディタに慣れた（と教えられた）。
また、純粋なC言語スタイルのコードでグラフィカルなアプリケーションのレイアウトを構築することは、彼らにとってはほとんど興味のないことなのです。もう筋金入りのCスタイルなので。
グラフィカルなアプリケーションを構築するためには、ビジュアルエディターが必要です。そうすれば、人々はそれを習得しようとするでしょうし、VSやRadStudioで仕事をしていた人たちは、すぐにビジュアルエディターを使いこなせるようにさえなるのです。
なぜ、ここで必要とされるのか？
そうなんです。
私の意見は、EAのビジュアルインターフェースにより、1つのアプリケーションにストラテジーを蓄積することが可能になり、マーケットでの販売に悪影響を与えるということです。エキスパート・アドバイザーを誰でも簡単に、しかもダイナミックに作成できるようになれば（GUIで作成可能）、現在のマーケットでの回転率が下がり、売上に影響する。内部でストラテジーを統合・修正するExpert Advisorが前面に出て、設定やいくつかの条件だけが異なるクローンを排除していくでしょう。これはマーケットプレイスにとって良いことなのでしょうか？どうだろう。でも、これからEAのレベルが上がって、ショーケースで見るのがもっと面白くなるはずです。
絶対に遠回しに言っている問題です。
戦略収集のためのビジュアルインターフェースは不要で、サイコロが必要ならtslabへ。
また、ビジュアルモードでキューブを使ったストラテジーを収集するmqlコードを生成するプログラムも見たことがあります。
取引戦略やインジケーターの開発にはビジュアルモードは必要ありません。
しかし、モジュール化されたグラフィカルなアプリケーションには、gifで示したようなビジュアルモードが有効でしょう。