Diseño e implementación de una GUI: Presentación

¡Hola! ¿Qué tal están?

En este texto me propongo hablarles de un tema relacionado con la informática, y en específico presentarles la idea de hacer un tutorial sobre diseño e implementación de una interfaz gráfica de usuario, o para abreviar GUI (Graphical User Interface) por sus siglas en inglés.

En todo caso, primero veamos un poco de historia, a ver de dónde proviene esto de las interfaces gráficas de usuario, porque aun si la gente de menos edad podría llegar a dudarlo en nuestros días, las computadoras no estuvieron provistas con esta forma de interacción con ellas hasta tiempos un poco más recientes.

En efecto, en una época fue común para los usuarios de una computadora vérselas con una interfaz de comandos cuando pretendían utilizarla para resolver un problema, o incluso para extraer un par de datos desde una base de datos, o desde un archivo almacenado en ella en un tambor o una cinta magnética; o por lo menos así fue cuando estuvieron disponibles para su uso las terminales de texto propias de las mainframes y las minicomputadoras, dado antes de eso todo era todavía más primitivo, en el tiempo de los conmutadores, indicadores de luces, tarjetas perforadas, e impresoras de línea para ver la salida, cuando no se tenía a mano ni un dichoso teclado.

La interfaz de comandos, también conocida como intérprete de comandos, por lo general consistía en un indicador en pantalla conformado por uno o más caracteres de texto blanco sobre un fondo oscuro. La idea era sirviera para sugerir a la persona delante de la terminal en cuestión la computadora estaba esperando y debía escribir una petición a ésta. La petición en sí era también conocida como comando, porque más bien consistía en una orden, y de ahí el nombre de la interfaz, y del programa encargado de procesarla para la obtención de los resultados; en ocasiones estaba compuesta por varios parámetros, y por eso podía llegar a ser bastante complicada y por tanto un poco difícil de recordar para un pobre ser humano. El intérprete de comandos leía la susodicha petición, una vez el usuario terminaba de teclearla y presionaba “Enter” en su teclado, y si todo estaba en orden, la procesaba y devolvía el resultado en pantalla en forma de un texto. En caso contrario, si el intérprete de comandos encontraba un error de sintaxis u otro problema, se limitaba a escribir a la terminal una explicación breve de porqué esa petición en particular había fracasado, y luego de eso volvía a mostrar el indicador para sugerir al ser humano lo reintentara.

Por supuesto, por lo normal lo descrito ocurría nada más con los comandos del sistema, tanto los llamados internos como los externos (los comandos residentes en forma de un programa independiente separado del intérprete de comandos); los programas de los usuarios, esto es, los programas de oficina, los programas de base de datos, etc., podían tener una interfaz de usuario un poco más elaborada, aun si por lo común también de texto.

El proceso fue más o menos así durante años, y siguió casi igual cuando por fin estuvieron disponibles las microcomputadoras; a los encargados de los centros de cómputo de los institutos científicos, y de las empresas y universidades importantes, no parecía molestarles para nada.

En ese momento todavía las computadoras eran utilizadas más frecuentemente por la gente dedicada a la informática, la cibernética, y a las matemáticas o la investigación científica, y puede por eso a veces esas personas hasta parecían disfrutar con la complejidad de los engorrosos mecanismos primitivos envueltos en el proceso de utilizarlas. En realidad, si se lo piensa, era normal fuera así para ellos, pues si se venía a ver, como se ha mencionado, antes de las interfaces de comandos basadas en texto todo era incluso más complicado. Por eso, es probable esa manera de interactuar con una computadora pudiera haber sido vista por esos individuos más bien como un alivio; y eso sin decir nada de un hecho importante, casi todas esas personas eran superdotadas en comparación con el resto de los pobres mortales, o al menos en su área. Pero resulta ser las microcomputadoras no demoraron un largo período de tiempo en imponerse, y en extenderse, y, en contra de todos los pronósticos anteriores sobre su futura demanda, hasta en tener cierta penetración aun en entornos menos especializados, como en las empresas medianas y pequeñas o las viviendas de la gente de clase media.

La expansión por todos lados de las computadoras se hizo más y más posible a medida los decrecientes precios del hardware lo iban permitiendo, y se fueron descubriendo áreas y áreas en donde usar una de ellas podía resultar recomendable y rentable.

En resumen, en un momento determinado las microcomputadoras pudieron estar disponibles aun en las viviendas de las personas de clase trabajadora debido a su nivel de precios, en donde debían poder ser usadas hasta por los escolares. Por eso, más y más empresas se empezaron a dedicar a crear software para esos sistemas electrónicos, y poco a poco fue emergiendo la idea de hacer las cosas de manera un tanto diferente, podríamos decir de un modo más sencillo para el común de los usuarios, para así poder venderle esos dispositivos a todavía más personas. En este contexto, más o menos en la época del reinado de los microprocesadores de 8 bits como el Z80, fue cuando se empezó a generalizar la idea original de una interfaz gráfica de usuario, como les comenté también conocida como GUI.

La primera interfaz gráfica de usuario conocida fue desarrollada en los 70s en una institución de nombre Xerox PARC situada en Palo Alto, California, en donde se diseñó también el predecesor del ratón de nuestros días para poder controlar las ventanas gráficas de un modo fácil; y a partir de ese desarrollo inicial, más bien experimental, el resto de empresas como: Digital Research con su GEM, Apple con su Lisa y luego su Macintosh, Microsoft con su Windows, IBM con su OS/2 y el Presentation Manager, entre otras, elaboraron (o robaron según algunos) sus propias versiones de la idea.

En un momento determinado, las GUI se empezaron a hacer tan populares que las compañías de desarrollo debieron incorporarlas en sus productos o perecer en la competencia, en especial luego del contundente éxito de Windows 95 en casi todo nuestro planeta; pero esto ahora no debe de ser  un secreto para nadie, cuando pocos usan un intérprete de comandos clásico para interactuar con una computadora durante la realización de sus tareas, a menos sean fanáticos del Unix o del GNU Linux de los cuales a mi modo de ver no existen muchos.

La razón es evidente, las interfaces gráficas de usuario poseen varias ventajas con respecto a las interfaces de comando, como podrían ser:

  • El usuario del software puede percatarse más fácilmente de cómo se usa éste, pues puede ver sin problemas los botones y otros elementos gráficos (WYSIWYG por What You See Is What You Get en inglés), y así recordar las funciones sin tanto esfuerzo.
  • Es posible conformar interfaces bastante complicadas a partir de un conjunto de elementos básicos estándar, o de componentes individuales predefinidos, y por lo tanto se potencia todavía más lo antes mencionado, al conseguir la creación de interfaces gráficas se podría decir comunes para todos los programas.
  • En parte por lo anterior, el período de tiempo dedicado por un individuo a dominar un sistema informático se reduce exponencialmente, con la consiguiente disminución de los costos de entrenamiento del personal de la empresa involucrada; y esto mismo sucede en cierta medida con lo referente al desarrollo del software, al poder concentrarse los programadores en cómo funcionará el sistema en vez de preocuparse por cómo va a verse en pantalla.

En resumen, en estos días o se tiene una GUI disponible o es poco probable un software se use en lo absoluto, y como por lo general la interfaz gráfica de usuario debe ser proveída por el propio sistema operativo, dada la naturaleza multitarea de estos, es necesario prever el desarrollo de una GUI a la hora de diseñarlo, o lo más probable será no se popularice ni en su propia casa.

En todo caso, mi intención con este tutorial no es desarrollar una interfaz gráfica de usuario utilizable en un sistema operativo existente, y mucho menos pienso hacer un software de esa última naturaleza; aun si debo confesar en ocasiones he tenido esa idea loca en la cabeza, y todavía me asalta de cuando en cuando, por ser un sistema operativo un programa de los más complicados de elaborar todavía, y por tanto resultar su estudio interesante. Por lo menos a mí me parece bastante emocionante desarrollar un software de esa índole, en especial uno para correrlo sobre una de esas tarjetas limitadas como las Arduino, o tal vez en una decodificadora de televisión digital común y corriente (no sé si eso sea posible porque no lo he estudiado y puede carezcan del firmware para ello, sin embargo, sería útil en un país como Cuba, en donde mucha gente no dispone de recursos para comprar una microcomputadora y también resulta difícil encontrarlas). Por lo menos serviría para ver en un televisor ahora un poco obsoleto documentos en formato PDF, para correr programas ligeros, o incluso para entretenerse con videojuegos poco complejos o educativos. Pero no deben engañarse, hacer un programa como ese tomaría muchos meses para su desarrollo, y eso sin mencionar la necesidad de una inversión inicial de modo se pueda conseguir el hardware necesario, y seguramente al final nadie lo utilizaría nunca, a pesar de resultar bastante económico no sólo por el costo del dispositivo, sino por la poca cantidad de energía consumida por las decodificadoras de televisión digital en comparación con las microcomputadoras de sobremesa.

Nota: En caso de tener interés en el desarrollo de un sistema operativo me gustaría lo comentaran y tal vez más adelante pueda comenzar a hacer un tutorial paso a paso sobre cómo desarrollar un software como ese por cuenta propia de la manera más sencilla posible; o tal vez les interese más un sistema operativo web, o WebOS como suele llamárseles a menudo, mucho más simples a la hora de implementarlos puesto con ellos no deberemos de lidiar directamente con el hardware de la microcomputadora, sino con los servicios proveídos por los navegadores.

En fin, mi intención con este tutorial es ir experimentando acerca de cómo podría funcionar internamente un gestor de ventanas propio de una GUI, y sus componentes más comunes, más bien con fines educativos; y por eso me gustaría participaran y me propusieran ideas, pues como deben imaginarse, nada más soy un aficionado a la informática a este nivel, y en general no poseo profundos conocimientos de esa ciencia.

Por lo demás, me propongo utilizar QBasic, en primer lugar por ser BASIC un lenguaje de programación fácil de comprender para todos a pesar de tener ciertas limitaciones importantes, y en segundo lugar porque como corre en MSDOS, y ese sistema corre en modo real, eso me permitirá experimentar como me plazca (además, si se puede hacer con QBasic se puede hacer con Pascal, C, etc.). Por supuesto, no dispongo de una microcomputadora dedicada para instalarle el MSDOS, si la tuviera podría instalarle FreeDOS y listo, correría más rápido; y me imagino a los demás les pase lo mismo, aun si con una PC considerada ahora obsoleta sería suficiente, y es posible alguno tenga una tirada por ahí. Por eso me gustaría recomendarles a los interesados en seguir este tutorial se descarguen por Internet el DOSBox para correr el QBasic, y también este último entorno de desarrollo o uno compatible (existen muchos puesto BASIC es uno de los lenguajes de programación más utilizados a lo largo de la historia). Por si no lo saben, el DOSBox es un emulador desarrollado para correr programas hechos en su momento para MSDOS, y usándolo pueden ejecutar hasta el Windows 3.0 de principio de los años noventa (y seguramente también los Windows 1 o Windows 2 si por una casualidad los encuentran). Por último, como en ocasiones podríamos necesitar manipular los dispositivos a nivel del hardware, un emulador como el mencionado podría sernos de mucha utilidad para impedir dañemos la computadora si metemos la pata durante un experimento, porque nos puede servir como una capa de software intermedia o una caja de arena, y así aislar nuestro programa del hardware real del dispositivo.

Nota: El código de los programas del tutorial será corrido y probado por mí usando DOSBox en mi computadora, y por eso su funcionamiento estará garantizado, no obstante, no me hago responsable de ningún daño causado por éste en la computadora de otro, o de un daño se crea causado por dicho software, puesto es imposible suceda desde mi punto de vista.

Por supuesto, creo es innecesario mencionarlo, en un caso de desarrollo de una GUI para un sistema real sería imprescindible utilizar un lenguaje de programación diferente, o por lo menos un compilador del BASIC como FreeBASIC, dado no creo el lenguaje como tal sea culpable de las limitaciones; incluso, un lenguaje orientado a objetos facilitaría un montón las cosas, como se podrán imaginar, aun si con ese paradigma también se generan programas mucho más grandes y lentos para hacer la misma tarea, y por mi parte considero a C mucho más conveniente para implementar una API. Pero una vez más les digo, como esto nada más es un desarrollo con la única idea de divertirnos a la vez nos superamos, no necesitaremos nada más además de lo antes mencionado (salvo tener conocimientos básicos de programación); y con suerte los conceptos involucrados en el proceso de desarrollo de nuestra GUI sí nos serán de mucha utilidad para desarrollar un sistema de ventanas para una interfaz gráfica de usuario realmente utilizable.

Nota: La interfaz gráfica de usuario para un sistema real también necesita implementar un mecanismo para permitir su API sea llamada desde los programas de usuario, sin embargo, esta cuestión depende mucho de dónde se usará la interfaz, porque es dependiente del sistema operativo, y no será tratada en este tutorial, en el cual nos limitaremos a hacerla funcionar como un programa de usuario más.

En la próxima entrega comenzaré a escribir el código necesario en QBasic, y espero me perdonen si debo hacer cambios entre una entrega y otra, dado esto no es nada planificado y lo iré desarrollando casi improvisando; desarrollar un software de esta manera no es recomendable en lo absoluto, aun si nos puede ser útil en este caso para los fines perseguidos con este emprendimiento, y por eso no miren esta forma de hacer un programa como un modelo.

Por otro lado, en ocasiones los cambios no se deberán a no haber planificado, sino más bien a la necesidad de empezar haciendo las cosas del modo más simple para después ir agregando más y más características de manera lo entiendan hasta los menos experimentados, por eso espero nadie se impaciente.

Por ahora, antes de terminar, nada más me gustaría mencionar a Sebastian Mate, autor del GIMI del cual tomaré prestadas las ventanas para comenzar (más adelante las cambiaré y les comentaré los motivos en su momento), y tal vez más tarde use también un par de códigos más de su sistema si lo necesitamos; en el caso de las ventanas porque me parecieron bonitas (pueden ver una muestra el Figura 1 después de este párrafo), y en cuanto a los códigos de programación, para ahorrar tiempo y no reinventar la rueda a cada paso, porque casi siempre es más conveniente utilizar la experiencia acumulada por otra persona.

Figura 1: El modelo de ventana de la interfaz gráfica de GIMI.

Los interesados en estudiar dicha GUI para MSDOS (pueden ver su escritorio en la Figura 2 a continuación) seguro podrán encontrarla en Internet todavía, aun si por mi parte la conseguí hace mucho y no sé si seguirá disponible; me parece un programa interesante para estudiarlo, puesto que no se limita sólo a ser una interfaz gráfica, sino también es un intérprete de sus propios programas; el GIMI de Sebastian Mate es incluso capaz de implementar multitarea sobre MSDOS con un máximo de 20 procesos concurrentes, a pesar de correr lento debido en parte a estar desarrollado con QuickBasic, y en parte a interpretar sus programas como les he mencionado antes (el código tampoco parece estar para nada optimizado).

Figura 2: El escritorio de GIMI corriendo en DOSBox.

Por último debo decir el tutorial estará dividido en varias partes, cada una de ellas con un cierto número de entregas, y su continuidad dependerá del interés mostrado por ustedes en este tema de por sí sólo importante para una minoría de personas amantes de la programación de sistemas.

Me despido esperando serles de utilidad a pesar, como les mencioné, de ser el desarrollo de una GUI bastante poco práctico, y del todo inútil para conseguirse un empleo o ganar dinero, como también lo es desarrollar un sistema operativo en nuestros tiempos.

En todo caso, deben recordar recomendarme temas relacionados con la informática de los cuales deseen saber, tal como les comento en la página de inicio de este sitio, para así poder hacer un tutorial sobre ellos y superarnos todos en el proceso.

¡Hasta pronto!

Siguiente->
Esta entrada ha sido publicada en Cómo hacer..., Programación, Programación de sistemas y etiquetada como , , , , , . Guarda el enlace permanente.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.