Il y a le "quoi ?" et il y a le "comment ?". Nous pouvons deviner que le "quoi ?" est difficile à bien des égards, car on peut voir de nos jours de nombreuses conceptions d'interface utilisateur médiocres, même avec des composants fournis par les systèmes d'exploitation et les bibliothèques. Une bonne partie de la conception d'une bonne interface utilisateur nécessite une compréhension profonde de la façon dont nous, les humains, "travaillons dans le monde", et il est certainement le cas que la plupart des informaticiens d'aujourd'hui ont manqué cet apprentissage.
Il y a beaucoup d'autres routes qui pourraient être prises en plus de la combinaison d'idées dans l'interface utilisateur graphique Parc (fenêtres(vues) qui se chevauchent, icônes, pointage, sans modèle, 2+D, modèles-vues-contrôleurs, etc.) Voici un essai que l'on m'a demandé d'écrire en 1989 sur cette approche http://www.vpri.org/pdf/hc_user_interface.pdf
La partie "comment ?" est relativement facile si vous n'avez pas à optimiser : par exemple, si vous pouvez rafraîchir l'"écran d'affichage virtuel" après chaque changement graphique, si vous pouvez vous permettre de marcher à travers toutes les limites des régions qui sont censées être sensibles à l'action de pointage, et ainsi de suite.
Ce sera vraiment un exercice intéressant pour vous de faire un système simple de zéro qui peut être manipulé par un utilisateur final.
Vous aurez des tableaux de nombres de 32 bits qui représenteront des images avec un pixel étant 3 champs de 12 bits - pour le rouge, vert, bleu - de chaque nombre. Ecrivez une routine qui copiera l'un de ceux-ci - il lui sera associé les x et y et la largeur etc de l'image - dans un très grand tableau qui sera votre affichage simulé (vous le remettrez à l'OS pour l'affichage après chaque action majeure).
Associez un "numéro de profondeur" à chaque image et mettez les pointeurs vers les images dans un tableau qui contiendra les pointeurs dans l'ordre le plus profond en premier. Écrivez une routine pour effacer le tableau d'affichage et y copier chaque image. Cela se manifestera par les graphiques familiers "2 1/2 D" les plus souvent utilisés.
Pour traiter les actions de pointage, écrivez une routine qui défile dans les rectangles d'image (vous avez les x, y, largeur et hauteur comme paramètres pour chaque image) pour voir dans quels rectangles se trouve le point de pointage (notez que vous voulez généralement donner la priorité à celui qui est le plus haut).
Vous pourriez essayer de mettre en place deux actions d'interface utilisateur :
-cliquer-, qui amènera une image au sommet (ce qui signifie que vous avez changé sa profondeur à "la plus haute", ce qui signifie que le réaffichage l'affichera en dernier, et cela semblera l'avoir déplacée au sommet),
et
-glisser-, où vous devrez vous rappeler où était le pointeur afin de modifier de manière appropriée les paramètres x et y de l'image que vous pointez, de sorte que le réaffichage semblera déplacer l'image à son nouvel emplacement x et y.
Cela motivera l'écriture de routines pour comprendre les actions de pointage. Par exemple, un "clic" commencera par un "mouseDown" et sera suivi dans un certain temps max par une action "mouseUp". Si le temps max est dépassé alors cela s'appellera un "mouseStillDown" et cela pourrait être associé à une action -drag- (comme donné plus haut).
Et cela motivera l'écriture d'un gestionnaire d'événements d'une sorte ou d'une autre. Un simple est une sorte de planificateur conditionnel consistant en une boucle qui a des tests pour diverses actions de pointage avec la partie "then" appelant la routine d'action appropriée.
Et cela motivera le contournement de beaucoup de choses qui sont trop primitives en C pour être raisonnablement utilisées directement.
Par exemple, un bon stratagème dans la programmation de niveau inférieur de n'importe quel type est de mettre en place votre propre planificateur multitâche. Une façon très simple de le faire est la programmation "sans boucle", où vous ne piégez pas le contrôle dans de longues boucles, mais où vous faites passer le contrôle à chaque itération dans toutes les "boucles virtuelles" qui doivent se produire dans chaque processus simulé.
Tout ce que j'ai mentionné peut être fait en quelques centaines de lignes de C au maximum. Ce qui est complexe à ce sujet, ce sont les diverses architectures de plus haut niveau mises au-dessus de C auxquelles vous devez réfléchir.
En parlant de cela, l'une des plus grandes motivations pour la "vraie programmation orientée objet" était l'infographie, à partir du système Sketchpad d'Ivan Sutherland en 1962. Ainsi, de nombreuses choses dans les systèmes graphiques interactifs sont beaucoup plus "de type objet" que de simples structures de données.
Une dernière chose que vous pourriez essayer dans le cadre de votre architecture de test est de réfléchir au fait que les "choses faites de choses qui sont faites de choses" apparaissent superposées sur un écran 2D. Ainsi, une action de pointage est vraiment un rayon qui descend à travers toutes les couches. Cela signifie qu'il n'est pas clair quel gestionnaire des objets doit être appelé.
Notez, qu'il est souvent le cas que c'est l'image "plus grande" "la plus extérieure" qui aura les "intérieures" comme parties. C'est souvent le cas que l'objet "extérieur" devra avoir la première coupe pour savoir quoi faire - d'autre part, de nombreuses opérations voudront être faites avec l'objet "le plus intérieur". Cela suggère qu'une certaine forme d'associations devra être mise en place pour traiter la "propriété" (une relation à double sens) et pour regrouper tous les hits d'une action de pointage dans une structure qui peut aider à trier qui fera quoi.
Tout ce qui précède commence à motiver des déplacements de simples structures de données vers des moyens plus complets de traiter les relations.
Et cela devrait motiver un éloignement du C et des langages de type C, qui sont presque aussi éloignés de ces idées que le code machine.
Mais, pour l'apprentissage, cela peut être une bonne chose de traiter directement avec certains de ces mécanismes.
En attendant, la partie beaucoup plus importante de tout cela est d'apprendre "l'art de comprendre les humains" et cela conduit à "l'art de concevoir des interfaces utilisateur".