帆布很酷! - 页 51

 
Nikolai Semko:


我说的是MT及其图表的外观和感觉,以及用户的图形库。主 要是缺乏抗锯齿的图形和通过窗口菜单界面选择各种选项和设置。

另一方面,这在事实上也没有什么区别。就重要性而言,大约在第二十位。

这就是说,我绝不接受设计或图形有问题的说法。
 
Nikolai Semko:

谢谢,阿列克谢。
几乎都是如此。谢谢你对这个问题的关注。

Kanvas对我个人来说只是一种爱好和休闲活动。我不承担开发新的图形库和GUI的负担,因为这不再是一个爱好,而是一个耗时的工作。虽然如果问题出现了,我可能会做得很好。

在我看来,MT在图形和视觉化方面远远落后。至少落后10年。很遗憾,这个领域在MQ团队的优先名单上并不占优势。对于企业来说,包装有时起着决定性的作用。

是的,尼古拉,我知道画布是你的爱好!我真的希望它能保持这种状态,因为正是在这个爱好中,我们投入了真正的灵魂和知识。我相信,新的GUI库不会太久,它将以你的例子为基础!所以,我希望你在这方面不要停下来。

有一个小小的要求,如果你有心情的话:在你的一个例子中,你在画布上画了 "表格",可以拖放每一个表格。尝试为这些形状添加 "关闭 "按钮,当它们成为焦点时改变其颜色。或者在主动(可拖动状态或前台)和被动(背景)中改变这些相同 "表格 "的 "标题"。

这将是一个改变画布特定区域而不重绘整个画布的绝佳例子。

我再说一遍:如果你有兴致和愿望!你就会知道。:)

 
Renat Fatkhullin:

我们没有落后,相反,我们远远领先于(所有)其他平台。画布+OpenCL+完整的DirectX开箱即用--这是不是落后了?

但问题是,"能玩 "的人的圈子很窄。大多数交易者不会超越标准技术指标的阶段。


现在我们要发布与编辑器中的Python的集成,以及与服务的脚本。你将能够在终端中直接运行Python程序作为脚本,这将使你能够轻松地将你的分析发展转移到MT5。这些是脚本,不是专家顾问 - 它们不能在测试器中运行。

我们的工作主要是关于数据库和集合的运作。我们正在增加新的数据库XXXX功能。我们不仅要扩展常规的SQLite功能,还要在编辑器中启动SQLite浏览器。

也许我们会把WinML 纳入MQL5语言的标准功能,以便能够运行ONNX训练的模型。如果Python中的TensorFlow还不够的话。

总而言之,我们正在走建立一个数据分析工作室的道路。

Renat,我们都知道,在mql环境中,许多开发人员仍然不会跳出程序化设计,对他们来说,OOP就像一块红布,对公牛来说,你说的是python(甚至更早的是sharp)。Python、Sharp都绝对是OOP,这就是为什么人们不愿意掌握它。但一切都有其时间,冰块会被打破。人们仍然无法摆脱MT4。

在这个场合,我想表达一个非常小的愿望:把工具从ex4自动转换成ex5格式。许多用户(不是开发者)不会因为他们最喜欢的,也许是曾经买过的工具只能在MT4上使用而转到MT5。我确信,如果有一个自动转换器,甚至如果它是终端本身的一部分就更好了,它可以帮助用户从一个终端切换到另一个终端,这将增加MT5的普及。

 
Алексей Барбашин:

....,你说的是Python(或更早的Sharp)。Python、Sharp都是毫不含糊的OOP,所以人们并不热衷于学习它。

不代表所有的人...

我只是不想用手鼓跳舞,否则他们早就写好了,因为互联网上有很多有趣的东西,而且是用python写的。
 

当我读到 "这能在哪里应用?"这样的短语时,我对这种纯粹的、在我看来是短视的做法感到震惊。那些问这个问题的人是在没有任何指标和专家顾问的情况下完全使用终端吗?

我假设有这样的人,当然,但他们是非常少的。其余的人则使用专家顾问或指标。

指标是一种将数据可视化的先验工具!

专家顾问至少可以将建议可视化。

这两种工具都是从事信息的可视化工作。而这正是尼古拉在他的伟大的例子中向我们展示的可视化的能力!

而事实上,许多人缺乏将其付诸实践的想象力......那么,问题其实并不在于想象力,而在于缺乏具体的需求。

只不过,人们不应该把 "个人缺乏需求 "推测为 "普遍缺乏需求"。

顺便说一句,尼古拉,至少有一个控件我已经在你的例子中注意到了。"滑块",在SLAU解决方案的例子中实现了,与"滚动条"工具只有一步之遥。

 
Renat Akhtyamov:

但不代表所有人...

我只是不喜欢用手鼓跳舞,否则我们早就写好了,因为互联网上有很多有趣的东西,而且是用python写的。

我说过 "所有 "吗?不,我只是说 "许多" ))所以不要把它当做个人问题。让我们一起生活!

 
一个直接来自破碎记录的惊人故事的夜晚已经开始。

现实中的问题是,人们真的无法进入更高的层次。你对此无能为力。


这就是复杂性问题的模样。


这个过程的复杂程度和功能不断发展,因为较低的级别由于要求增加而不能提供解决方案,或者在经济上根本不可行。这就是那种防止走回头路的进步。

当然,整个阶层的交易者甚至不知道他们在说什么,平庸地掉了下来。而要教育他们几乎是不可能的--只有微不足道的人愿意投入数千小时的培训,这是痛苦的原因。

这就是为什么有的人不知道问题,却打着旗号为下级呼吁。打倒进步!


我们正在为那些以下人士开发机会
  1. 在市场上为他人创造应用
  2. 为自己创造了更复杂的解决方案
 
Алексей Барбашин:

当我读到 "这能在哪里应用?"这样的短语时,我被这种纯粹的、在我看来是短视的做法惊呆了。那些问这个问题的人是在没有任何指标和专家顾问的情况下完全使用终端吗?

我假设有这样的人,当然,但他们是非常少的。其余的人则使用专家顾问或指标。

指标是一种将数据可视化的先验工具!

专家顾问至少可以将建议可视化。

这两种工具都是从事信息的可视化工作。而这正是尼古拉在他的伟大的例子中向我们展示的可视化的能力!

而事实上,许多人缺乏将其付诸实践的想象力......那么问题就不是真正的想象力,而是缺乏具体需求。

只不过,人们不应该把 "个人缺乏需求 "推测为 "普遍缺乏需求"。

顺便说一句,尼古拉,至少有一个控件我已经在你的例子中注意到了。"滑块",在SLAU解决方案的例子中实现了,与 "滚动条 "工具只有一步之遥。

尼古拉所做的,每个男孩在开始学习编程时都会做。

 
ME正在整合语言,这很好。

任何需要帆布GUI的人,我都会把我的建造者交给社区。我有时间的话,会把它刷起来,然后贴出来。憋在心里有什么用呢?

但是,如果尼古拉愿意,就让他写自己的图书馆。我决不是在劝阻它。只是,这项工作和我以及阿纳托利的工作一样,注定没有什么人问津。这就是现实。
 

雷纳特,你提到了终端能力的又一次扩展--这很好,真的!"。

目前,许多需求都是通过标准库来 解决的。但我认为,许多开发者会同意我的观点,即其中一些需求如果在平台本身的核心层面上实现,看起来会更好。

例如,去年描述的相同的SQLite处理或并行进程,并附有额外的图表...- 这样的功能应该在平台本身而不是标准库中实现。