Ir al contenido principal

Sesion 4

 Aquí tienes el **Technical Journal** de nuestra sesión de ingeniería, documentando la evolución del código y las decisiones técnicas tomadas.


---


# Technical Journal: Desarrollo de Entorno de Escritorio TUI con Python y Urwid


**Fecha:** 23 de Mayo de 2024

**Tecnologías:** Python 3.x, Urwid, Psutil

**Rol:** Senior Technical Documenter


---


### 1. Contexto Inicial y Premisa

**Perfil del Usuario:** Desarrollador con conocimientos intermedios de Python, interesado en interfaces de usuario basadas en texto (TUI) y simulación de sistemas operativos.

**Necesidad Implícita:** El usuario buscaba transicionar de un simple script de menús (launcher de comandos bash como `bc` o `ls`) a una aplicación integrada y cohesiva. No bastaba con ejecutar comandos externos; se requiera "simular" un entorno de escritorio donde las herramientas (calculadora, gestor de archivos) vivieran dentro de la misma interfaz gráfica.

**Objetivo:** Crear un "Mini Sistema Operativo" en consola que sea funcional, estéticamente agradable y capaz de auto-monitorearse.


---


### 2. Definición del Desafío (The Core Challenge)

El desafío técnico principal no era la lógica de la calculadora o el listado de archivos, sino la **Gestión del Event Loop y el Estado de la Interfaz**.


Las variables críticas fueron:

1.  **Integración de Widgets:** Pasar de `os.system('clear')` a widgets nativos de `urwid` (`WidgetWrap`) que mantengan el estado visual sin romper el flujo del programa.

2.  **Manejo de Layouts:** Urwid es estricto con los tipos de widgets (Box vs Flow). Un error común es intentar aplicar propiedades de relleno (padding) en dimensiones que el widget contenedor no soporta.

3.  **Concurrencia Simulada:** Implementar un monitor de recursos (CPU/RAM) en tiempo real sin bloquear la interfaz de usuario, dado que `urwid` corre en un solo hilo principal.

4.  **Interacción Híbrida:** Lograr que la calculadora responda tanto a clics del mouse como a eventos de teclado físico (Numpad).


---


### 3. Iteración de Soluciones y Pivotaje


#### Fase 1: De Shell a GUI (La primera propuesta)

*   **Acción:** Reemplacé las llamadas a `subprocess` por clases `CalculadoraWidget` y `FileManagerWidget`.

*   **Resultado:** Se logró una interfaz visual, pero surgió un error crítico de ejecución (`TypeError: Padding.__init__`).

*   **Pivotaje:** Se identificó que `urwid.Padding` no acepta el argumento `bottom`. La solución arquitectónica fue cambiar la estrategia de espaciado: en lugar de propiedades de margen, se insertaron widgets divisores (`urwid.Divider`) dentro de la estructura de pila (`urwid.Pile`).


#### Fase 2: Introspección del Sistema (Monitor de Recursos)

*   **Solicitud:** El usuario requirió medir el consumo de CPU y RAM del propio proceso.

*   **Análisis:** Ejecutar un comando externo como `htop` rompe la inmersión de la TUI.

*   **Solución:** Se integró la librería `psutil`.

*   **Desafío Técnico:** No se puede usar un `while True` para actualizar el reloj/monitor porque congelaría la UI.

*   **Implementación:** Se utilizó el mecanismo de "alarmas" del MainLoop (`loop.set_alarm_in`), creando una recursividad asíncrona que actualiza la barra de estado cada segundo sin bloquear el hilo principal.


#### Fase 3: Refinamiento de UX y Estética

*   **Solicitud:** Mejorar colores y habilitar el teclado para la calculadora.

*   **Solución:**

    *   **Event Handling:** Se sobrescribió el método `keypress` en `CalculadoraWidget` para capturar teclas numéricas, `Enter` (calcular) y `Backspace` (borrar), mapeándolas a las funciones lógicas internas.

    *   **Paleta de Colores:** Se definió una paleta de alto contraste inspirada en herramientas clásicas como *Midnight Commander* (fondos azules/grises, textos blancos brillantes y focos en rojo/cian), mejorando la legibilidad y la jerarquía visual.


---


### 4. Arquitectura de la Solución Final


El sistema resultante es una aplicación monolítica estructurada en **Widgets Modulares** bajo un **Event Loop** central.


*   **Core (`MiniSistema`):** Controlador principal. Inicializa el `MainLoop`, gestiona la paleta de colores y maneja la ventana principal (`urwid.Frame`). Contiene el "Heartbeat" (alarma) que consulta a `psutil` y actualiza el footer.

*   **Capa de Presentación (Overlays):** Las aplicaciones no reemplazan la pantalla completa, sino que se instancian como `urwid.Overlay` (ventanas flotantes) sobre el `urwid.Frame` base, simulando un gestor de ventanas.

*   **Módulos Funcionales:**

    *   **Calculadora:** Implementa lógica de evaluación segura (`eval` controlado) y mapeo de eventos de hardware (teclado) a acciones de software.

    *   **File Manager:** Utiliza `os` para recorrer directorios reales. Mantiene un estado de `path_actual` y refresca dinámicamente el `ListBox` al navegar.

*   **Monitor de Recursos:** Instancia un objeto `psutil.Process(os.getpid())` para obtener métricas exclusivas del script en ejecución (RSS memory y CPU usage).


---


### 5. Conclusión y Valor Transferible


Tras esta sesión, has adquirido competencias clave en:


1.  **Programación Orientada a Eventos (Event-Driven UI):** Has aprendido que en una UI, no "esperas" input en un bucle; defines *callbacks* y *alarmas*. El programa reacciona, no espera linealmente.

2.  **Introspección de Procesos (Python Psutil):** Ahora sabes cómo una aplicación puede "mirarse a sí misma" para reportar su salud (uso de memoria y CPU) en tiempo real, una técnica vital para desarrollar dashboards y herramientas de servidor.

3.  **Arquitectura de Componentes TUI:** Entiendes la diferencia entre widgets de flujo (Flow) y de caja (Box), y cómo anidarlos (Columns dentro de Piles dentro de Fillers) para crear layouts complejos sin usar coordenadas absolutas.

4.  **Manejo de Input Híbrido:** La capacidad de unificar la lógica de botones en pantalla con teclas físicas mediante la intercepción del método `keypress`.


Este conocimiento es directamente transferible a la creación de **herramientas CLI profesionales**, paneles de control para servidores headless, o scripts de instalación interactivos.

Comentarios

Entradas populares de este blog

Sesion 3

 **DOCUMENTO TÉCNICO REGISTRAL (TECHNICAL JOURNAL)** **Autor:** Senior Technical Writer / Arquitecto de Software **Proyecto:** "Mi Biblioteca Digital" - Evolución de Desktop a Web Contenerizada **Fecha de Sesión:** [Fecha Actual] --- ### 1. Contexto Inicial y Premisa La sesión comenzó con la solicitud de una aplicación de escritorio nativa para Debian Linux diseñada para gestionar, categorizar y medir el tiempo de lectura de documentos PDF.  **Suposiciones sobre el perfil del usuario:**  Basado en la consulta inicial, identifiqué a un usuario con conocimientos técnicos intermedios-avanzados, usuario de Linux, con una mentalidad orientada a la eficiencia (al sugerir C++) pero altamente pragmático (dispuesto a sacrificar rendimiento computacional por velocidad de desarrollo funcional).  **Necesidades implícitas:** El usuario no solo buscaba código, sino validación arquitectónica. Necesitaba un sistema de gestión documental personal (DMS) que cerrara la brecha entre el ...

Sesion1

 # 📓 TECHNICAL_JOURNAL_SESSION_01.md **Rol:** Senior Technical Documenter   **Tema:** Diseño de Arquitectura de Base de Datos para ISP (CRM & ERP)   **Stakeholder:** [Tu Usuario] --- ## 1. Contexto Inicial y Premisa **Análisis de la Entrada:** La sesión comenzó con una solicitud para conectar tablas basadas en una estructura HTML preexistente para un sistema de Gestión de ISP. *   **Suposición Inicial:** Asumí que el usuario tenía conocimientos intermedios de SQL y buscaba una validación de un esquema relacional estándar. *   **Necesidad Implícita Detectada:** A medida que avanzamos, se reveló que el usuario poseía la lógica de negocio (cómo funciona el ISP: clientes, planes, equipos, señal óptica), pero carecía del fundamento teórico de **Diseño de Base de Datos Relacional**. *   **Objetivo Real:** El usuario no buscaba solo un script SQL, sino entender **cómo traducir la realidad física** (una persona con un router y una deud...