C'è "cosa?" e c'è "come?". Possiamo immaginare che il "cosa?" sia difficile in molti modi, perché ci sono molti design di UI scadenti da vedere in questi giorni, anche con componenti forniti da sistemi operativi e librerie. Un bel po' di buon design UI richiede una profonda comprensione di come noi umani "lavoriamo nel mondo", ed è certamente il caso che la maggior parte degli informatici oggi abbia mancato questo apprendimento.
Ci sono molte altre strade che potrebbero essere prese oltre alla combinazione di idee nella GUI Parc (finestre sovrapposte (viste), icone, puntamento, modeless, 2+D, modelli-viste-controllori, ecc.) Ecco un saggio che mi fu chiesto di scrivere nel 1989 su questo approccio http://www.vpri.org/pdf/hc_user_interface.pdf
La parte del "come?" è relativamente facile se non si deve ottimizzare: per esempio se si può aggiornare lo "schermo virtuale" dopo ogni cambio di grafica, se ci si può permettere di marciare attraverso tutti i confini delle regioni che si suppone siano sensibili all'azione di puntamento, e così via.
Sarà davvero un esercizio utile per voi fare un semplice sistema da zero che possa essere manipolato da un utente finale.
Avrete degli array di numeri a 32 bit che rappresenteranno delle immagini con un pixel costituito da 3 campi a 12 bit - per rosso, verde, blu - di ogni numero. Scrivete una routine che copierà una di queste - avrà associata la x e la y e la larghezza ecc. dell'immagine - in un array molto grande che sarà il vostro display simulato (lo passerete al sistema operativo per la visualizzazione dopo ogni azione principale).
Associate un "numero di profondità" ad ogni immagine e mettete i puntatori alle immagini in un array che conterrà prima i puntatori nell'ordine più profondo. Scrivete una routine per cancellare l'array di visualizzazione e copiare ogni immagine in esso. Questo si manifesterà come la familiare grafica "2 1/2 D" usata più spesso.
Per trattare le azioni di puntamento, scrivete una routine che marcia attraverso i rettangoli delle immagini (avete la x, la y, la larghezza e l'altezza come parametri per ogni immagine) per vedere in quali rettangoli si trova il punto del puntatore (notate che generalmente volete dare la precedenza a quello più in alto).
Potresti provare a impostare due azioni UI:
-cliccando-, che porterà un'immagine in cima (il che significa che avete cambiato la sua profondità in "più alta", il che significa che il redisplay la mostrerà per ultima, e questo sembrerà averla spostata in cima),
e
- trascinando-, dove dovrete ricordare dove si trovava il puntatore in modo da poter cambiare opportunamente i parametri x e y dell'immagine che state puntando in modo che il redisplay sembri spostare l'immagine nella sua nuova posizione x e y.
Questo motiverà la scrittura di routine per capire le azioni di puntamento. Per esempio, un "click" inizierà con un "mouseDown" e sarà seguito in un certo tempo massimo da un'azione "mouseUp". Se il tempo massimo viene superato, allora si chiamerà "mouseStillDown" e questo potrebbe essere associato ad un'azione -drag- (come indicato sopra).
E questo motiverà la scrittura di un gestore di eventi di qualche tipo. Uno semplice è un tipo di scheduler condizionale che consiste in un ciclo che ha test per varie azioni di puntamento con la parte "then" che chiama la routine di azione appropriata.
E questo motiverà l'aggiramento di molte delle cose che sono troppo primitive in C per essere ragionevolmente usate direttamente.
Per esempio, un buon stratagemma nella programmazione di livello inferiore di qualsiasi tipo è di impostare il proprio scheduler multitasking. Un modo molto semplice per farlo è la programmazione "loopless", dove non si intrappola il controllo in lunghi loop, ma invece si infila il controllo attraverso ogni iterazione in tutti i "loop virtuali" che devono avvenire in ogni processo simulato.
Tutto ciò che ho menzionato può essere fatto in poche centinaia di righe di C al massimo. Ciò che è intricato in tutto ciò sono le varie architetture di livello superiore messe in cima al C a cui bisogna pensare.
Parlando di questo, una delle maggiori motivazioni per la "vera programmazione orientata agli oggetti" è stata la computer grafica, a partire dal sistema Sketchpad di Ivan Sutherland nel 1962. Così molte cose nei sistemi grafici interattivi sono molto più "object-like" che semplici data-structure-like.
Un'ultima cosa che potreste provare come parte della vostra architettura di test è considerare che "le cose fatte da cose che sono fatte da cose" appaiono sovrapposte su uno schermo 2D. Quindi un'azione di puntamento è in realtà un raggio che scende attraverso tutti i livelli. Questo significa che non è chiaro quale dei gestori degli oggetti debba essere chiamato.
Nota, che spesso accade che sia l'immagine "più grande" "più esterna" ad avere come parti quelle "interne". È spesso il caso che l'oggetto "esterno" dovrà avere il primo taglio per capire cosa fare - d'altra parte, molte operazioni vorranno essere fatte con l'oggetto "più interno". Questo suggerisce che qualche forma di associazione dovrà essere impostata per gestire la "proprietà" (una relazione bidirezionale) e per raggruppare tutti i risultati di un'azione di puntamento in una struttura che possa aiutare a stabilire chi farà cosa.
Tutto ciò inizia a motivare il passaggio da semplici strutture di dati a modi più completi per gestire le relazioni.
E questo dovrebbe motivare un allontanamento dal C e dai linguaggi simili al C, che sono lontani da queste idee quasi quanto il codice macchina.
Ma, per l'apprendimento, può essere una buona cosa avere a che fare direttamente con alcuni di questi meccanismi.
Nel frattempo, la parte molto più grande di tutto questo è imparare "l'arte di capire gli umani" e questo porta a "l'arte del design dell'interfaccia utente".