Making a crowdsourced project on Canvas - page 13

New comment
 
Igor Volodin:


For me, it's easier to create a product development team, whose members, to an agreed degree, will receive a profit from the product sales (maybe someone is the project ideologist, someone finances for a share, someone is the programmer).

And since everyone is financially motivated, to implement the necessary libraries for the interface as part of the project as well.

agreed, but the library itself should be crowdsourced openly )
 
o_O:
Igor Volodin:


For me, it's easier to create a product development team, whose members, to an agreed extent, will receive a profit from the product sales (maybe someone is the project ideologist, someone finances for a share, someone is the programmer).

And since all are financially motivated - to implement within the project and the necessary libraries for the interface.

I agree, but the library itself should be open-source crowdsourced).
I read the thread and did not understand what for it is necessary - to draw the button on Canvas from scratch. Can you explain without emotions?
 
Alexey Volchanskiy:
I've read the thread and still don't understand why it's necessary to draw a button on Canvas from scratch. Can you explain without emotions?
I choose between ObjectCreate and ResourceCreate.
because MT developers are not omnipotent and it is time consuming to bother them with petty requests
 

Why it might come in handy:

1. the interface on the bitmap is fast. So fast that it is almost indistinguishable from the system one. For example, I've implemented semi-transparent elements with gradients andeven when they move they are smoothly rendered without visible delay, taking into account the colour mixing and alpha channel calculation on other objects with semi-transparent gradients.

2. the interface is scalable. You can make the application more complex and it won't slow down due to deletion and creation of a large number of graph objects. Redrawing costs are minimal, it is only a replacement of a picture in a thousandth of a second.

3. ready-made controls can be created and new ones can be created as you can provide your own event pool, for example:

OnMouseDown - pressed the LKM

OnMouseUp - pressed the LKM

OnMouseHoverOn - hover the mouse cursor over an object

OnMouseHoverOut - move mouse cursor away from object

OnMouseClick - press and click within the object boundaries

OnMouseDblClick - double mouse click within the bounds of the object

OnDragStart - event that occurs once at the beginning of movement with pressed left mouse button

OnDragMove - event generated during movement with the left mouse button

OnDragEnd - event generated after moving with LKM

OnPut - object is cast to another object

OnGet - object is dumped to another object

OnFocus - object got focus

OnBlur - object loses focus

OnResize - object has changed size

OnParentResize - the parent object has changed size

OnKeyPress - a key pressed

OnChange - value of a field changed

etc.

 
Igor Volodin:

Why it might come in handy:

1. the interface on the bitmap is fast. So fast that it is virtually indistinguishable from the system interface. For example, I've implemented semi-transparent elements with gradients andeven when they move, they are smoothly rendered without any visible delay, taking into account the colour mixing and alpha channel calculation on other objects with semi-transparent gradients.

2. the interface is scalable. You can make the application more complex and it won't slow down due to deletion and creation of a large number of graph objects. Redrawing costs are minimal, it is only a replacement of a picture in a thousandth of a second.

3. ready-made controls can be created and new ones can be created as you can provide your own event pool, for example:

OnMouseDown - pressed the LKM

OnMouseUp - pressed the LKM

OnMouseHoverOn - hover the mouse cursor over an object

OnMouseHoverOut - move mouse cursor away from object

OnMouseClick - press and click within the object boundaries

OnMouseDblClick - double mouse click within the bounds of the object

OnDragStart - event that occurs once at the beginning of movement with pressed left mouse button

OnDragMove - event generated during movement with the left mouse button

OnDragEnd - event generated after moving with LKM

OnPut - object is cast to another object

OnGet - object is dumped to another object

OnFocus - object got focus

OnBlur - object loses focus

OnResize - object has changed size

OnParentResize - the parent object has changed size

OnKeyPress - key pressed

OnChange - value of a field changed

etc.

Exhaustive, thank you!

 
Read the thread, interesting. It's a pity there wasn't such a ruckus about interfaces about 3 years ago.

I don't see any point in posting my code as there is a high probability that the initiative will die down due to laziness and difficulties in communication between the participants (and they are already observed) my code will be dragged away to the basement for revision and I (and the community) will not benefit from it at all.

But to participate in the project I could, starting from discussing the necessary features and casting specific details of implementation, as there is a benefit in such, let's call it a framework.

The benefit is simple, voiced by Alex in the first few posts. The community can influence the developers of the terminal to introduce modifications into the MQL platform.

My hopes for improvements (directly relating to the programming interfaces) are as follows:

  1. MQL application - as a separate type of program that does not cancel others (it has no onTick and no possibility to refer to the default symbol - it's a relic of the past, but with the possibility to get a trading environment of any symbol and trade, because everything is multicurrency), the application should not start on the chart of a particular symbol, but in its own window. If you drag such a program onto a chart, a new window will open. And drag and drop is not necessary - 2 click in the navigator - also opens a new window. This is similar to the request of some people to provide API to the terminal for development in another language. Developing topic - can be assumed that such a program, specially compiled, can be run without a terminal (and for safety reasons, allow this compilation only through the Market). It may sound wild, but what if?
  2. Support for third-party vector fonts presented as a separate file and the ability to compile as a resource (stated in the documentation, but not implemented)
  3. Mouse scroll event capture
  4. Right-click menu locking. The right button is now handled, but it's useless.
  5. Handling the system clipboard, to create your own text editing controls (including multi-line editor), spacebar and enter can already be locked - good.
 

@Igor Volodin, @Combinator, @Anatoli Kazharski

I'll start with the sore subject.)
The issue that concerns me the most is some kind of universality/abstraction for storing rendering parameters.

----

As we understand all controls use font, background colour and text colour equally, etc.
When all these parameters are the same for all controls, then the interface has a common look with a single concept.

But how to store them? because controls don't always use all the parameters.
+ The system is complicated by the fact that elements have different states that should use font and background colours differently. They are Active, Disable, Over, or Select, etc.
+ there are groups of controllers - relief (like Button) and input fields (like Edit, List), and when is the background to render them

----

In the current working idea I have a minimum attribute element of class GAttribBase, which contains 5 basic parameters (font/size, background/ border colour, border size)

These base elements are used to form an array for the GAttributribut class states (Active/Disabvle/Over/Select, etc.).

And then GAttribut is populated for the different element types - Relief, Editable, etc.


So, we fill in rendering parameters once (we store them in xml), they can be edited in order to create different designs and we use them globally without defining them for every controller.

Of course, if you want to define rendering parameters for some control, just create in the control a GAttributribut object and specify the desired colours.

----

This model works, the unified design is achieved in no time, all the controls take the colours from the common array.

But in my opinion, it's not universal. The user doesn't understand which parameters from the base GAttribBase are used for rendering of this or that control.
For coder to know exactly what colour must be changed, he would have to look into rendering function of the control. Which is really bothersome.

-----

Anyway, any ideas for the coder to be free from colour management (to use predefined colours straight away and not to bother with them in the beginning).

On the other hand, if he wants to re-color some of the controls on the screen, he doesn't have to investigate what GAttribBase is used and in what case.

 
o_O:

@Igor Volodin, @Combinator, @Anatoli Kazharski

In general - what ideas do you have for the coder to be free of colour work on the one hand (so that it uses the laid in colours straight away and doesn't bother with them at the beginning)

And on the other hand, if they want to re-color some of the controls on the screen, they can do it without going into the maze of drawing functions and searching for what GAttribBase is used and in what case.

Ok, themes.

For example, the main object of our application, let's call it App, is associated with ConcreteTheme object.

What is a theme object:
colours (background, foreground, disable, active, etc.), base sizes, font sizes for standard cases: titlesize, commonsize, etc. sprites for: panels, buttons, checkboxes, etc.

A new theme is a new class/structure with changed values. But it's better that themes can be inherited by overriding only certain parameters.


The rest - the hierarchy of controls in which each controller uses one of the necessary values of the object-theme by default. If it needs to override this, we call a method to work with that property, specifying the new value.

For example SetBgColor(XRGB(255,0,128));

CView - a basic class providing basic event-based interaction
- CRect - coordinates
- Cpanel has a bgcolor
- CButton has a state object, each state has bg
- CText has a text colour and font properties
- CCircle

And so on.

If you want to use xml to describe the elements,

then for each class control or primitive we need to create a generating class let's call it "build-container" which will map attributes (bgcolor="(255,0,128)") to the corresponding methods ( SetBgColor(attrValue) ) of the class. Such build containers will be parsed by XML parser, the output will be an object initialized with needed values, or with default ones if no values were specified.

 

Here Theme is the same as mine - a set of GAttributors for different types of controls and their states.

but you already suggest the first step on the way to transparency for coder - add functions to specific control to change its rendering properties (SetBgColor etc.)

Basically I agree, it will be clear what colours it has and what can be changed.


such a question then - does Theme imply redundancy of unused parameters?

Let's say that in my basic GAttribBase for some control (e.g. button) we use only background colour and size, and other parameters - border thickness etc. are not used in this control.

That is - do you have a base element for all controls? where the information is stored "for all cases", or all controls have only their own parameters without the universality overhead?

 
o_O:

...

In general - what are some ideas for the coder to be free from handling colours (so that it would use default colours and not bother with them in the beginning)

And on the other hand - so that if he wants to re-color some controller on the screen, he doesn't have to dive into the wilderness of rendering functions and find out what GAttribBase is used and in what case.

Set default values for each item. If user needs to change something, for each item property there should be a method to set new value. This is how I have it done now.

I don't have this yet:

If you need to change properties of all elements in "two counts", then just create separate methods (for common properties that are design related and applicable to all elements) in that class where all interface elements are accessible.

In principle, I can already see how this could be implemented in my schema. For example, through events. But then in the event handler of each element you need to handle this event (the code is bloated). Second option, create a special public method in a class that handles common GUI events, or even higher, where all pointers to GUI elements are stored. Both of them are base classes of custom MQL-application class, and the user will have direct access to them. It can be something like overloaded ObjectSet methods in MQL (for example,ElementSet), where (1) property and value or (2) property, modifier and value must be specified.

But all this is my reasoning regarding my scheme. I don't rule out that it will still change a lot when I start the transition. So everything I wrote above may no longer be relevant to the topic under discussion here. )

1...67891011121314151617181920...45
New comment