Making a crowdsourced project on Canvas - page 38

New comment
 
Реter Konow:
The core is the matrix. It contains all the properties of the objects.

You can choose your method. But, in all my years of gui development, I have found that no other method can provide the same level of functionality. Maximum simplicity and efficiency is perfection.


Peter, do you have any experience and examples of writing GUI not only in the current version?

You completely deny other paradigms, but claim that your model is the best for GUI implementation. That's a very controversial assertion.

 

Make an indicator that corrects inclination angles of drawn lines, their intersection points and proportions of ellipses. While the anchor points are set in the future

after two weekends and some bloody indie day...

PS/ it feels like the people who draw the interfaces are not involved in trading at all

 
Maxim Kuznetsov:

Make an indicator that corrects the slope angles of the drawn lines, their intersection points and the proportions of the ellipses. With the anchor points set in the future

after two weekends and some bloody indie day...

PS/ it feels like the people who draw the interfaces have nothing to do with the trade at all

Max, I dare say that in half of the cases this is the case. The trader does not have to be a programmer and the programmer does not have to be a trader.

 

I dare say that Peter does not program in anything else but mql. All modern versions of languages require knowledge of working with classes: java, kotlin, sharp, python, c++ and so on. Even 1C has a semblance of classes in the form of fixed object types. But this is just a digression.

From my point of view, the system of interface building should look like this:

CForm Форма = new CForm;
Интерфейс.Добавить(Форма);
CButton КнопкаBUY= new CButton;
КнопкаBUY.Заголовок = "BUY";
КнопкаBUY.ЦветФона = clrBlue;
КнопкаBUY.Позиция(7,20);
Форма.Добавить(КнопкаBUY);

That is, interface creation should be declarative. I can't even imagine how any other programmer will add description of properties of a control referring to indexes.....

I'm sure that even for an average programmer it would be puzzling, let alone a beginner.

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

I dare say that Peter does not program in anything else but mql. All modern versions of languages require knowledge of working with classes: java, kotlin, sharp, python, c++ and so on. Even 1C has a semblance of classes in the form of fixed object types. But this is just a digression.

From my point of view, the system of interface building should look like this:

That is, interface creation should be declarative. I can't even imagine how any other programmer will add description of properties to the board referring to indexes.....

I'm sure that even for an average programmer this would be puzzling, let alone a beginner.

If there are a lot of elements and/or properties depend on an index, it's no problem and vice versa, it's hard to write a mess while referring to each individual one.

 
Roman:

A matrix is nested loops, and nested loops are time. I'm not being sarcastic, just reasoning logically.

Right. Everything in the universe takes time).
 
Алексей Барбашин:

1. Peter, you get the following: the core consists of a global matrix of element properties, a global matrix of element values, a global matrix of dependencies, a global matrix of pictures...

2. If you need to add some more properties then the dimensionality of the matrices is increased.

3. The properties are accessed strictly by indexes, because cells do not have names.

At least field names can be accessed with the structure.

Peter, you... giant...

I, for example, see it this way (simplified):

4. A de facto "class" is a specific string in your global array, just with a more "human" face. Classes are designed to create their own data objects, with a set of understandable properties that can be accessed by name rather than index. A class is just a universal type constructor.

So, let's create a basic control that contains the most common properties, which almost any control has.

You can create specialized objects based on it:

That is, each subsequent control type simply supplements the base type with the required properties.

And since, as I wrote earlier, the basic properties are stored in the base control, the traversal of "hitting" the cursor in the control is done by checking one data type: CControl. Having found the desired object, the program immediately has access to the properties of that object, since the program point is already in the object itself, just like in your loop the program is on the desired array line.

1. The core is one global matrix. Two dimensions. The core is built by a special function that reads a file where the markup language says which windows and elements need to be created.

2. No, the dimensionality of the matrix is constant. There are only 2 dimensions.

3. The properties of the objects in the kernel are ordered. Each has its own index. The indexes are named through defines. As the number of object properties increases, the matrix grows wider. There are ways to restrain its growth and compact the objects inside.

4. The class, as an object description, is good, but the mechanism (which the code is) works more efficiently with the kernel. Anyway, it doesn't matter. It suits everybody's needs.

Scattered description and storage of object properties (main ones in base class, others in descendants) complicates access and handling. Add visibility limitations, access modifiers and alien language and you get a real reduction not only in the mechanism, but in the development process. However, this is imho.
 
Реter Konow:
1. The core is one global matrix. Two dimensions. The core is built by a special function that reads a file where the markup language says which windows and elements need to be created.

2. No, the dimensionality of the matrix is constant. There are only 2 dimensions.

3. Properties of objects in the kernel are ordered. Each has its own index. The indexes are named through defines. As the number of object properties increases, the matrix grows in width. There are ways to restrain its growth and compact the objects inside.

4. The class, as an object description, is good, but the mechanism (which the code is) works more efficiently with the kernel. Anyway, it doesn't matter. It suits everybody's needs.

Scattered description and storage of object properties (main ones in base class, others in descendants) complicates access and handling. Add visibility limitations, access modifiers and alien language and you get a real reduction not only in the mechanism, but in the development process. However, this is imho.

It's not complicated at all, that's the beauty and power of classes. Each next one builds up its functionality based on the functionality of the original object. As a result, all basic functionality (focus, clicks, out of element, drag and drop, draw) - all of it is implemented on the basis of basic objects. Further development and modification, development of new controls - all this will not affect the basic functionality, as it is created at the level of, say, your language: the "core" of the library. In this case, objects will have exactly those data types, which are necessary for a particular property.

"The core is built with a special function that reads a file, where it's written in the markup language what windows and elements must be created." - this is just tinny. So you have a matrix that stores all the properties, and you also have a markup file that specifies exactly how the matrix with the properties should be read..."Indices are named via defines" - each index is hardwired to a define. Randomly inserting an extra field will cause the properties to shift with consequences. "As the number of object properties increases, the matrix grows in width" - that's what I meant by dimensionality (my fault, misapplied the term). By creating your data object as a class, you avoid all these complications. And this is real complexity, which is not really needed. But we know how to create complications for ourselves in order to successfully overcome them later.

And you don't have to create hierarchical classes and you don't have to use them at all. But it is reasonable to use structures to get rid of unnecessary data threads. IMHO

Peter, you have done a great job of creating a GUI library in your style. But if you plan to publish this thing, it's still worth redesigning everything to a different technology. I am ready to help you in this and step by step transfer all the power of your library in a new direction.

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

It doesn't get any more complicated than that, which is the beauty and power of classes. Each next one builds up its functionality based on the functionality of the original object. As a result, all basic functionality (focus, clicks, out of element, drag and drop, draw) is implemented on the basis of the basic objects. Further development and modification, development of new controls - all this will not affect the basic functionality, as it is created at the level of, say, your language: the "core" of the library. In this case, objects will have exactly those data types, which are necessary for a particular property.

"The core is built with a special function that reads a file, where it's written in the markup language what windows and elements must be created." - this is just tinny. So you have a matrix that stores all the properties, and you also have a markup file that specifies exactly how the matrix with the properties should be read... By creating your data object as a class you avoid all this complexity. And these are real complexities that you don't really need. We know how to create complications for ourselves in order to successfully overcome them later.

And you don't have to create hierarchical classes and you don't have to use them at all. But it is reasonable to use structures to get rid of unnecessary data threads. IMHO

Peter, you have done a great job of creating a GUI library in your style. But if you plan to publish this thing, it's still worth redesigning everything to a different technology. I'm willing to help you with that, and step by step move all the power of your library into a new direction.

You know, I've argued so much here about implementing my own and other people's solutions that I'm tired of it. )) It's just, really tiring. My thinking is more adapted to the matrix, others' thinking to the classes... Not worth breaking any spears on.

I generally tend to change or simplify the rules, deviate from the general course, assert my own over someone else's. You can't change me.

Thanks for the offer. You can go your own way in gui development. I have already done my way and I don't see any point in repeating it in a different style. There's a markup language, a couple of steps to the vis editor and about a week to publish. There's still a taskbar to redo and minor bugs to catch. Then, you will give your feedback on my work. I hope it will be useful to all.

ZS. After publication, I will be able to give more details about the solutions and it may help you in creating an analogue in the classes.
 
Реter Konow:
You know, I've argued so much here about the implementation of my own and others' solutions that I'm tired of it. )) It's just, really tiring. My thinking is more adapted to the matrix, others' thinking to the classes... Not worth breaking any spears on.

I am generally inclined to change or simplify the rules, to deviate from the general course, to assert my own over someone else's. You can't change me.

Thanks for the offer. You can go your own way in gui development. I have already done my way and I don't see any point in repeating it in a different style. There's a markup language, a couple of steps to the vis editor and about a week to publish. There's still a taskbar to redo and minor bugs to catch. Then, you will give your feedback on my work. I hope it will be useful to everyone.

In your case it's not a simplification, but a real complication. IMHO

1...313233343536373839404142434445
New comment