Creating a graphic library from scratch - page 3

New comment
 
Maxim Kuznetsov:

Briefly, about engineering :

If there is an urge to improve some "A" by re-development, it is necessary to specify its critical weaknesses. Just list them and explain why they are intractable in the evolutionary development of "A".

On the other hand, no one forbids it. If you like writing code, write it. Rewrite "A" but in your own way, but it will be new

Max, hi!

Well I have already repeatedly described the "flaws" that from my point of view I see in the standard library and in Anatoly's library.

Both libraries have, in my opinion, one significant drawback: the interface is built on discrete chart objects, i.e. the more controls in the interface, the more detached objects in the chart itself. On the one hand this doesn't seem to be a problem, but on the other hand it is a problem with drag and drop dialogs, as not a single "form with elements" object is dragged and dropped, but many different elements. And this consumes additional resources.

Anatoly's library is very chic, but it is complicated in its composition and difficult to integrate into the main program. And the standard library is limited in the controls themselves, although the original architecture is very good in my opinion.

Actually, the best solution would be what Petr Konov tries to do: GUI GUI builder with GUI code generation, but with extended event model, so when integrating with main program, you would not need to get into huge GUI code (something like MVVM analogue), and of course with objects that users could expand on their own.

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

Max, hi!

Well, I have already described many times the "shortcomings" that, from my point of view, I see in the standard library and in Anatoly's library.

Both libraries have, in my opinion, one significant drawback: the interface is built on discrete chart objects, i.e. the more controls in the interface, the more isolated objects in the chart itself. On the one hand this doesn't seem to be a problem, but on the other hand it is a problem with drag and drop dialogs, as not a single "form with elements" object is dragged and dropped, but many different elements. And this consumes additional resources.

Anatoly's library is very chic, but it is complex in its composition and difficult to integrate into the main program. And the standard library is limited in the controls themselves, although the original architecture is very good in my opinion.

In fact, the best solution would be what Petr Konov is trying to do: a GUI GUI builder with GUI code generation, but with an extended event model, so that when integrating with the main program you don't have to go into huge GUI code, and of course with objects that users could extend on their own.

the quote should be read from bottom to top. The bottom (what is underlined) is more important. It's the defining one.

With all the modern development of all the Human Interfaces, it's rather surprising to see coordinate views and form elements in the foreground.
At the same time everyone uses browsers with Rest/Ajax, knows what MVC is, but doesn't think about the interface between the Expert Advisor and its GUI.

If the model is described and there is a protocol for working with it, the GUI can be anything and does not depend on the Expert Advisor. This is some kind of evil when you put windows into the Expert Advisor. The main purpose of Expert Advisors is to trade, everything else should be taken out of the main code and be optional.

 
Maxim Kuznetsov:

the quote should be read correctly from bottom to top. The bottom (what is underlined) is more important. It is the defining one.

With all the modern development of the Human Interface, it is quite surprising to see coordinate representations and form elements in the foreground.
At the same time everyone uses browsers with Rest/Ajax, knows what MVC is, but doesn't think about the interface between the Expert Advisor and its GUI.

If the model is described and there is a protocol for working with it, the GUI can be anything and does not depend on the Expert Advisor. This is some kind of evil when you put a box in the Expert Advisor. The main purpose of Expert Advisors is to trade, everything else should be taken out of the main code and be optional.

I think we should assume that from the beginning the developers didn't think about the fact that interfaces functionality might be needed. If you remember, in the early days there wasn't even any OOP in mql, its main purpose was only to write indicators and everything was designed for it.

And now we see that mql has already worked with sockets and databases, even at the core level... But the mechanisms of interaction between the user and the program are left aside.

The developers themselves have declared almost ten years ago that the development of interfaces is a very important mechanism of interaction between the user and the application and have developed a standard library for this case, but only its applicability to the tasks have not shown and in fact even today many programmers are not aware of its existence.

We will try to eliminate the gaps. Even if other participants will not need it, a certain experience will be gained anyway.

 
Alexandr Andreev:

I started with your library, thank you for that, then I tweaked it a bit, then some more, then some more)))) changed everything including rewritten line functions, also wide line function from Kanvas source, removed fake functions, put stub on event. not yet completely gone from W structure although there is not much left too. I've added calculation of bar on the left and right by binary search among other elements and also added binary search itself with ability to choose greater or lesser value. Also added ability to build from arrays of any kind (timeseries/common ) And came to conclusion that I should change construct))))))

Cool.

Yes, the libraries should be either universal for novice programmers, or narrowly focused for more advanced.

I myself have several versions of my own iCanvas for different purposes.

This is why I started to formulate a list of intentions and goals or at least indicate the direction. And put this list in the first post while it is available for editing.

  
//whats TD (template define)? because TT is busy
//почемуто этот код в шаблонах на мкл не хочет компилироваться поэтому через дефайн - это Плохо надо бы через шаблоны как то придумать.... привет метаквотам
#define  TD1 int
#define  TD2 double 
#define  EMPY -1 
#define  GET this.operator>> 
#define  SET this.operator<< 
class CCoordD; 
class CSizeD;
class CCoordBaseD //полностью внутрений класс
   {
   private:
   #define  ME CCoordBaseD 
   TEMPL1(T)
   bool Chek(T *a)                  {return CheckPointer(a)!=POINTER_INVALID;}
   TEMPL1(T)
   bool Chek(T a)                   {return a!=(T)EMPY;}
   TD1 Error()                      {Print(__FUNCTION__," ",__LINE__," POINTER_INVALID size"); int a[]; a[0]=0; return (TD1)EMPY;};//wtf??? =P CRASH Error
   TD1 GetA()                       {return c.GetA()+ar;}
   TD1 GetP()                       {return c.Result() + size.GetP()*(TD1)pr;}
   public:
   ME()                                   {Init();} 
   ME(TD1 a)                              {Init(a);} 
   ME(TD1 a,CCoordD &b)                   {Init(a,b);} 
   ME(TD1 a,CCoordD &b,CSizeD &x)         {Init(a,b,x);} 
   ME(TD2 a,CSizeD &b)                    {Init(a,b);} 
   ME(TD2 a,CCoordD &b,CSizeD &x)         {Init(a,b,x);} 
   CCoordD *c;//one coord
   CSizeD *size;//size 
   TD1 ar;
   TD2 pr;//percent проценты
   void Init()                            {ar=(TD1)EMPY; pr=(TD2)EMPY; }  
   TD1 Result()                           {return Chek(ar)?Chek(c)?GetA():ar:Chek(pr)?Chek(size)?GetP():Error():(TD1)EMPY;}
   ME *GetMe()                            {return &this;}
   ME *GetCoorBase()                      {return c;}
   ME *GetSizeBase()                      {return size;} 
   CCoordD *GetCoor()                     {return c;}
   CSizeD *GetSize()                      {return size;} 
   void Init(TD1 a)                       {Init(); SET(a);}
   void Init(TD1 a,CCoordD &b)            {Init(); SET(a); SET(b);}
   void Init(TD1 a,CCoordD &b,CSizeD &x)  {Init(); SET(a); SET(b); SET(x);}
 //  void Init(TD2 p)                     {Init(); pr=p_;}
   void Init(TD2 a,CSizeD &b)             {Init(); SET(a); SET(b);}
   void Init(TD2 a,CCoordD &b,CSizeD &x)  {Init(); SET(a); SET(b); SET(x);}
   void operator >> (TD1 &a)              {a=ar;} 
   void operator >> (TD2 &a)              {a=pr;}  
   void operator >> (CCoordD &a)          {a=GetPointer(c);}  
   void operator >> (CSizeD &s)           {s=GetPointer(size);}  
   void operator << (TD1 &a)              {ar=a;} 
   void operator << (TD2 &a)              {pr=a;}  
   void operator << (CCoordD &a)          {c=GetPointer(a);}  
   void operator << (CSizeD &s)           {size=GetPointer(s);}  
   void operator << (ME &a)               {a>>c; a>>ar; a>>pr; a>>size;}  
   void operator = (CCoordD &a)           {SET(a);}
   void operator = (CSizeD &a)            {SET(a);}
   void operator = (ME &a)                {SET(a);} 
   #undef  ME
   #undef  TD1
   #undef  TD2
   #undef  GET 
   #undef  SET
   };
   
class CSizeD : public CCoordBaseD
   {
   public:
   CSizeD(){};
   };
   
class CCoordD : public CCoordBaseD
   {
   public:
   CCoordD(){};
   };

class CTX {public:CTX(){}}; 
class CTY {public:CTY(){}};
class CTZ {public:CTZ(){}};
TEMPL(T)
class CCoordA : public T
   {
   public:
   CCoordA() {};
   CSizeD size;
   CCoordD ar; 
   void operator <<(CSizeD &a)   {return ;}
   void operator <<(CCoordD &a)  {return ;}
   };
   
class CCoord
   {  
   public: 
   CCoordA<CTX> X;
   CCoordA<CTY> Y; 
   CCoord ()                              {} 
   bool MouseOn(CMouse &mouse)//px
      {
      //return X.ar.Result()<=mouse.X && X.ar.Result()+X.size.Result()>=mouse.X && GetY()<=mouse.Y && GetY()+GetH()>=mouse.Y;
      return false;
      }
   };  
 

Anyway, either I'm doing something wrong or the class declaration (empty) templates don't want to work. Which makes the code not particularly handy.

I'm thinking of changing

 
Such a beautiful code would be the best way to take it to an exhibition. What it's for, how and what it solves is unknown, but it's very beautiful...
 
Guys, since you taught me, let me teach you.

You should understand how GUI mechanisms work in the first place, and then start writing code. You should know the structure and behaviour of elements, their reactions in different situations. First, present them as templates, and then create instances on a prepared technical base, including event model, state handlers, phenomena, coordinates, bindings and drawing. At the end, you will have a raw graphics library on canvas. It will be a long way from a markup language. Not to mention an editor. But, go for it.

If you think that you will just take something ready-made and raise it to a higher level, then you have never developed anything serious.
 
Реter Konow:
Guys, since you taught me, let me teach you.

You should understand how GUI mechanisms work in the first place, and then start writing code. You should know the structure and behaviour of elements, their reactions in different situations. First, present them as templates, and then create instances on a prepared technical base, including event model, state handlers, phenomena, coordinates, bindings and drawing. At the end, you will have a raw graphics library on canvas. It will be a long way from a markup language. Not to mention an editor. But, go for it.

If you think you'll just take something ready-made and take it up a notch, then you've never developed anything serious.

Wait to judge - it's not even more than the basics. And the fact that I will finish the GUI is unlikely - that's what I said back in the beginning. As for large projects - I say so in your code lines are not enough to compete with large projects.....


now the question is why the trick doesn't work

class CB; 
class CC;

class CBx{public: CBx(){};};
class CBy{public: CBy(){};};
TEMPL(T) 
class CA : public T
   {
   public:
   CA(){}
   CB<T> *b;
   CC<T> *c;
   };
    
TEMPL(T) 
class CB : public CA<T>
   {
   public:
   CB(){}
   };
    
TEMPL(T) 
class CC : public CA<T>
   {
   public:
   CC(){}
   }; 

CB<CBy> cc;
 
Alexandr Andreev:

...

now the question is why this trick doesn't work

Who knows why it doesn't work...

The library schema should be created first, and then the codes should be written. That's the way it's usually done.
12345678910...15
New comment
close