Gallery of UIs written in MQL - page 79

New comment
 
Реter Konow #:
I agree, but we need to get to that point. One person has already volunteered to be a beta tester on the thread pages, hopefully there will be others, but it's too early. Sometime within the next month the initial testing of the editor will become relevant. There is still a lot of routine work that slows things down considerably. All those property sheets, template groups, tab and group assignments, design decisions, minor bugs... but, nobody said it would be easy).

In any case, you spend time on a product that fulfils its purpose, unlike a lot of other people here writing the same EAs with no guarantee of results.

 
Реter Konow #:
Why there is no point in developing the markup language direction further:

1. High entry threshold.

For users to be able to build complex panels they need to know the rules of the language. But they will be able to know them only after studying ~20 tutorials that I need to write in the next 6-7 months.

I think there is some mistake in this, after all, the one who will use the developed basis is not an ordinary user, and for a developer the need to learn the principles of technology application is a normal phenomenon

 
Aleksey Vyazmikin #:

In any case, you spend your time on a product that fulfils its purpose, unlike a lot of other people here who write the same advisors with no guarantee of results.

Yes, my product fulfils the task, but it has no sense without people writing EAs without a guarantee of results. So, I can't criticise them, let them keep writing).
 
Реter Konow #:
Yes, my product fulfils the task, but it is meaningless without people writing advisors without guaranteeing the result. So, I can't criticise them, let them keep writing).

It's not about criticism, it's about the joy of achieving a tangible result.

 
Kuzma Shevelev #:

I think there is some mistake in this, after all, the one who will use the developed basis is not an ordinary user, and for the developer the need to learn the principles of technology is normal

For a developer, absolutely. However, objectively looking at the experience of the authors of articles and GUI libraries, one can't help but notice some difficulty of popularisation they had to face. For some reason not quite clear to me, this topic does not capture the attention of the general public. Perhaps because the percentage of strong developers is not high, but it is also likely that the complexity of large libraries and articles scares someone. Let's face it - OOP is not a simple abstraction and when it stands in the way, one's motivation is tested.

My markup language is of course much simpler than the OOP concept, but it also requires a presentation broken down into parts and stretched over months. In terms of popularising anything, this is a very inefficient approach. So I've come to the conclusion that a markup language will almost inevitably suffer the same fate as graphical libraries.

In contrast, a visual editor inside the trading platform is a new way. It hasn't been done here before. So there is hope that it will have a different fate.

 
Aleksey Vyazmikin #:

It's not about criticism, it's about the joy of achieving a tangible result.

In this respect, I agree, but in the absence of demand, this joy instantly disappears and emptiness remains. So now I am in the same situation as people who write advisors without guaranteeing the result. In the same boat, so to speak.
 
Реter Konow #:
For the developer, of course. However, looking at the experience of the authors of the articles and GUI libraries, one can't help but notice a certain difficulty of popularisation that they had to face. For some reason not quite clear to me, this topic does not capture the attention of the general public. Perhaps because the percentage of strong developers is not high, but it is also likely that the complexity of large libraries and articles scares someone. Let's be frank - OOP is not a simple abstraction and when it stands in the way, a person's motivation is tested.

My markup language is of course much simpler than the OOP concept, but it also requires a presentation broken down into parts and stretched over months. In terms of popularising anything, this is a very inefficient approach. That's why I've come to the conclusion that markup language will almost inevitably repeat the fate of graphical libraries.

In contrast, a visual editor inside the trading platform is a new way. It hasn't been done here before. So there is hope that it will have a different fate.

Nowadays most of the advanced interfaces are developed programmatically, and it gives very good results, besides writing a library will take much less time than developing a complete graphical editor, the main thing is just to come up with a convenient software interface that would be easy to use

I think you could be inspired by React Native.

 
Kuzma Shevelev #:

Nowadays most of the advanced interfaces are developed programmatically, and it gives very good results, besides writing a library will take much less time than developing a complete graphical editor, the main thing is just to come up with a convenient software interface that would be easy to use

I think you could be inspired by React Native.

I'm not going to argue, just an opinion.

In the evolution of GUI development, class or function libraries occupy the first step of the three existing ones - graphical library, markup language and visual editor.

The library allows the developer to create controls in the most time-consuming way, but it is worth noting that it allows maximum creative freedom (designed only for VERY experienced developers).

The markup language is the middle link in this chain. It combines convenience and ease with a wide range of features. However, it inherits from libraries one of their main disadvantages - the need to fully compile the programme to check every slightest change. If you change the colour of an element - compile it, if you want to check something - recompile it. Changed the font? - recompile. Moved the position? Write different text? - recompile, recompile, recompile.

However, the markup language is indispensable when large groups of multiple elements are created and properties are set en masse. It makes this process very convenient. Much easier than in a library. Plus, the little syntax, intuitiveness and uncomplicated rules ensure much faster understanding than in the case of libraries.

The visual editor is the highest level. It combines all the advantages of the markup language, but raises them to a new level, which is beyond the reach of libraries. When working in the editor, all changes are visible at once. Recompilation is not necessary. It is not inferior to, but surpasses the markup language in capabilities. The top.

And objectively, there is not much left to this peak... compared to the distance travelled so far.

 
Although I do not use any graphics in my EAs, and EAs give very tangible financial results, I follow the topic with interest and wish the author success from the bottom of my heart!
 
JRandomTrader #:
Although I do not use any graphics in my EAs, and EAs give very tangible financial results, I follow the topic with interest and wish the author success from the bottom of my heart!
Thank you very much!


1...7273747576777879808182
New comment