Requisitos nuevos flamantes

Con vistas en el nuevo TP estamos acordando algunos requisitos bastante llamativos en relación a la implementación actual. A saber:

• El núcleo de la aplicación van a ser los inspectores y los skins. La interfaz principal como tal va a perder algo de protagonismo. De hecho, la idea es poder manipular skins e inspectores como componentes de modo que pueda haber otras formas de cargarlos, incluso como programas individuales.
  
• Queremos evitar la dependencia de GTK. Vamos a usar GTK como interfaz pero queremos poder usar otras cosas. Es decir, queremos poder hacer skins web o de consola, por ejemplo. También queremos que un cambio en GTK no sea demasiado traumático ni afecte a la implementación de los inspectores, solo a los skins. Esto tiene fuertes y traumáticas implicaciones:
• No podremos usar los stores de GTK como almacén para los modelos de los inspectores. Tendremos que definir una interfaz para acceder a los datos del modelo. Esto supondrá varias repercusiones en el rendimiento porque implica copiar (o indireccionar) el contenedor de datos del modelo a la vista.
  
• No podemos usar el UIManager para gestionar las "Actions" que pueden ofrecer los inspectores. Sin embargo, este sistema es muy flexible y quizá habría que copiarlo. De hecho ya lo copiamos en su momento sin saberlo.
  
• Y agarraos los machos! Queremos que esos "componentes" sean distribuidos. Es decir, algo como lo que GNOME intentó con BONOBO, pero nosotros lo vamos a hacer bien :-S Y claro, para eso vamos a usar Ice. Cada skin e inspector posible ES un servicio. Y nuestra amada/odiada factoría es substituida (en parte) por IceBox. Él va a instanciar y eliminar skins y inspectores.

Lo más llamativo puede ser lo de usar Ice, aunque no es tan sorprendente. Paco lo dijo desde el principio de los tiempos, a magmax también le convencía y a mi me llamaba la idea sobre todo por el tema de imponer interfaces férreas gracias al slice, aunque siempre me ha preocupado la penalización que van a tener las invocaciones remotas (aunque sean locales) dado que es «otra capa de mierda» y me temo que se hará cierta esa frase que dice

«Cualquier problema en ciencias de la computación puede ser solucionado con otra capa de indirección… pero usualmente creará otro problema» ― David Wheeler

Pero ciertamente tiene muchas ventajas que espero que podamos explotar:

• Hacer componentes en muchos y variados lenguajes. En particular esto nos permite prototipar en Python (aprovechando el código actual) y después las partes que sean estables, probadas y que sean críticas en cuanto a rendimiento se pueden pasar a C++.
  
• Manipular inspectores remotos o locales de forma transparente, de modo que se puedan interponer «inspectores-caché» o hacer aplicaciones GUI puras para dispositivos móviles.
  
• El modelo de datos puede estar perfectamente establecido por medio de un pequeño conjunto de interfaces, que como veremos se parece mucho a DUO, pues sigue el mismo principio: son interfaces de acceso puro a los datos, la semántica de los mismos la pone el que los interpreta.
• Es posible utilizar inspectores ya creados por el sistema u otro usuario.
  
• Hay muchas otras cosas que se pueden delegar a Ice:
• Persistencia de la configuración
• Gestión de la instanciación/liberación de los componentes
• Instalación/actualización de componentes. El sistema de plugins ahora es IceBox.

Pero usar Ice también plantea muchos problemas que tendremos que ir viendo y que trataremos en siguientes posts. Este es más que nada para que lo vayáis digiriendo. ;-)

La primera conclusión es que ahora queremos dos cosas: Un programa para interacción entre colecciones de objetos cualesquiera (TP) y una plataforma de componentes (que no tiene nombre aún).

Saludos

Widgets personalizados en la barra de tareas

Como ya sabéis (o deberíais) Twinpanel usa una encapsulación del ActionGroup de GTK (menu.ActionManager) dónde se pueden añadir de forma muy parecida a cómo se hace en GTK acciones que se mostrarán, dependiendo de la "location" especificada, en la barra de menú o en la de herramientas.

El problema de esto es que GTK solo proporciona algunos tipos de acciones (gtk.Action y algunos más) que generan elementos en el menú de herramientas, lo que hace imposible en principio añadir un widget genérico en dicha barra.

Para poder hacer esto se debe crear una especialización de gtk.Action (de forma que el ActionGroup de GTK pueda aceptarlo como acción), registrarlo en la factoría de tipos de GObject y, tras ello, decirle que tipo de widget debe representar. El widget a su vez debe ser una especialización de gtk.ToolItem.

¿Lioso? Bueno, no tanto. Como nosotros queremos añadir un widget personalizado tan solo deberíamos crear una especialización del gtk.ToolItem y, al ser estos también especialización de gtk.Container, añadir nuestro widget en ellos (y, por supuesto, no os olvidéis de hacer el "show" de nuestro widget).

Con esto he creado un pequeño ejemplo que se puede ver en el fichero widget.py de la distribución "stable"de Twinpanel.

Tenemos una clase "SpinAction", que hereda de gtk.Action y está registrada en la factoría de Gobject. La especialización de ToolItem en este caso es "SpinToolButton", que en su constructor crea un SpinButton y se lo añade y muestra. Además tiene una serie de métodos, propios de SpinButton, que nos permite acceder y modificar su valor, además de los callbacks que se conectan con los de SpinButton para emitir nuestras propias señales (que por supuesto están registradas en gobject unas líneas más abajo).

Con esto simplemente tendremos que crear una instancia de SpinAction y añadirla a nuestro ActionManager con "add_real_action" (TODO: debe cambiarse dicho nombre para que sea "add_action", y cambiar el actual "add_action" a algo más apropiado).

Lo mismo que con el ejemplo que acabo de explicar estoy intentando hacer con el MenuToolButton, para que podamos añadir una acción que defina un botón con menú asociado (al estilo de los que vemos todos los días en el navegador en los botones "Atrás" y "Adelante"). Lo malo de este tipo es que tiene un menú asociado, y añadirlo en tiempo de "diseño" de la interfaz parece que va a requerir algunos cambios en Twinpanel...

Rediseño del TwinPanel

Pues parece que vamos a hacer cierto rediseño del núcleo de TP dado que hay algunos problemas importantes que debemos resolver. Estos son algunos  de los más urgentes:

• No hay ninguna forma mínimamente cómoda de hacer baterías de pruebas.  Hay que pensar una forma lo menos invasiva posible de poder comprobar entradas y salidas. Yo estoy trabajando en un proyecto para hacer pruebas automáticas de GUIs, pero sería bueno poder probar el modelo sin GUI, o con una capa de presentación alternativa basada en linea de comandos o algún medio de comunicación programático.
  

• Los «stores» (ListStore y TreeStore) provocan mucha contención y no están convenientemente probados. Probablemente son la causa más importante de los cuelgues actuales de TP debido a la tácita enemistad entre GTK y los hilos.

• El diseño basado en método y dominio no escala. Quedan muchos casos que ese modelo no cubre y complica el uso de la factoría. Necesitamos una forma de abstraer el acceso (http, ftp, ice, etc) del modelo (multimedia, repositorio, sensor, etc).

• Muchas de las interacciones entre plugins y core no están definidas por interfaces. Necesitamos documentar e imponer interfaces concretas de modo que TP se niegue a cargar plugins que no cumplan la interfaz. zope-interface parece una buena solución pero la hemos aplicado a muy pocas interfaces hasta el momento.
  

• Necesitamos un sistema de instalación y activación/desactivación de plugins, de modo que los que den problemas se "desactiven" automáticamente evitando la ristra de errores que aparecen al arrancar la aplicación.

Lo bueno es que todos estos cambios afectan (o deberían afectar) muy poco a los plugins que es dónde está la mayor parte del trabajo hecho hasta la fecha.

David me dijo que Carlos está trabajando ya en algunos de estos problemas, principalmente en cuestiones de captura de requisitos y diseño pero no he sabido nada más. Empieza a ser urgente ponernos con esto porque la bola de nieve sigue creciendo y empieza a ser preocupante. Personalmente ha llegado un punto en el que me da miedo añadir o modificar nada en TP porque es imposible saber las consecuencias que tiene en el resto de la aplicación.

Galería de imágenes

He decidido añadir algunas imágenes de cómo se va viendo la aplicación.




Aquí podemos observar los paneles gemelos. A la izquierda está la lista de plugins (que es jerarquizable y, por tanto, se puede navegar) y a la derecha la lista de directorios. Se pueden ver también los tabs de distintas rutas.





En esta otra imagen está un netstat tal cual se ve :-D






Y aquí está la vista del ping.

Pensaba poner también la lista de créditos, pero como sólo se iba a ver a uno de los creadores, creo que iba a ser algo muy feo y no la he añadido :-D