Crowdsourced GUI. Open beta testing. - page 8
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
that it all goes to the usual style setting. There are certain moments, such as the link button, the hover button, the click button, and just the button. And for each moment they usually make their own styles, or a mixture of them.
To tell the truth, I've always misunderstood in such things how to arrange the settings of executed code for a button. So that it would be also visual. And also with its own checks of the code for errors.
A vivid example of such a work would be creating a menu for creating a menu. That is, if graphically it will be possible to make the left or right menu with embed code so to speak on the fly.
Or is it just generating buttons in code....?
Setting up the styles is just the beginning of editing. Next, the number of features will grow in an avalanche-like fashion. The main task is to drag and drop the basic features of the markup language into the visual editor. It's not hard to do. I'd say there's a kind of breakthrough at the visual level, like breaking through a supersonic barrier. It's hard to describe... - It's like, the possibilities were locked up under a lock and now, when you go to visual, the door to them has opened and they're piling up. Just time to implement.
Upcoming tasks:
1. Adding windows.
2. Removing elements.
3. Creating a new tool - blue frame.
4. Copying elements within the window.
5. Extending the editing focus.
6. Adding editing targets.
7. Selecting and loading saved projects.
8. Upgrading the engine.
...
//------------------------------------------------
The code is not essentially generated. A kernel containing the elements in the numerical description is generated. It is read by the engine attached to the user application and manages the two-way communication.
Setting up styles is just the beginning of editing. Next, the number of features will grow like an avalanche. The main task is to drag and drop the basic features of the markup language into the visual editor. It's not hard to do. I'd say there's a kind of breakthrough at the visual level, like breaking through a supersonic barrier. It's hard to describe... - it's like, the possibilities were locked up under a lock and now, when you go to visual, the door to them opens and they pile up. Just time to implement.
Upcoming tasks:
1. Adding windows.
...
//------------------------------------------------
The code is not essentially generated. What is generated is a kernel containing the elements in the numeric description. It is read by the engine attached to the user application and manages the two-way communication.
What I would like: creating a base style and editing it, creating default styles. Customising the button style separately. Greater emphasis should be placed on style templates, taking something from the modern trend.
Possibility to at least some editing of the user files code on the fly. For example, the call of certain classes or the list to be shown. Accordingly, it must be the standard of a certain response for further post processing.
It is logical that there should be a possibility of visual editing - but it is only the first step, in which I think it is logical to use the right button and make there a definite menu. In general, it's easier to make the code independent - because in the future you may need it not only for work in MT. Accordingly the files are pluggable. Well, at least in the inludes if we do it for the market.
Usually in such directions every new step leads to even more problems in the code, it often seems that everything can be done in a certain amount of time but in fact it takes much longer. And this will always be the case, avalanche figuratively will only increase the functionality after the release of the first fully working version.
What would be desirable: creating a base style and editing it, creating default styles. Customise the button style separately. Greater emphasis should be placed on style templates taking something from the modern trend.
Possibility to at least some editing of the user files code on the fly. For example, a call for certain classes or a list, that needs to be shown. So, there must be a standard response for the further post processing.
It is logical that there should be a wide possibility of visual editing - but it is only the first step, where I think it is logical to use the right button and make there a definite menu. In general, it's easier to make the code independent - because in the future you may need it not only for work in MT. Accordingly, the files are pluggable. well, at least in the inludes if we do it for the market
I will think about saving the style templates. In a markup language, this was easy. There, the property chain could be simply copied from element to element and it would look just right. Here we don't have a direct chain, but what's the problem with making one? I think it could be better and simpler. Something like a styleset with saved values of templates properties...
About the possibility to edit usable files - not quite understood what exactly we're talking about. An example would be...
The files necessary for connection are printed. There are two of them. They contain the load information for the engine and the api for the user application. So that it "communicates" with the elements.
Print text on the elements.
think about the grid - some kind of alignment/alignment is needed. it's already difficult to line up three elements evenly
I agree. I'll think about it.
think about the grid - some kind of alignment/binding is needed.
Yes this whole grid is 10 times to......
Need to see the user interest. For example if it was possible to create this or that chart on the fly... for example draw a line by maxes and so on.
Because so far it's nothing more than a very good lesson for the author in program design. Just creating a menu is not that interesting. And function calls should come from a button.
Although, due to popularization of canvas on html, there is a sporting interest to implement something universal. But it is too complicated for me
....
Admittedly, there is another option - to limit oneself to code generation. Like an "inludnik" with all the buttons layout is created and all that's left is to enter the data ....... - also a variant. PS: The closest and most viable option
My goal is to implement the following list of tasks by the 3rd of March:
1. Adding/removing windows.
2. Deleting items.
3. Creating a new tool - blue frame.
4. Copying elements within the window.
5. Extending the editing focus.
6. Adding editing targets.
7. Selecting and loading saved projects.
8. Upgrading the engine.
9. Grid and autocorrect element positions.
//------------------------------------------------
After that, the visual editor can be used to create a Windows-like interface for custom applications.
(sic. with a set of simple elements. This will be followed by tables and various lists).
Peter invented and wrote Windows! Only 30 years too late =)
Following in the footsteps of the giants).