Fare un progetto in crowdsourcing su Canvas - pagina 38

Nuovo commento
 
Реter Konow:
Il nucleo è la matrice. Contiene tutte le proprietà degli oggetti.

Potete scegliere il vostro metodo. Ma, in tutti i miei anni di sviluppo di gui, ho scoperto che nessun altro metodo può fornire lo stesso livello di funzionalità. La massima semplicità ed efficienza è la perfezione.


Peter, hai qualche esperienza ed esempio di scrittura di GUI non solo nella versione attuale?

Lei nega completamente gli altri paradigmi, ma sostiene che il suo modello è il migliore per l'implementazione della GUI. Questa è un'affermazione molto controversa.

 

Realizzare un indicatore che corregga gli angoli di inclinazione delle linee disegnate, i loro punti di intersezione e le proporzioni delle ellissi. Mentre i punti di ancoraggio sono fissati nel futuro

dopo due fine settimana e qualche maledetto giorno di indie...

PS/ sembra che le persone che disegnano le interfacce non siano affatto coinvolte nel commercio

 
Maxim Kuznetsov:

Fai un indicatore che corregga gli angoli di pendenza delle linee disegnate, i loro punti di intersezione e le proporzioni delle ellissi. Con i punti di ancoraggio fissati nel futuro

dopo due fine settimana e qualche maledetto giorno di indie...

PS/ sembra che le persone che disegnano le interfacce non abbiano niente a che fare con il commercio

Max, oserei dire che nella metà dei casi è così. Il commerciante non deve essere un programmatore e il programmatore non deve essere un commerciante.

 

Oserei dire che Peter non programma in altro che in mql. Tutte le versioni moderne dei linguaggi richiedono la conoscenza del lavoro con le classi: java, kotlin, sharp, python, c++ e così via. Anche 1C ha una parvenza di classi sotto forma di tipi di oggetti fissi. Ma questa è solo una digressione.

Dal mio punto di vista, il sistema di costruzione dell'interfaccia dovrebbe essere così:

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

Cioè, la creazione dell'interfaccia dovrebbe essere dichiarativa. Non posso nemmeno immaginare come qualsiasi altro programmatore aggiungerà la descrizione delle proprietà di un controllo facendo riferimento agli indici.....

Sono sicuro che anche per un programmatore medio sarebbe sconcertante, figuriamoci per un principiante.

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

Oserei dire che Peter non programma in altro che in mql. Tutte le versioni moderne dei linguaggi richiedono la conoscenza del lavoro con le classi: java, kotlin, sharp, python, c++ e così via. Anche 1C ha una parvenza di classi sotto forma di tipi di oggetti fissi. Ma questa è solo una digressione.

Dal mio punto di vista, il sistema di costruzione dell'interfaccia dovrebbe essere così:

Cioè, la creazione dell'interfaccia dovrebbe essere dichiarativa. Non posso nemmeno immaginare come qualsiasi altro programmatore aggiungerà la descrizione delle proprietà alla scheda facendo riferimento agli indici.....

Sono sicuro che anche per un programmatore medio questo sarebbe sconcertante, figuriamoci per un principiante.

Se ci sono molti elementi e/o proprietà che dipendono da un indice, non è un problema e viceversa, è difficile scrivere un casino facendo riferimento ad ogni singolo elemento.

 
Roman:

Una matrice è costituita da loop annidati, e i loop annidati sono il tempo. Non sono sarcastico, sto solo ragionando in modo logico.

Giusto. Tutto nell'universo richiede tempo).
 
Алексей Барбашин:

1. Peter, ottieni quanto segue: il nucleo consiste in una matrice globale delle proprietà degli elementi, una matrice globale dei valori degli elementi, una matrice globale delle dipendenze, una matrice globale delle immagini...

2. Se avete bisogno di aggiungere altre proprietà, allora la dimensionalità delle matrici viene aumentata.

3. Le proprietà sono accessibili rigorosamente tramite indici, perché le celle non hanno nomi.

Almeno i nomi dei campi sono accessibili con la struttura.

Peter, tu... gigante...

Io, per esempio, la vedo così (semplificata):

4. Una "classe" de facto è una stringa specifica nel vostro array globale, solo con un volto più "umano". Le classi sono progettate per creare i propri oggetti di dati, con un insieme di proprietà comprensibili a cui si può accedere per nome piuttosto che per indice. Una classe è solo un costruttore di tipo universale.

Quindi, creiamo un controllo di base che contiene le proprietà più comuni, che quasi ogni controllo ha.

È possibile creare oggetti specializzati basati su di esso:

Cioè, ogni tipo di controllo successivo integra semplicemente il tipo base con le proprietà richieste.

E poiché, come ho scritto prima, le proprietà di base sono memorizzate nel controllo di base, la traversata per "colpire" il cursore nel controllo è fatta controllando un tipo di dati: CControl. Avendo trovato l'oggetto desiderato, il programma ha immediatamente accesso alle proprietà di quell'oggetto, poiché il punto del programma è già nell'oggetto stesso, proprio come nel vostro ciclo il programma si trova sulla linea dell'array desiderato.

1. Il nucleo è una matrice globale. Due dimensioni. Il nucleo è costruito da una funzione speciale che legge un file dove il linguaggio di markup dice quali finestre ed elementi devono essere creati.

2. No, la dimensionalità della matrice è costante. Ci sono solo 2 dimensioni.

3. Le proprietà degli oggetti nel kernel sono ordinate. Ognuno ha il suo indice. Gli indici sono nominati attraverso le definizioni. Man mano che il numero di proprietà dell'oggetto aumenta, la matrice diventa più ampia. Ci sono modi per frenare la sua crescita e compattare gli oggetti all'interno.

4. La classe, come descrizione dell'oggetto, è buona, ma il meccanismo (che è il codice) funziona in modo più efficiente con il kernel. Comunque, non importa. Si adatta alle esigenze di tutti.

La descrizione e la memorizzazione sparse delle proprietà degli oggetti (quelle principali nella classe base, altre nei discendenti) complicano l'accesso e la gestione. Aggiungete limitazioni di visibilità, modificatori di accesso e linguaggio alieno e otterrete una vera riduzione non solo del meccanismo, ma del processo di sviluppo. Tuttavia, questo è imho.
 
Реter Konow:
1. Il nucleo è una matrice globale. Due dimensioni. Il nucleo è costruito da una funzione speciale che legge un file dove il linguaggio di markup dice quali finestre ed elementi devono essere creati.

2. No, la dimensionalità della matrice è costante. Ci sono solo 2 dimensioni.

3. Le proprietà degli oggetti nel kernel sono ordinate. Ognuno ha il suo indice. Gli indici sono nominati attraverso le definizioni. Man mano che il numero di proprietà dell'oggetto aumenta, la matrice cresce in larghezza. Ci sono modi per frenare la sua crescita e compattare gli oggetti all'interno.

4. La classe, come descrizione dell'oggetto, è buona, ma il meccanismo (che è il codice) funziona in modo più efficiente con il kernel. Comunque, non importa. Si adatta alle esigenze di tutti.

La descrizione e la memorizzazione sparse delle proprietà degli oggetti (quelle principali nella classe base, altre nei discendenti) complicano l'accesso e la gestione. Aggiungete limitazioni di visibilità, modificatori di accesso e linguaggio alieno e otterrete una vera riduzione non solo del meccanismo, ma del processo di sviluppo. Tuttavia, questo è imho.

Non è affatto complicato, questa è la bellezza e il potere delle classi. Ogni successivo costruisce la sua funzionalità sulla base della funzionalità dell'oggetto originale. Di conseguenza, tutte le funzionalità di base (focus, click, out of element, drag and drop, draw) - tutto è implementato sulla base di oggetti di base. Ulteriori sviluppi e modifiche, sviluppo di nuovi controlli - tutto questo non influenzerà la funzionalità di base, poiché è creata a livello, diciamo, della vostra lingua: il "nucleo" della libreria. In questo caso, gli oggetti avranno esattamente quei tipi di dati che sono necessari per una particolare proprietà.

"Il nucleo è costruito con una funzione speciale che legge un file, dove è scritto nel linguaggio di markup quali finestre ed elementi devono essere creati". - questo è semplicemente insignificante. Così avete una matrice che memorizza tutte le proprietà, e avete anche un file di markup che specifica esattamente come la matrice con le proprietà dovrebbe essere letta..."Gli indici sono nominati tramite define" - ogni indice è collegato ad una define. Inserendo casualmente un campo in più, le proprietà si sposteranno con conseguenze. "Man mano che il numero di proprietà dell'oggetto aumenta, la matrice cresce in larghezza" - questo è ciò che intendevo per dimensionalità (colpa mia, ho applicato male il termine). Creando il vostro oggetto dati come una classe, evitate tutte queste complicazioni. E questa è una vera complessità, che non è veramente necessaria. Ma sappiamo come crearci delle complicazioni per poterle poi superare con successo.

E non dovete creare classi gerarchiche e non dovete usarle affatto. Ma è ragionevole usare le strutture per sbarazzarsi dei thread di dati non necessari. IMHO

Peter, hai fatto un ottimo lavoro nel creare una libreria GUI nel tuo stile. Ma se avete intenzione di pubblicare questa cosa, vale ancora la pena di riprogettare tutto su una tecnologia diversa. Sono pronto ad aiutarvi in questo e a trasferire passo dopo passo tutto il potere della vostra biblioteca in una nuova direzione.

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

Non c'è niente di più complicato di questo, che è la bellezza e il potere delle classi. Ogni successivo costruisce la sua funzionalità sulla base della funzionalità dell'oggetto originale. Di conseguenza, tutte le funzionalità di base (focus, click, out of element, drag and drop, draw) sono implementate sulla base degli oggetti di base. Ulteriori sviluppi e modifiche, sviluppo di nuovi controlli - tutto questo non influenzerà la funzionalità di base, poiché è creata a livello, diciamo, della vostra lingua: il "nucleo" della libreria. In questo caso, gli oggetti avranno esattamente quei tipi di dati che sono necessari per una particolare proprietà.

"Il nucleo è costruito con una funzione speciale che legge un file, dove è scritto nel linguaggio di markup quali finestre ed elementi devono essere creati". - questo è semplicemente insignificante. Così avete una matrice che memorizza tutte le proprietà, e avete anche un file di markup che specifica esattamente come la matrice con le proprietà dovrebbe essere letta... Creando il vostro oggetto dati come una classe eviterete tutta questa complessità. E queste sono vere e proprie complessità di cui non avete bisogno. Sappiamo come crearci delle complicazioni per poterle poi superare con successo.

E non dovete creare classi gerarchiche e non dovete usarle affatto. Ma è ragionevole usare le strutture per sbarazzarsi dei thread di dati non necessari. IMHO

Peter, hai fatto un ottimo lavoro nel creare una libreria GUI nel tuo stile. Ma se avete intenzione di pubblicare questa cosa, vale ancora la pena di riprogettare tutto su una tecnologia diversa. Sono disposto ad aiutarvi in questo, e passo dopo passo spostare tutto il potere della vostra biblioteca in una nuova direzione.

Sapete, ho discusso così tanto qui sull'implementazione delle mie e delle altrui soluzioni che mi sono stancato. )) È davvero stancante. Il mio pensiero è più adatto alla matrice, quello degli altri alle classi... Non vale la pena di spezzare qualche lancia per questo.

In genere tendo a cambiare o semplificare le regole, a deviare dal corso generale, ad affermare il mio rispetto a quello di qualcun altro. Non puoi cambiarmi.

Grazie per l'offerta. Puoi andare per la tua strada nello sviluppo della gui. Ho già fatto a modo mio e non vedo il motivo di ripeterlo in uno stile diverso. C'è un linguaggio di markup, un paio di passaggi al vis editor e circa una settimana per pubblicare. C'è ancora una barra delle applicazioni da rifare e piccoli bug da catturare. Poi, darete il vostro feedback sul mio lavoro. Spero che sia utile a tutti.

ZS. Dopo la pubblicazione, sarò in grado di dare maggiori dettagli sulle soluzioni e potrebbe aiutarvi a creare un analogo nelle classi.
 
Реter Konow:
Sapete, ho discusso così tanto qui sull'attuazione delle mie e altrui soluzioni che mi sono stancato. )) È davvero stancante. Il mio pensiero è più adatto alla matrice, quello degli altri alle classi... Non vale la pena di spezzare qualche lancia.

Sono generalmente incline a cambiare o semplificare le regole, a deviare dal corso generale, ad affermare le mie su quelle di qualcun altro. Non puoi cambiarmi.

Grazie per l'offerta. Puoi andare per la tua strada nello sviluppo della gui. Ho già fatto a modo mio e non vedo il motivo di ripeterlo in uno stile diverso. C'è un linguaggio di markup, un paio di passaggi al vis editor e circa una settimana per pubblicare. C'è ancora una barra delle applicazioni da rifare e piccoli bug da catturare. Poi, darete il vostro feedback sul mio lavoro. Spero che sia utile a tutti.

Nel tuo caso non è una semplificazione, ma una vera e propria complicazione. IMHO

1...313233343536373839404142434445
Nuovo commento