Galleria di interfacce utente scritte in MQL - pagina 72

Nuovo commento
 
Il tempo passa e l'idea di un editor visivo continua a vivere nella mia mente. Non vuole lasciarmi. E quando ci penso con calma, ogni volta mi pongo la domanda "qual è il problema? - L'ho già creato, solo che non è acceso".

Nel prolungarsi della riflessione torno alle stesse conclusioni: le funzioni di base dell'editor visuale sono già presenti nella mia implementazione, e mancano solo gli strumenti complessi. Tuttavia, le cose complesse possono essere create attraverso il linguaggio di markup, che in pratica è molto più veloce e comodo rispetto alla modalità visuale.

Per esempio, tabelle ed elenchi ad albero: è lungo e doloroso comporli manualmente, ma scriverli nel codice kib è facile e veloce... soprattutto quando si usano i template. soprattutto quando si usano i template. Perché allora inventare ingombranti strumenti di editing visuale per tabelle ed elenchi, quando è possibile costruirli con un semplice copia-incolla? Non ha senso, questo è abbastanza chiaro. Ma allora qual è il problema?

È semplice. Il compito è quello di combinare il lavoro del linguaggio di markup e le attuali capacità dell'editor visuale. Non è necessario aggiungere nulla di nuovo né al primo né al secondo: è sufficiente combinarli in modo che si completino a vicenda.

Dopo aver riflettuto seriamente su questo problema, sono giunto alla conclusione che, anche se ora ci fosse l'opportunità di passare completamente alla costruzione di GUI visuali, rifiuterei. Il motivo è che non voglio perdere l'opportunità di usare i modelli di codice kib e il semplice copia-incolla di elementi o proprietà nell'ambiente del linguaggio di markup. È un vantaggio troppo prezioso. Forse non solo per me, ma per tutti i futuri utenti che potranno condividere i loro sviluppi o semplicemente copiare parti dei loro sviluppi precedenti. È una cosa indispensabile.

Cioè, è assolutamente impossibile rinunciare a un linguaggio di markup per amore di un editor visuale. Non l'ho capito prima....

Quindi, oggi il problema è sviluppare un sistema che combini armoniosamente le capacità del linguaggio e dell'editor visuale. E in realtà, tecnicamente, è abbastanza facile da fare. (1) In primo luogo, tutte le funzioni necessarie dell'editor visuale sono state scritte e testate diversi anni fa, (2) in secondo luogo, negli ultimi mesi, i meccanismi chiave del linguaggio di markup sono stati ben rafforzati ed è stato effettuato un importante aggiornamento con l'aggiunta della gestione dell'interfaccia software. In altre parole, tutto è pronto per l'integrazione e la fusione, e il compito è solo quello di pensare al concetto di interazione senza conflitti di entrambe le funzionalità nel processo di modellazione e costruzione di un'interfaccia grafica.

Concettualmente, il linguaggio di markup e l'editor visuale sono effettivamente in conflitto.

Ci sono diverse ragioni che rendono difficile questo compito:

Ricordiamo che gli elementi e le finestre della GUI sono scritti in codice come standard, ma possono anche essere creati in un editor visuale, come mostrato nella gif qui sopra.

1) Sia nel primo che nel secondo caso la funzionalità del costruttore costruisce il nucleo grafico, anche se in modi diversi, ma poiché le capacità dell'editor visuale sono più deboli di quelle del linguaggio, gli elementi creati non accettano un insieme completo di impostazioni dall'utente attraverso l'editor. Le impostazioni possono essere integrate scrivendo un editor, ma in questo caso il linguaggio di markup diventa superfluo, e questo è un male, perché non c'è la possibilità di affidarsi a modelli di codice. Non si può rinunciare al linguaggio di markup, punto e basta.

2) Quando si creano nuovi elementi e finestre in modalità visuale, il linguaggio di markup non li "vede". Cioè, il linguaggio di markup non viene aggiornato durante la costruzione visiva della GUI. Non viene "aggiunto" nulla al codice kib originale. Questo fatto porta ancora una volta alla separazione concettuale tra l'editor visivo e il linguaggio di markup. È un conflitto.

Quindi, come comportarsi e cosa fare in questa situazione? Qual è il compromesso che porta alla simbiosi di due potenti strumenti di costruzione di GUI?

Cercherò di capire la soluzione:

Punto principale: limitare il ruolo dell'editor visuale nella modellazione dell'interfaccia, lasciando inalterate le caratteristiche del linguaggio. In pratica, questo significa:

1. Rifiutare di creare nuovi elementi e finestre in modalità visuale, perché il codice di markup non viene aggiornato quando li si aggiunge.

2. Lasciare la possibilità di modificare le posizioni e impostare le proprietà degli elementi e delle finestre della GUI utente attraverso le finestre di impostazione dell'editor visuale, oltre ai valori predefiniti e personalizzati dell'utente nel codice kib. In questo caso, l'editor scriverà e salverà un file speciale con le sovrascritture dei valori, da cui li caricherà nel kernel e li assegnerà agli elementi. Di fatto, questo significa un nuovo tipo di modelli di elementi "elaborati" nell'editor. Non entreranno in conflitto con i modelli del codice kib, ma si limiteranno a sovrascrivere i valori delle proprietà in essi impostati.

Questa, a mio parere, è un'efficace simbiosi tra editor e linguaggio di markup.

P.S. L'ironia è che tecnicamente è possibile realizzare l'idea di fondere le capacità dell'editor e del linguaggio in pochi giorni, ed è abbastanza realistico, ma pensare a tutti i dettagli della loro integrazione e interazione nel lavoro dell'utente.... richiede più tempo. :)

P.S. Ma la conclusione principale è che possono e devono lavorare insieme, completandosi a vicenda.
 
Quello che volete fare richiederà molto tempo, e il vostro codice sorgente quasi nessuno potrà contribuire allo sviluppo, dovrete fare affidamento su voi stessi.
 
hini #:
Quello che volete fare richiederà molto tempo e il vostro codice sorgente non sarà in grado di contribuire. quasi nessuno sarà in grado di contribuire, dovrete fare affidamento su voi stessi.
Non sono assolutamente d'accordo con la prima affermazione. Il concetto di editor visuale non solo è stato pensato 4 anni fa, ma è tecnicamente implementato a sufficienza per consentire all'utente di assemblare facilmente una semplice finestra di impostazioni a partire dai controlli di base. Nel designer, ad esempio, c'è un markup informativo con dimensioni e griglia, c'è un pannello per impostare le proprietà e le funzioni per salvare un progetto e stampare un file API, le stesse finestre ausiliarie con cornici, immagini e font. Tutto è come in un linguaggio di markup.

Tuttavia, per completare l'editor visuale, è indispensabile un navigatore di file. La buona notizia è che il navigatore di file è già presente - l'ho mostrato in precedenza nelle pagine del ramo - e anche se necessita di modifiche, la funzionalità di base funziona.

Oltre al navigatore di file, dobbiamo sviluppare il concetto di template simile al codice kib. All'inizio pensavo che fosse impossibile, ma la soluzione si è rivelata estremamente semplice: se c'è un navigatore di file, l'editor visivo sarà in grado di salvare l'interfaccia costruita non come progetto, ma come modello. In fondo, in sostanza, si tratta della stessa cosa. Inoltre, non solo l'intero progetto, ma anche le finestre separate di questo progetto saranno salvate come modello. È facile da fare, perché viene salvata solo una parte del nucleo costruito, che può essere caricato in un altro progetto e l'utente sarà in grado di estrarre (tramite la copia mostrata nella gif sopra) gli elementi necessari e quindi cancellare questo modello dal suo progetto. Ho la funzione di cancellare finestre ed elementi. Questo è tutto.

Le tabelle possono essere costruite semplicemente copiando le celle secondo l'esempio dei pulsanti nella gif qui sopra. La stessa cosa. Un elenco ad albero è più complicato.... ma non è la cosa principale.

Con molto entusiasmo, tutto può essere fatto in un mese, un mese e mezzo. Ma ora sono impegnato a preparare il materiale per gli articoli, quindi questo lavoro è rimandato.

Per quanto riguarda l'affermazione che altri programmatori non saranno in grado di sviluppare il progetto..... sì, non possono sviluppare direttamente il progetto. Ma possono offrire soluzioni, condividere la loro esperienza, le loro opinioni, offrire funzioni per lavorare con il colore, con il gradiente. Sono aperto a questa interazione e cooperazione.
 
Реter Konow #:

...

Tuttavia: un navigatore di file è assolutamente necessario per completare l'editor visuale. La buona notizia è che il navigatore di file è già presente - l'ho mostrato in precedenza nelle pagine dei rami - e anche se necessita di modifiche, la funzionalità di base funziona.
...


Per non essere da meno, ecco come funziona il navigatore di file (a sinistra). È sufficiente integrarlo nell'editor.

 

Questo video mostra la creazione della finestra delle impostazioni nell'editor visuale della MT5. È possibile giudicare approssimativamente il grado di completamento dell'editor.


 
hini #:
Quello che volete fare richiederà molto tempo, e il vostro codice sorgente quasi nessuno sarà in grado di contribuire allo sviluppo, dovrete fare affidamento su voi stessi.
Mi chiedo a quale scopo tu abbia scritto questo post. :) Mi sto solo chiedendo.

Forse, come molti altri, stai cercando di farmi capire l'inutilità degli sforzi e delle aspirazioni..... di provocarmi a rendermi conto dell'irraggiungibilità dei miei obiettivi... forse stai cercando di mostrarmi che conosci un'altra strada. o Dio solo sa cos'altro.

Ma sarò onesto: non importa. Scriverò gli articoli e finirò l'editor visivo come avevo intenzione di fare. E lascerò che rimanga un inutile "cavallo sferico nel vuoto" per tutti. Lasciamolo fare.

Per me è un'importante fase di sviluppo.

Sottolineo: per me è una fase essenziale dello sviluppo.

Pertanto, l'editore "sarà e basta". Indipendentemente dal mio, dal vostro o da quello di chiunque altro, dai ragionamenti, dalle riflessioni, dalle argomentazioni, dalle controargomentazioni, dai ragionamenti, dalle valutazioni, dagli stati d'animo, dai sospiri, dagli scuotimenti di testa, ecc.

L'editor visivo sta PER ESSERE (finito).

"Perché", "per cosa", "come" e "perché" applicarlo...oppure no.... lasciare che ognuno decida per sé... PER SE STESSO.

Pace. :)
 
Реter Konow #:
Mi chiedo a quale scopo hai scritto questo post. :) Mi chiedo solo.

Forse, come molti altri, stai cercando di trasmettermi un messaggio sull'inutilità dell'impegno e dello sforzo.... per provocarmi a rendermi conto dell'irraggiungibilità dei miei obiettivi... forse stai cercando di mostrarmi che conosci un'altra strada. o Dio sa cos'altro.

Ma onestamente, non importa. Scriverò articoli e finirò l'editor visuale come avevo intenzione di fare una volta. E lascerò che rimanga un inutile "cavallo sferico nel vuoto" per tutti. Che sia così.

Per me è una fase importante dello sviluppo.

Sottolineo: per me è una fase essenziale dello sviluppo.

Pertanto, l'editore "sarà e basta". Indipendentemente dai ragionamenti, dalle riflessioni, dalle argomentazioni, dalle controargomentazioni, dai ragionamenti, dalle valutazioni, dagli stati d'animo, dai sospiri, dagli scuotimenti di testa, ecc.

L'editor visivo è semplicemente BUONO (finito).

"Perché", "per cosa", "come" e "perché" applicarlo... o non applicarlo..... lasciate che ognuno decida per sé... PER SE'.

Pace. :)

Non voglio dire altro, è solo un'idea; ti sostengo nel portare a compimento ciò che vuoi fare.

----------------------------



<edited by moderator> in russo: Non intendo nient'altro, è solo un'idea; ti sostengo nel portare a compimento ciò che vuoi fare.

 

Peter, penso che quello che stai facendo sia fantastico! Sappi che hai il mio incoraggiamento nella tua impresa.
È fin troppo facile per le persone dire "mai lasciare che la perfezione sia nemica del bene", ma questo è più facile a dirsi che a farsi quando
hai una visione di come il tuo progetto dovrebbe funzionare.
Attendo con ansia i prossimi articoli ecc... su come funzionerà il tuo editor visivo.
E sappi che un buon editor visivo non sarà mai un "inutile cavallo sferico nel vuoto".

saluti

Doug

 
hini #:

Non intendo altro, è solo un'idea; vi sostengo nel portare a compimento ciò che volete fare.

----------------------------



<edited by moderator> in russo: Non intendo nient'altro, è solo un'idea; ti sostengo nel portare a compimento ciò che vuoi fare.

Grazie per il vostro continuo supporto e partecipazione, che mi ha aiutato molto nella gestione di questo thread.
 
Douglas Prager progetto dovrebbe funzionare.
Non vedo l'ora di leggere altri articoli, ecc.... su come funzionerà il vostro editor visivo.
E sappiate che un buon editor visivo non sarà mai un "inutile cavallo sferico nel vuoto".

Saluti,

Doug

Grazie mille Douglas per le tue parole ispiratrici. So che quando le persone si liberano degli strati di critiche disfattiste, aspirazioni svalutanti e idee avvilenti con convinzione, raggiungono insieme le vette più alte!
1...656667686970717273747576777879...83
Nuovo commento