Perché i terminali consentono solo display a cella di caratteri

Poiché gli emulatori di terminale sono forniti per adattarsi a uno stile semplice di comunicazione uomo-computer, la riga di comando , che rimane estremamente utile in contesti alcuni .

Indietro quando la linea di comando e i terminali hardware erano tutto ciò che avevamo, era chiaro che erano terribilmente limitati per alcuni contesti. La gente ha iniziato a spingere le proprie capacità, dandoci ANSI, ncurses e, infine, sistemi di finestre e grafici grezzi, come illustrato nei primi due esempi. Parallelamente a questo sforzo, i sistemi GUI effettivamente indirizzabili ai pixel iniziarono a popolare lentamente il mondo, perché quei pacchetti di finestre basati sul terminale erano intelligenti, ma ancora irrimediabilmente inadeguati per molte esigenze. Alla fine, i sistemi di grafica indirizzabili ai pixel hanno conquistato il mondo.

Tuttavia, l'API software per manipolare i sistemi GUI è molto più complessa dell'API necessaria per visualizzare messaggi di testo in un set di caratteri fissi, su uno schermo di dimensioni fisse, su un terminale hardware. I componenti volevano che il loro vecchio software continuasse a funzionare, e per il loro nuovo software non volevano scrivere una funzione da 300 righe, specificando maniglie di finestre, maniglie di font, bitblit e manipolando rettangoli sovrapposti, solo per stampare un registro messaggio sullo schermo. Quindi, una delle prime cose che gli sviluppatori della GUI hanno fatto era scrivere emulatori di terminale che permettessero ai programmi di fingere di parlare ancora con 80x25, set di caratteri fissi, terminali hardware. Tutti i vecchi programmi funzionano ancora, e quelli di noi che scrivono nuovi programmi per la riga di comando non sono gravati dall'apprendimento di molte nuove API che sono irrilevanti ai nostri obiettivi. Sono stati aggiunti campanelli e fischietti, ma questo è ancora il ruolo essenziale per gli emulatori di terminali.

Se hai bisogno di grafica a livello di pixel e supporto per le immagini, è sufficiente farlo in un'applicazione scritta per il sistema di finestre host o in Javascript in un browser. Non è necessario aggiungere questa capacità al terminale (oltre alla perversità / curiosità).

Why the terminals seem to have such limitations as everything being done with ansi escape sequences, divided into lines and cells for characters

La maggior parte dei computer ampiamente utilizzati dagli anni '60 fino agli inizi degli anni '80 comunicavano con i loro terminali tramite interfacce seriali e molti mostravano il loro output su carta . I terminali video non si sono diffusi fino alla fine degli anni '70, e quelli avevano una memoria molto limitata. Nel passato eravamo abituati a distinguere tra "terminali stupidi" che essenzialmente implementavano la stessa interfaccia della carta (stampare nella posizione corrente e scorrere verso il basso erano gli unici comandi) e "terminali intelligenti" che permettevano cose come il posizionamento del cursore di linee e colonne .

Vale la pena notare che il sistema X Window , che è ancora usato come GUI per Linux, è stato appena progettato come soluzione per consentire ai programmi di mostrare la grafica da remoto. Quindi è fondamentalmente il terminale grafico che stai cercando. Usa primitive come il testo e anche le immagini.

Questo approccio, tuttavia, inizia ad essere lento in quanto vi è la necessità di video e grafica 3D. Le implementazioni moderne utilizzano estensioni per consentire l'uscita dei programmi locali senza utilizzare il protocollo remoto. Inoltre, è in ritardo in termini di funzionalità, quindi i framework GUI più popolari sono passati dall'utilizzo delle primitive X al solo disegno di tutti i loro widget su un singolo canvas che viene inviato alla grafica come un bulk. Ciò ha reso l'uso remoto proibitivo.