Gallery of UIs written in MQL - page 74

New comment
 
Vitaliy Kostrubko #:

_/\_, I'd love to be a Beta tester :)

Thanks for the initiative!

It will definitely help to improve the quality of technical implementation. But I must say at once, the code of the designer or editor is not subject to discussion. Only the work of functionality and compliance with user requirements. This is a prerequisite. If you agree, everything will go "on rails". :)
 
Vitaliy Kostrubko #:

... HOW to make similar 2-3 line captions on buttons in your GUI --> without kanvas, or WITH kanvas

Will.
 
A carefully considered strategic decision was made to fully focus on restoring the functionality of the visual editor. According to rough estimates, it will be able to become minimally complete and practically applicable in the next 3 weeks. Further only development and improvement.

I will explain the reasons for this decision further.
 
Vitaliy Kostrubko #:

... Speaking of content (for "ideas for the future") :

I'm currently "trying my hand" at designing a panel directly from Terminal objects: Button and Text Label,

and encountered this situation : -->


--> For "myself" - to avoid confusion in Buttons - I decided to sign the button "detail" itself. and accordingly - it was necessary to make the inscription not in the button itself (as the inscription will appear in the middle of the button height), but in the form of "superimposed" text on the button (!)
. That's why the inscription turned out to be 2-line:

hence the premise to voice this situation - in case in the future, you "invent" a way - HOW to make such 2-3 line captions on buttons in your GUI --> without or with kanvas --

right? :-)

without GUI editors :-)

or like this...

or this.

:-)

just for the record and I had 10 minutes to spare...

 
Why there is no point in developing the markup language direction further:

1. High entry threshold.

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

2. It is impossible to fully use GUI templates without knowledge of language rules.

Knowledge is obtained from tutorials, and the materials are printed in articles. Articles are published at intervals of one or two per month. To complete a full course of study it is necessary to publish at least 7 - 10 articles, and at this rate the process will take ~ half a year.

The conclusion from the above arguments is that it makes sense to publish templates only after articles are published. Without practical knowledge of the language, users will not be able to modify kib-code templates to suit their needs, which will significantly reduce their usefulness. As a result, users will turn to me for explanations and help. I can help one or two people, but if there are more, we will be at a dead end.




Now, why it makes a lot of sense to develop a visual editor.

1. Low threshold of entry for users.

The visual editor has the advantage of being intuitive. Its capabilities and limitations are easily recognised by exploring its graphical interface. Adding tooltips helps in understanding complexities.

2. Small amount of required training material to get started in the visual editor.

The whole course can be fit into 3 - 5 articles. But even without them users will quickly learn how to create simple and complex panels.

3. The editor simplifies and speeds up GUI creation as much as possible.

The difference between the effort of working with a markup language and a visual editor is huge. This factor finally tipped the scales in favour of the visual editor. The low amount of effort required favourably influences the interest of users to create GUI trading applications.

4. The conceptual basis of the visual editor is well thought out, and the technical base was written and tested 4 years ago. We can say that objectively, the editor is on the threshold of its first release.
 
Maxim Kuznetsov #:

right? :-)

this is without GUI editors :-)

or so.

or this

:-)

I'm just saying, and I had 10 minutes to spare...

Of course, there will be people who want to use third-party programmes to build GUI and connect it via DLLs, that's fine.

It's everyone's choice.
 
Реter Konow #:
...
4. The conceptual basis of the vis.editor is well thought out, and the technical basis was written and tested 4 years ago. We can say that the editor is on the threshold of its first release.
This point is worth to be stated in details.

The Visual Editor (VE) requires the minimum necessary functionality to be implemented. Let's consider in general what it is.

Functional basis of VE:

1. Interactions of editing and editable elements.

2. Separation of the graphical core into a staff and user area. Editing and editable elements should be in different parts of the kernel, the former in the staff area, the latter in the user area.

3. Functions of creating and deleting elements and windows should work with the user part of the kernel, and be called by elements from the standard one.

4. Functionality of saving custom part of the kernel after GUI editing.

5. Loading the saved part of the kernel (project) from a file, for redesigning and refining the project.


This is the necessary minimum for a working editor.


What is already implemented:

1. Interaction of editors and editable elements.

Editors have two specific properties: Target_object and Target_property. When the user clicks on an editable element, it comes into a special focus. At that moment, editor elements take the property values of the editable element into their parameters according to their Target_property property and output them through their other special property, Output_property. That is, if Target_property is the colour of the element, then Output_property can be either text displaying the name of the colour of the editable element, or the base colour of the editor element, which changes accordingly.

There are many variants of interconnection of these elements, but the technical implementation is not a difficult task and is quite simple.

2- The constructor now has its own internal API file, which makes it easy to use the functionality of its own customisation windows using wrapper functions and incoming GUI events.

3. Also, the constructor can be loaded in two ways - from the kernel directly, bypassing the kib-code interpretation process, or standardly, via kib-code interpretation. Thanks to this, the time of loading the constructor on the chart has dropped from ~1.5 seconds to ~16 - 32 milliseconds. Also, thanks to loading from the kernel file we managed to get rid of warnings related to kib-code. But perhaps this is just a trifle compared to the prospects. The main advantage of loading from a ready kernel is the possibility to "top off" ready kernel parts from other files, which can be templates of windows or groups of elements necessary for user's work. This is one step away.

4. Folders and files of the constructor are fully translated into English. The architecture has undergone huge changes.

My main goal is to create the minimum functionality of the editor that allows you to build the editor from the inside out, bypassing the markup language.

 
Earlier I announced the deadline for the next release - 28th of November. Due to the reorientation to the visual editor, I have to postpone the publication of the update to the tenth of December. Otherwise, the previously approved programme remains unchanged. The editor will be uploaded to kodobase, the templates branch will be opened and the first article will be written.

The last two points should be explained.

1) The UI window templates branch will be opened as intended, but instead of GUI pictures with kib-code fragments, GUI pictures will be posted along with UIDATA files containing technical information and kernel fragments necessary to reproduce templates in the editor.

2) After the release I hope to write an article about the editor. In it I will present the necessary information to get started. In the future, when the topic of the editor will be exhausted, and if there is interest and demand, I can release articles about trading applications with graphical interface.

Thus, almost nothing has changed in the plans. Only the date and the topic.

P.S. I think I made the right decision.

My main goal is to ignite demand and make the editor a popular tool. This is much harder to achieve with a markup language. I have already had an opportunity to see it on the pages of this thread. Repeat this way - publish codes, pictures and tutorials - but with even more efforts and expect that the result will be different and people will rush to learn the language..... No. No point.

I hope the editor will be more useful. We'll see, though. :)

 
Реter Konow #:
Earlier I announced the deadline for the next release - 28th of November. Due to the reorientation to the visual editor, I have to postpone the publication of the update to the tenth of December. Otherwise, the previously approved programme remains unchanged. The editor will be uploaded to kodobase, the templates branch will be opened and the first article will be written.

The last two points should be explained.

1) The UI window templates branch will be opened as intended, but instead of GUI pictures with kib-code fragments, GUI pictures will be posted along with UIDATA files containing technical information and kernel fragments necessary to reproduce templates in the editor.

2) After the release I hope to write an article about the editor. In it I will present the necessary information to get started. In the future, when the topic of the editor will be exhausted, and if there is interest and demand, I can release articles about trading applications with graphical interface.

Thus, almost nothing has changed in the plans. Only the date and the topic.

P.S. I think I made the right decision.

My main goal is to ignite demand and make the editor a popular tool. This is much harder to achieve with a markup language. I have already had an opportunity to see it on the pages of this thread. Repeat this way - publish codes, pictures and tutorials - but with even more efforts and expect that the result will be different and people will rush to learn the language..... No. No point.

I hope the editor will be more useful. We'll see, though. :)

I think the editor is a better choice for a wider audience. Most people are not technical and want an easy way to produce results. 

I think the editor is a great idea and if you pull it off it would be fantastic. You could even sell it as a library on the market. It seems criminal such a thing would be made available for free as you are putting so much time and effort into it. 

I fully support your decision to do a editor 
 
Levi Dane Benjamin #:
...

I think the editor is a better choice for a wider audience. Most people are not technical and want an easy way to get results.

I think the editor is a great idea and if you implement it, it would be fantastic. You could even sell it as a library on the market. It seems criminal that such a thing should be available for free, after all you put so much time and effort into it.

I fully support your decision to make an editor
Thank you for your valuable support! It's important for me to know other people's opinions so that I don't get lost in my conclusions..... and make the right choice.

You know, I've made a decision for myself not to think of a visual editor as something fantastic. I've noticed that I subconsciously see the editor as less achievable. So I try to look at it as a work routine. It makes it easier for me to create it that way. It's just mind games. :)

About free distribution, it's a considered decision. There is no other way now. I won't monetise the editor itself, that's for sure. But maybe in the future, if there is a demand, I will come up with some paid feature. We'll see. :)
1...67686970717273747576777879808182
New comment