Textos. Procedimientos

OOo Basic vs. Python. Aplicación simple de texto

Tomando como referencia la información que aportan las fuentes consultadas y algunas más, voy a iniciar el estudio del uso de TkInter (Tk) partiendo de la exposición y explicación del funcionamiento de una sencilla aplicación de escritorio basada en Tk. Esta aplicación no está pensada específicamente para un SEO, pero tampoco cabe esperarlo; precisamente uno de los objetivos (finales) de este blog es aprender a crear este tipo de aplicaciones.

Como dije en la entrada anterior, el modelo que tenemos presente es el de creación de GUI en OOo Basic, así que bueno será explicitar el esquema básico de su desarrollo para tener presente el punto de partida.

En OOo Basic partimos de tras opciones GUI que se pueden presentar en estado puro o en diferentes combinaciones:

• Las ventanas emergentes (MsgBox e Input/InputBox), que se construyen por entero mediante código (de hecho son las únicas que se construyen de este modo).
• Los formularios, que se construyen manualmente implementado los controles (widgets) sobre el documento del servicio.
• Y los cuadros de diálogo, que se construyen desde el IDE y se superponen al documento a modo de ventanas emergentes.

Formularios y cuadros de diálogo se construyen manualmente, no mediante código, aunque sí es posible manipular su funcionamiento u acceder a su contenido mediante script.

Es esta la primera diferencia que nos encontramos respecto a Tk, ya que la interfaz que creemos mediante Python deberemos crearla directamente desde el código. Más adelante veremos cómo.

Aunque se pueden dar diferentes modos de trabajo y funcionamiento, el algoritmo que he empleado con más frecuencia en los docap que he creado se basan en el siguiente procedimiento:

La fase de entrada (input) se representa por un formulario (o cuadro de diálogo) que consta de una serie de controles, uno de ellos un botón de comando, que sugiere que detrás de la interfaz también hay código asociado (en este caso al menos una función que se activa con ese comando).

En la fase procesamiento se diferencian 5 fases las cuales describo a continuación:

1. Con la fase 1 se asocia el contenido de los controles del formulario a variables de tipo objeto. Esto es necesario por ser los controles objetos.
2. La fase 2 supone la asignación del contenido de las variables objeto de paso 1 a variables tipo string, integer, booleano o del tipo que corresponda. Esta fase, aunque posiblemente innecesaria, me permite trabajar con el contenido capturado de los controles con mayor comodidad y de forma más comprensible y simple.
3. Trabajo que se desarrolla en la fase 3, representada con un icono que ilustra el procesamiento de esas variables mediante las estructuras lógicas del lenguaje.
4. De nuevo reconvertimos las variables de la fase 2 a variables objeto (4)..
5. ... ya que el proceso de almacenamiento (fase 5) para exponer en el soporte correspondiente (fase salida) requiere de nuevo manejar objetos.

Finalmente la fase de salida (output) presenta peculiaridades en un docap peculiaridad que la diferencia radicalmente de lo que podemos esperar de un programa creado con Python.

Aquí la represento mediante esos dos iconos, el primero y superior se puede identificar con el documento del servicio sobre el que se construye el docap, y el inferior el soporte que puede identificarse con el anterior en unos casos, o diferenciarse en otros, pero que en todo caso se identifica con la posibilidad (opcional, pero frecuente) de trasladar a papel el resultado obtenido, previo paso por el formato .pdf, o directamente como documento .odt.

Partiendo, como prometí, del ejemplo de sencilla aplicación de escritorio construida en Python con interfaz gráfico basado en Tk, voy a analizar las semejanzas y diferencias entre docap y aplicación; pero antes es necesario explicar qué identifica y cómo se entiende una aplicación (gráfica) de escritorio (1):

•  Es una aplicación y no un docap, ya que no se basa ni queda delimitada por un servicio de un paquete ofimático (vg. el procesador de texto o la hoja de cálculo).
• Se identifica como de escritorio por oposición al soporte web. Esto implica que funciona de forma independiente a cualquier programa y que no requiere acceso a la red.
• Es gráfica por utilizar una interfaz gráfica (GUI) tanto para la entrada de datos como para la salida.
• Y es encilla porque omitimos (en estos momentos) cualquier complejidad añadida como el almacenamiento de la información resultante. 

Iniciar este proyecto requiere despejar algunas dudas cuya solución es previa al desarrollo de nuestra propuesta: las funciones, las librerías (bibliotecas) de funciones y su uso en un proyecto.

Efectivamente, ya sabemos que TkInter está incluido en Python, lo que quiere decir que sus módulos (bibliotecas) de funciones están disponibles sin necesidad de tener que instalarlas (cosa que no sucede con otras librerías, con lo que esto implica), pero no están disponibles directamente: hace falta llamarlas o lo que es lo mismo, importarlas.

He manejado aquí cuatro conceptos que es necesario aclarar para poder avanzar; pero no vamos hacerlo en esta entrada, ya que resultaría un texto muy largo y complejo. En su lugar, utilizaré el principio de modularidad y una de las ventajas del hipertexto para dirigirte como potencial interesado a documentación específica que entronca con el enfoque sistemático de aprendizaje de Python que también estamos desarrollando en este blog (2).

• Concepto de función y su posición en el algoritmo. Una primera aproximación en esta entrada.
• Aproximación al concepto de paquetes y librerías (bibliotecas).
• Instalar paquetes que no forman parte del núcleo principal del Python.
• Importar componentes. Diferentes formas.

Para no demorar más la presentación de una primera aplicación de escritorio, y más por interés didáctico que funcional, paso a comentar mi primer script Python, creación a medio camino entre un mero ejercicio y una primera (y muy básica) aplicación de escritorio basada en interfaz gráfica. Los dos archivos de que está compuesta son accesibles al final de esta entrada. Este análisis o comentario del código se realiza en comparación con la construcción paralela del mismo script en soporte OOo Basic (3).

Creé este proyecto sobre dos bases: 

• En cuanto al contenido, basándome en la creación  de informes a partir de los datos recabados mediante formulario. Este modo de trabajo (que aquí se presenta simplificado en exceso) es muy habitual como docap OOo Basic debido a la utilidad que tiene para nuestro trabajo, de modo que son muchas los docap que he creado dentro de esta perspectiva. Partir de ella para crea una aplicación en Python facilita la comparación de procedimientos entre ambos lenguajes.
• y a nivel de lenguaje de programación, me he basado en las fuentes documentales contenidas en los vídeos de [Píldoras informáticas], pero también en algunos de los [videos de esta fuente] sin la cual, he de reconocer, me habría sido difícil resolver algunas cuestiones fundamentales para el correcto funcionamiento de la aplicación (4).

La primera diferencia que se aprecia entre OOo Basic y Python cierto es que se debe en gran parte al recurso empleado para crear el formulario en Python, ya que TkInter no dispone de soporte para crear visualmente el formulario, lo que obliga a crearlo directamente mediante código. Un breve análisis cuantitativo del código Python revela que hasta cerca del 69% del total de las palabras empleadas en su escritura están dedicadas a la creación de la interfaz, lo que deja un 32% para el funcionamiento del script, esto es: más del doble del código teclado se dedica a construir el formulario que a determinar su funcionamiento (5). 

La segunda diferencia tiene que ver con el acceso a contenidos externos, algo que también se puede dar en OOo Basic, pero de forma muy limitada, pero que es muy habitual en Python, lo que indica la fuerte presencia de la modularidad y el peso del paradigma funcional en éste frente al peso del modelo jerárquico y lineal de OOo Basic. Como ejemplo valgan dos cuestiones:

• En Python iniciamos el script llamando a la librería TkInter

from tkinter import *

•   ... y seguimos creando dos funciones básicas para el funcionamiento del script

def Guardar():

textoResult = vNombre.get() + " " +vApellidos.get()+ " cursa " + vCurso.get() + " en el " + vCentro.get()

vResultado.set(textoResult)

def Borrar():

vNombre.set("")

vApellidos.set("")

vCurso.set("")

vCentro.set("")

vResultado.set("")

... a lo que debemos añadir la función incorporada en el código que define el tercer comando (boton CERRAR), que por cierto plantea una peculiaridad respecto al modo de trabajar con funciones en Python, inexistente en OOo Basic (6).

cmdCerrar = Button(vs,text="CERRAR", fg="blue",font=("Arial",12), command=raiz.destroy) 

Me interesa destacar la simplicidad que presenta Python para asignar una función a un comando (command=Guardar), así como su versatilidad (las dos formas vistas antes, que no son las únicas).

También es de destacar la simplicidad con la que se consigue acceder al contenido de los controles (widged) en Python, frente a la complejidad que presenta en OOo Basic:

• Primero se asigna/declara (a) una variable su calidad de variable de clase:

vNombre = StringVar()

• Después se asocia con el contenido del control

txtNombre = Entry(vp, width=30, textvariable=vNombre, bg="#F0F8FF",...)

• Y finalmente, en la función se trabaja con las funciones .get()/.set() para acceder a su contenido, procesarlo y trasladarlo donde sea necesario. Véase en las funciones Guardar() y Borrar() vistas antes.

Para finalizar, me interesa hacer hincapié en el bucle con el que finaliza el script, ya que sin él no llegaríamos a captar su existencia: raiz.mainloop(). Como recordaremos por lo dicho en otro momento, tan importante como el propio bucle es la posición que ocupa en el script.

En resumen:

• Con Python es mucho más sencillo crear aplicaciones similares a docap, aunque para alcanzar el mismo nivel de funcionalidad es necesario un nivel de conocimiento del lenguaje muy superior al que se necesita en OOo Basic. 
• La construcción del soporte gráfico del formulario resulta muy complejo en Python, dado que TkInter no cuenta con soporte gráfico (framework) para crear el formulario. Si bien es posible reducir este hándicap empleando otros recursos que sí disponen de framework, esto no significa necesariamente  una reducción significativa de la complejidad del proceso.
• Acceder al contenido de los controles (widget) y el procesamiento de esta información es mucho más sencillo en Python que en OOo Basic. Lo es aun sin haber desarrollado todo el potencial de ese lenguaje, ya que únicamente nos hemos limitado a los enfoques jerárquico y funcional, estando pendiente trabajar desde el enfoque de la programación orientada a objetos (PPO), de la que el uso de las variables de clase es un adelanto.
• No obstante, desde una perspectiva de funcionalidad, inversión de tiempo y esfuerzo, y aprovechamiento de los conocimientos adquiridos a partir de la práctica, desarrollar docap basados en script (OOo Basic o VBA) conlleva ventajas inmediatas sobre lo que implica el aprendizaje de lenguajes de programación, incluso del tipo de Python.

Seguiremos profundizando en estas cuestiones. De momento aquí te dejo los enlaces prometidos. Recuerda que tienes que descargar ambos y ubicarlos en las misma carpeta, sea esta cual sea.

• Script Python
• Icono

NOTAS

(1) Un ejemplo representativo de este tipo de aplicación es la calculadora, herramienta presente en todos los sistemas operativos y que frecuentemente se realiza como proyecto en esta fase del proceso de aprendizaje, aunque ahora no será el caso.

(2) De paso evitamos al usuario o usuaria que ya conozca estos temas que pierda el tiempo repasando esos conceptos con lo que nos adaptamos de este modo a los diferentes niveles de conocimientos previos del lector o lectora, practicando así uno de los principios básicos del modelo inclusivo.

(3) La utilidad práctica de esta aplicación es nula, por lo que, desde esta perspectiva, no se puede considerar un proyecto en sentido estricto, estando realmente más cerca a un ejercicio. No obstante, funcionalmente tiene todos los ingredientes para ser modelo de aplicación de escritorio, eso sí, simple en estructura y funcionamiento, pero aplicación al fin y al cabo. Sólo es cuestión de utilidad, lo que exige, además de imaginación,  posiblemente también un incremento (cuantitativo y cualitativo) de su complejidad para que sea una auténtica aplicación de escritorio. Estamos en los comienzos y es aun largo el camino por recorrer, por lo que hará falta crear muchas otras aplicaciones de este tipo para lograr niveles adecuados de habilidad y de funcionalidad.

(4) La creación del icono de la ventana TkInter fue posible [gracias a una aplicación on-line], que los realiza a partir de una imagen que aporta el usuario o usuaria. Uno de los dos archivos que te dejo al final de la entrada es precisamente el icono, que es necesario para el correcto funcionamiento del formulario TkInter: lo debes situarlo en la misma carpeta donde copies el script de Python.

(5) Cosa que sí se da en otras opciones, como  PYQT (ver Cuevas Álvarez (2016) Cap 8) sí dispone de un framework o ventaja de trabajo con esa utilidad.

(6) Esta línea nos permite observar el peso relativo de la codificación destinada a la creación del formulario (en rojo) frente a su funcionamiento (en azul). Además nos permite apreciar la posibilidad de trabajar con funciones (y funcionalidades) directamente, frente al modelo indirecto (invocar funciones) que representa el código de los otros dos comandos ( a modo de ejemplo:) cmdVer = Button(vp,text="VISUALIZAR", fg="blue",font=("Arial",12),command=Guardar)