Hay un "¿qué?" y un "¿cómo?". Podemos adivinar que el "¿qué?" es difícil en muchos sentidos, porque hay muchos diseños de IU pobres que se ven hoy en día, incluso con componentes suministrados por los SO y las bibliotecas. Un buen diseño de interfaz de usuario requiere una profunda comprensión de cómo los seres humanos "trabajan en el mundo", y es ciertamente el caso de que la mayoría de los informáticos hoy en día han perdido este aprendizaje.
Hay muchos más caminos que podrían tomarse además de la combinación de ideas en la interfaz gráfica de Parc (ventanas superpuestas (vistas), iconos, apuntando, modeless, 2+D, modelos-visiones-controladores, etc.). Aquí hay un ensayo que me pidieron que escribiera en 1989 sobre este enfoque http://www.vpri.org/pdf/hc_user_interface.pdf
La parte del "¿cómo?" es relativamente fácil si no tienes que optimizar: por ejemplo, si puedes refrescar la "pantalla de visualización virtual" después de cada cambio de gráficos, si puedes permitirte marchar por todos los límites de las regiones que se supone que son sensibles a la acción de apuntar, etc.
Realmente será un ejercicio que valga la pena para que hagas un sistema simple desde cero que pueda ser manipulado por un usuario final.
Tendrás matrices de números de 32 bits que representarán imágenes con un píxel siendo 3 campos de 12 bits - para el rojo, verde, azul - de cada número. Escriba una rutina que copie uno de estos - tendrá asociado el x y el y el ancho, etc de la imagen - en una matriz muy grande que será su pantalla simulada (usted entregará esto al sistema operativo para su visualización después de cada acción importante).
Asocie un "número de profundidad" con cada imagen y ponga punteros a las imágenes en una matriz que mantendrá los punteros en orden más profundo primero. Escribe una rutina para limpiar el array de la pantalla y copiar cada imagen en él. Esto se manifestará como los familiares gráficos "2 1/2 D" que se utilizan más a menudo.
Para tratar las acciones de apuntar, escriba una rutina que marche a través de los rectángulos de la imagen (tiene la x, y, anchura y altura como parámetros para cada imagen) para ver en qué rectángulos está el punto del puntero (tenga en cuenta que por lo general quiere dar prioridad a la más alta).
Podrías intentar configurar dos acciones de la UI:
clic-, que llevará una imagen a la parte superior (lo que significa que has cambiado su profundidad a "la más alta", lo que significa que la redistribución la mostrará en último lugar, y esto parecerá haberla movido a la parte superior),
y
arrastrar-, donde tendrás que recordar dónde estaba el puntero para poder cambiar apropiadamente los parámetros x e y de la imagen que estás señalando para que la redistribución parezca mover la imagen a su nueva ubicación x e y.
Esto motivará la escritura de rutinas para averiguar las acciones del puntero. Por ejemplo, un "clic" comenzará con un "mouseDown" y será seguido en algún tiempo máximo con una acción "mouseUp". Si el tiempo máximo se excede entonces esto se llamaría un "mouseStillDown" y esto podría estar asociado con una acción -drag- (como se dio anteriormente).
Y esto motivará a escribir un controlador de eventos de algún tipo. Uno simple es una especie de programador condicional que consiste en un bucle que tiene pruebas para varias acciones de apuntar con la parte "entonces" llamando a la rutina de acción apropiada.
Y esto motivará a evitar muchas de las cosas que son demasiado primitivas en C para ser razonablemente utilizadas directamente.
Por ejemplo, una buena táctica en la programación de bajo nivel de cualquier tipo es configurar su propio programador multitarea. Una forma muy sencilla de hacerlo es la programación "sin bucles", en la que no se atrapa el control en bucles largos, sino que se enhebra el control a través de cada iteración en todos los "bucles virtuales" que tienen que estar ocurriendo en cada proceso simulado.
Todo lo que he mencionado se puede hacer en unos cientos de líneas de C como máximo. Lo intrincado del asunto son las diversas arquitecturas de nivel superior puestas encima de C en las que hay que pensar.
Hablando de eso, una de las mayores motivaciones para la "verdadera programación orientada a objetos" fueron los gráficos por ordenador, empezando por el sistema Sketchpad de Ivan Sutherland en 1962. Así que muchas cosas en los sistemas gráficos interactivos son mucho más "como objetos" que como simples estructuras de datos.
Una última cosa que podría probar como parte de su arquitectura de prueba es ponderar que "las cosas hechas de cosas que están hechas de cosas" aparecen superpuestas en una pantalla 2D. Así que una acción de apuntar es realmente un rayo que baja por todas las capas. Esto significa que no está claro cuál de los manejadores de los objetos debe ser llamado.
Nótese, que a menudo es el caso de que es la imagen "más grande" "más externa" que tendrá las "internas" como partes. A menudo es el caso de que el objeto "exterior" tendrá que tener el primer corte en averiguar qué hacer - por otro lado, muchas operaciones querrán ser hechas con el objeto "más interior". Esto sugiere que será necesario establecer alguna forma de asociación para tratar la "propiedad" (una relación bidireccional) y para agrupar todos los resultados de una acción de apuntado en una estructura que pueda ayudar a resolver quién hará qué.
Todo lo anterior empieza a motivar el alejamiento de las simples estructuras de datos hacia formas más completas de tratar las relaciones.
Y esto debería motivar un alejamiento de C y de los lenguajes tipo C, que están casi tan lejos de estas ideas como el código máquina.
Pero, para el aprendizaje, puede ser algo bueno tratar directamente con algunos de estos mecanismos.
Mientras tanto, la parte mucho más grande de todo esto es aprender "el arte de entender a los humanos" y esto lleva al "arte del diseño de la interfaz de usuario".