Twin Panel

Primer prototipo TP 2.0

2010-01-12T02:01:00.000-08:00

¡Hola!

Según avanzamos en el diseño de la nueva versión de TwinPanel, se hace necesario "prototipar" determinadas cosas. De este modo, podemos capturar requisitos no visibles a primera vista, y comprobar en cierto modo la viabilidad de algunas propuestas.

Por eso, presentamos el primer prototipo escrito teniendo en cuenta parte del nuevo diseño. Básicamente está formado por dos partes: el entorno de objetos distribuidos y los clientes (aunque, en este caso, sólo hay uno ;) )

Aunque el prototipo es funcional, no está escrito a fuego, por lo que es posible que cambien muchas cosas. Aún así, vamos a desgranarlo un poco, para entenderlo bien.

Distributed Component Platform

El nombre todavía no es definitivo, pero de alguna forma hay que llamarlo. DCP es el conjunto de objetos (plugins, factorías, etc.) que dan servicio a los clientes. De el forman parte los sirvientes que presentan un modelo de datos o de acceso para determinado recurso, así como las factorías utilizadas para la gestión de estos componentes.

En el prototipo hay dos factorías. La primera gestiona los plugins que proveen modelos de acceso a determinado recurso. Tiene un método, getThingFromURI, que analiza una URI, y crea un sirviente para dar acceso a esa URI. El objeto que se retorna puede tener diferentes interfaces, dependiendo de los plugins que soporte. En el prototipo, sólo hay uno registrado, que presenta una interfaz de tipo FILE, y que soporta el esquema HTTP.

La segunda factoría, gestiona modelos de datos. Aunque la interfaz tiene varios métodos, el más interesante es simpleCreateDataModel, que crea un sirviente para un modelo de acceso determinado. Los plugins de esta factoría son capaces de "entender" y manipular el recurso, presentando una interfaz para manipularlo. El único plugin registrado en el prototipo es HTMLDir, que reconoce el formato HTML, lo "parsea" y genera una estructura de directorios con el contenido servido.

Cliente

La otra parte del prototipo es el cliente. Su cometido es sencillo: obtiene los proxies a las factorías antes mencionadas, y crea los sirvientes adecuados para explorar una URI de tipo HTTP (como "http://www.google.es"). Crea una interfaz gráfica muy sencilla (a modo de Skin) con un IconView para mostrar el modelo generado a partir del HTML.

He de remarcar que es un prototipo, por lo que no está depurado, no es tolerante a fallos y puede comportarse de forma indefinida, aunque por lo general, hará lo que le dices :) El código fuente está disponible para todo el que lo quiera probar. Depende de python-zeroc-ice y de pyicebox. Para probarlo, es necesario lanzar por un lado el DCP, usando:

$ ./launchFactories.sh

y por otro, el cliente, de una forma parecida a:

$ ./Client.py --Ice.Config=client.cfg http://www.google.es

Conclusiones

Todavía quedan muchas cosas por pulir:

Es necesario definir un mecanismo para registrar los plugins en las factorías correspondientes. En caso de que sea la factoría quien los cargue, es necesario establecer una interfaz para los plugins (interfaz que se implementará en el módulo).
Definir el mecanismo de interacción entre plugins, es decir, es necesario especificar aquellas interfaces que cierto plugin es capaz de manipular.
Se han de especificar las relaciones entre componentes activos, inactivos y no instanciados, así como los protocolos de reutilización, compartición y limpieza de recursos.
Es preciso determinar si es escalable o no, y la forma de hacerlo escalable. Por ejemplo, en un recurso con múltiples ficheros ¿se debería crear un sirviente por cada nodo? ¿Se podría utilizar un default servant?

Algo que he visto bastante acertado es la separación entre la "plataforma de componentes" y los clientes. Esto nos permite mucha flexibilidad a la hora de diseñar diferentes interfaces de usuario, o de hacer pruebas a la plataforma. También hace más sencillo entender todo como conjunto (divide y vencerás), y escribir sus partes, siempre que estas sean lo más ortogonales posible.

Descargas

Organización de ideas

2009-12-21T02:52:00.000-08:00

El pasado viernes estuvimos discutiendo algunos aspectos interesantes de TwinPanel. De ahí, obtuvimos varias ideas clave y otros puntos un poco difusos (al menos, para mi).

Partimos de la idea de Recurso, que fué una de las más controvertidas ;). Un Recurso no deja de ser un modelo (de acceso, si se quiere aclarar), al igual que los otros modelos que ya teníamos (los modelos de datos). La distinción que queríamos hacer principalmente se mantiene (la que diferencia entre el mecanismo de acceso a los datos, y la manipulación de estos), pero no se añade (a primera vista) una capa más (aunque esto es discutible :P)

Queremos respetar el MVC a toda costa, algo que me parece muy bunea idea, dada la pluralidad de interfaces de usuario que vamos a tener.

También quedó claro que la arquitectura para todo esto nos la provee perfectamente Ice, más concretamente IceBox + Slice. Usaremos el evictor de IceBox para gestionar dinámicamente los plugins instanciados (una pena que PyIceBox no tenga evictor, así que o lo implementamos o usamos otros lenguajes...). Por tanto, algo en lo que tenemos que trabajar primero es en la factoría de plugins.

Si, por ejemplo, queremos inspeccionar una URI dada, como "http://www.google.es", tendríamos primero que comprobar si denota un proxy válido (pues cualquier cosa que se desee explorar, deberá primero tener forma de proxy). Si no lo es, habrá un componente que se encargue de convertir esa URI. Ese componente, que posiblemente esté asociado a la factoría, deberá buscar un plugin capaz de manipular ese recurso, en este caso, un plugin para HTTP. Se creará (o se retornará) una instancia que manipule nuestra URI y ya tendremos el proxy que buscábamos (al modelo de acceso). Ahora, necesitaremos otro plugin para manipular el contenido del recurso, que se creará de forma análoga. Por último, una tercera entidad deberá representar de forma visual el contenido de los datos, aunque esta parte no es imprescindible, pues este modelo puede ser fuente para otro modelo, que a su vez... Sí, los modelos son 'stackables' :)

Como vemos, otra labor vital que resolverá parte de los problemas actuales de TP, será definir las interfaces para todos los tipos de modelos necesarios.

Un problema que tendremos que resolver será el mecanismo para decidir que modelo escoger. Por ejemplo, el de HTTP puede ofrecer una interfaz de tipo FILE, la más común. Pero también se puede diseñar un interfaz de tipo HTTP, que implemente los verbos correspondientes: get, post, etc. En el siguiente nivel (modelo de datos), ocurre exáctamente lo mismo, y también en la capa de presentación.

Por otra parte, en lo que se refiere a la factoría, también se han oido ideas curiosas que hay que resolver, como el hecho de que sea distribuida (y por tanto, sea necesario un mecanismo de descubrimiento de "factorías", o búsqueda, con algo como ASD.Search).

El caso es que esto está tomando un cáriz interesante :D Ahora te toca a ti, busca los siete gazapos :P

再见!

Un par de sugerencias

2009-12-08T13:08:00.000-08:00

Buenas llevo tiempo detrás de escribir un par de sugerencias, hasta ahora sólo he estado leyendo los post y comentarios, y hoy me he decidido a hacerlo. Tened en cuenta que aunque he estado mirando algo de código estoy muy muy verde, gracias por vuestra comprensión y espero que os sirvan de algo.

1) Desacoplar Twin Panel - GTK

Hasta ahora por temas de rendimiento Twin Panel utiliza TreeViewPanel de GTK como representación interna, pero para permitir el desacople con GTK o con cualquier otra tecnología se puede recurrir al patrón Factoría, de forma que según el tipo de interfaz requerida (puede seleccionarse a través de un fichero de configuración o un parámetro en el arranque), genere una instancia especifica que es utilizada a través de una interfaz genérica. Vamos con un ejemplo: Si a la factoría se le pide una instancia de la aplicación para escritorio, esta construirá un TreeViewPanel de GTK, como hasta ahora; si en lugar de esto se le llama solicitándole la aplicación para consola, devolverá una instancia con otra representación interna; pero ambas tienen la misma interfaz.

Es decir, sería necesario especificar una interfaz con los métodos necesarios para trabajar con los modelos de representación interna, de forma que se permita desacoplar la tecnología, y permitir además la implementación multiplataforma pero sin perder la eficiencia que proporciona el trabajar con un modelo interno específico.

2) Sobre la inspeción de recursos.

Como bien han comentado David y Oscar en anteriores posts, uno de los problemas de TP es que mezcla la forma de acceder a un recurso con la forma de analizar o usar dicho recurso.

Por lo tanto debe de haber un analizador de URIs que por un lado, sepa qué usar para acceder a ese recurso (según el método o protocolo que se haya especificado) y por otro lado decidir el inspector a usar.

Por ejemplo tenemos http://example.org/video.avi, ftp://example.org/video.avi para ese recurso una vez se accede a él a través de un protocolo, se pueden realizar diferentes acciones, como abrir el navegador web, abrir un dialogo para almacenar el fichero, mostrar un resumen de la información del vídeo, traer el vídeo, lanzar un reproductor, etc. Todas estas acciones pueden ser realizadas con el recurso definido por esa URI, por tanto, puede que según el tipo de protocolo y de fichero, y los inspectores que se tengan instalados, puede haber un despachador que tenga una serie de reglas definidas, de forma que pueda o bien ejecutar la regla seleccionada (o la establecida por defecto) o solicitar la elección de una acción (preguntar por la regla a ejecutar y permitiendo a su vez que sea guardada como regla por defecto). Este comportamiento es el similar al que tienen los sistemas operativos con respecto a un fichero, donde según su extensión pueden tener definido quién es el programa encargado en atender ese fichero, o pueden ofrecer una lista de candidatos y elegir quién lo va a atender.

De la misma forma, al instalar un plugin este registra una serie de tipos de recursos que puede atender. Y así el despachador puede saber mirando la reglas que tenga, si debe utilizar un inspector u otro, o debe ofrecer los posibles candidatos para atender ese recurso.

Y enlazando con el post anterior si se indica en la ruta al recurso el modo o forma de acceder se usará el indicado, si no se usará el marcado por defecto para este tipo de recurso o si no se preguntará al usuario.

URI, URL, URN y otras hierbas

2009-12-03T08:11:00.000-08:00

Todo Resource debe ser identificado de alguna forma. A ser posible, que sea 'human readable' (como el XML :P). Esto no es nada nuevo, pero sería interesante comentar las opciones que tenemos, sean o no estándar, y que se adapten a nuestras necesidades. Sobre todo, sería muy interesante poder coger cualquier 'identificador' estándar y poder explorarlo.

En la primera versión de TwinPanel, usábamos algo llamado 'URI', pero que no se adecuaba a ningún estándar. Por ejemplo, para explorar un objeto Ice, usábamos algo como "ice://objeto -t:tcp -h host -p 1234". En los objetos complejos, que tienen jerarquía, separábamos el objeto de la "ruta" hacia el nodo, por ejemplo "ice://[objeto -t:tcp -h host -p 1234]/cameras/garage/". Si además es necesario añadir autenticación, entonces se puede añadir antes del recurso, por ejemplo "ftp://user:passwd@hostname/path/to/file".

La primera parte de estas URIs (lo que hay antes del '://') especificaba el tipo de acceso al recurso (ice://, http://, etc.). Ahora bien, nos surge la necesidad de especificar el acceso al recurso, pero también el tipo del recurso. Por ejemplo, subversion utiliza uris de la forma 'svn+ssh://box/path'. El recurso es un repositorio subversion, y la forma de acceder a el es por medio de ssh. A nosotros nos pasa algo parecido. Por ejemplo, tenemos un fichero zip, accesible por medio de http. En este caso, se podría omitir el modelo y dejar que algún mecanismo de introspección detectara que es. Esto es muchas veces caro, y alguna inviable. Por eso, surge la necesidad de ampliar nuestro esquema de nombrado de recursos.

Un ejemplo algo más claro: una imagen SVG modelada como un byteseq de Ice. Si no se especifica de algún modo el contenido de ese byteseq, se puede interpretar de muchas formas. Se podría detectar, analizando el byteseq, pero para eso, habría que obtenerlo primero (además, no siempre es posible detectar así el modelo). También se podría especificar como una propiedad, pero entonces se complica si queremos modelarlo como otra cosa (por ejemplo, como texto plano). Si esta información la añadimos al identificador del recurso, es inmediata la elección del modelo, y nos permite cambiar fácilmente entre distintos modelos.

Ahora, sería interesante elegir un esquema de direccionamiento. Uno de ellos podría ser URN, un identificador independiente de la localización, que es un tipo de URI. Básicamente, este esquema se compone de un identificador del dominio, mas un identificador dependiente del dominio. Algo así como 'urn:ice:object@adapter'. Esto sería perfecto si no fuera por la cantidad de restricciones que tenemos para componer el identificador dependiente del dominio. Cosas vitales como '/' o '[]' no son admitidas. Sí lo son en formato hexadecimal, lo cual es una carga a la hora de trabajar manualmente con ellas. Una posible solución pasaría por permitir al usuario entrar URN 'prohibidas' y convertirlas inmediatamente para manipularlas internamente. Así, se adaptaría al estándar a la vez que serían manejables. En esos casos, obviamente, prescindiríamos del prefijo 'urn:', con lo que tendríamos cosas como 'http:svg:server/path/file.svg', que sería traducida internamente a 'urn:http:svg:server%40path%40file.svg', o algo parecido.

¿Qué opinais?

Interfaces: Resource

2009-11-27T02:32:00.000-08:00

¡Hola!

Creo que es hora de ir pensando en cosas más profundas. Por ejemplo, en definir las interfaces que hemos visto hasta ahora. Por estos lares ando con un poco de miedo, pues la causa del "fracaso" del anterior diseño fue esto mismo: un mal diseño. Meter la pata a estas alturas nos va a costar mucho posteriormente.

De todos modos, por algún sitio hay que empezar. Y supongo que con la experiencia anterior, podremos ahorrarnos algunos errores. ¿Y qué tal si empezamos por los Recursos? Ok.

Ya hemos definido lo que es un recurso. También se comentó lo interesante que sería que todos los recursos compartiesen una misma interfaz. Así, todos los tipos de Modelo que pueda haber son accesibles usando cualquier mecanismo de acceso.

Un inciso: propongo cambiar la nomenclatura: recurso por acceso, pues me parece más próximo a la realidad. En este post, usaré Access como el mecanismo de acceso al recurso (por ejemplo, HTTP, FTP, File, etc).

Por ejemplo, si tenemos un AccessHttp, y añadimos un Modelo nuevo, con sus correspondientes inspectores, no es necesario hacer nada especial para que este modelo use el AccessHttp. Esto es una ventaja considerable, pero para ello, tenemos que ver si sería posible acceder a todos los recursos existentes usando una misma interfaz.

Podemos intentar ver si TODOS los casos son factibles. O mejor, encontrar uno que no encaje. Veamos, el mecanismo de acceso que se utiliza más comunmente es el consabido par get/set. Supongamos que dotamos al acceso de esta interfaz:

class Recurso:
    def get(): pass
    def set(blob): pass

Para HTTP, FTP, File... es válida. Son accesos que te proporcionan el recurso entero. Si las condiciones te lo permiten, es viable. Veamos un caso más complejo: Ice/CORBA/etc. Aquí, dependemos del tipo del recurso. Si es un entero o un byteseq, se puede seguir usando. Pero, ¿y si el "objeto" tiene una interfaz más compleja, por ejemplo AVStreams? Tendríamos un problema. Claramente no nos sirve, porque a lo que estamos accediendo no es a un recurso que se pueda tratar como un fichero o una imagen.

Vemos que una úinca interfaz, aunque interesante, no es posible. Tendríamos que crear una para cada tipo de recurso. Ya no es dependiente del mecanismo de acceso, porque es posible acceder a una fichero zip usando Ice, o a un objeto Bool usando File. Tendríamos un Access para recursos de tipo, llamemosle Data, que cubre un amplio espectro de uso. Pero también habría un Access para otros tipos de recursos (hay que pensar cuales).

Esto complica la estructura. Ya no solo clasificamos los Access por el mecanismo de acceso (FTP, etc.), sino también por el tipo de recurso al que se accede (un "Data", etc.). Quizá no sea esto lo que queremos.

¿Qué pensáis? Necesito ideas...

[Edición] Se me ocurre que en el caso de objetos Ice con interfaces complejas, podríamos considerar que la interfaz es parte intrínseca del Objeto, y que es el inspector quien sabe como usarla. Así, tendríamos un Access que provee la capacidad de "llamar" a métodos Ice (ya sea usando Ice, HTTP o File), sin conocer la interfaz real (es decir, un Access con dynamic Ice). Delegamos en el inspector el tratamiento del recurso. Esto se parece a lo que teníamos, pero con la salvedad de que ahora el acceso al recurso es transparente para el inspector (el inspector pide los ice_ids del objeto, y si el AccessX los obtiene de una base de datos, eso no importa). Y lo que es más, el inspector no tiene porqué conocer siquiera si el objeto está implementado en Ice o en CORBA. Eso es tarea del Access.

Quizá este tratamiento se pueda generalizar. Así tendríamos sólo tres o cuatro tipos de Access.
La siguiente figura es un ejemplo de cómo lo veo:

Un Model concreto podría dar soporte a una interfaz Access, por ejemplo, a DataAccess, siendo independiente del Access real que se use (DAFile, DAIce, etc.).

¿Como lo véis? ¡¡Feedback!!

Cuestión de conceptos

2009-11-25T05:18:00.000-08:00

Bueno, dado el anterior post de David, ahora tengo claros algunos conceptos más. Pero, para mi sigue siendo un montón de ideas en el aire, con relaciones parciales entre ellas. Necesito ponerlas en algún sitio, establecer esas relaciones y verlo todo como un conjunto conexo. Por eso, me gustaría empezar a distinguir y definir conceptos. Por supuesto, las cosas que falten, ya sabéis... comentarios.

A primera vista, los conceptos son: Recurso, Modelo, URI, Factoría, Inspector, Skin... TwinPanel :P De momento, un conjunto de nombres. Pongámosle caras.

Recurso: es el "qué". Aquello que se quiere utilizar, es la entidad a la que se desea acceder (no se me ocurren palabras más genéricas que realmente digan algo). Por ejemplo, un fichero zip en un directorio ftp de cierta máquina de nuestra red (como URL, sería "ftp://abox/ftp/afile.zip"). A nivel de TP, el recurso se puede considerar como un "proxy", un representante de lo que se quiere utilizar, y que sabe como acceder a él. El recurso (para TP) encapsula el mecanismo de acceso a esa entidad.
Modelo: especifica cómo se debe manipular el recurso. En el ejemplo anterior, tendríamos un fichero comprimido. El "modelo" es quien sabe lo que se puede hacer con ese fichero comprimido: leer su contenido, descomprimirlo, añadir otros ficheros, etc. El modelo es una entidad abstracta, que será instanciada por los Inspectores.
URI: es un identificador del recurso. Bien puede decir qué es (URN), o bien dónde está (URL). Este concepto es el más claro, aunque su estructura no la tenga tan clara... :D
Factoría: es la entidad encargada de proveer los componentes necesarios para inspeccionar determinado recurso. Antes, era un componente bien conocido, pero puede que cambie un poco su "personalidad".
Inspector: es el encargado de tratar con el contenido del recurso. Es la instanciación de un modelo. Para cada modelo puede haber varios inspectores, dependiendo de factores como la tecnología usada para tratar el recurso. Así, para el zip, tendríamos un inspector que usase "zip", y podríamos tener otro que se sirviera de un mecanismo online para ver el fichero, por ejemplo.
Skin: es la representación del recurso de cara al usuario: la vista del mismo. Este concepto tampoco ha variado mucho desde sus inicios, aunque sí la tecnología subyacente (¡ahora puede estar distribuido!). Utiliza un inspector para acceder al recurso.

Voy a intentar desempolvar los conceptos de UML para dibujar un ejemplo de clases.

Aquí se representan sólo las relaciones entre recursos, modelos e inspectores, y con ejemplos para verlo un poco más claro.

Ahora, podemos discutir cosas. Por ejemplo, la interfaz que debe conocer un modelo de cierto recurso. Si es diferente para cada recurso, un modelo dado debe ser consciente de los recursos para los que está disponible, algo que no es desable. Entonces, debe ser la misma para todos los recursos. Habría que ver si es posible una interfaz que sea práctica para todos los casos posibles.

De todos modos, ¿qué pensáis?

Recursos y Modelos

2009-11-05T03:24:00.000-08:00

Uno de los problemas de diseño que tiene el TP actual es que no separamos claramente dos cosas:

El acceso al recurso
La forma de interpretar ese recurso

Eso nos llevó a varias soluciones basadas en métodos, dominios, inspectores y otras abstracciones que nunca acabaron de cuajar.

Pongo un ejemplo para que se vea claro. Imagina que tienes un fichero "trabajo.zip" en el directorio "cosas" en tú máquina y que estás sirviendo a la vez ese mismo directorio con un servidor web y uno ftp. Eso te da dos URI's posibles para acceder al fichero.

http://example.org/cosas/trabajo.zip
ftp://example.org/cosas/trabajo.zip

Para conseguir el fichero (el "recurso" en un sentido más general) puedes utilizar dos métodos distintos, pero no estás asumiendo aún nada sobre el contenido o estructura del fichero. Para eso necesitas un modelo (por medio de un inspector).

Ahora imagina que tienes un inspector capaz de visualizar un fichero .zip como si fuera un directorio, pudiendo ver el nombre de los ficheros y sus atributos. Esto no es nada nuevo, gvfs + file-roller hacen eso mismo hoy día en GNOME (o lo intentan).

La conclusión es que el mecanismo de acceso al recurso y la forma de entender el recurso DEBEN ser cosas diferentes y desacopladas. Eso no lo logramos en la versión actual de TP y es fuente de muchos problemas.

Así que yo distinguiría entre Recursos e Inspectores, de modo que los inspectores necesitan una referencia a un recurso y nunca acceden "físicamente" a ningún fichero ni dispositivo. Esto encaja perfectamente con el modelo de tres capas en el que el Recurso estaría en la capa de persistencia/acceso y el Inspector en la capa de modelo.

Ejemplos de Recursos: ftp, http, bluettooth, ssh, ice, etc.
Ejemplos de inspectores: zip, camera, json, media, hg, etc.

Desde el punto de vista de la plataforma eso es todo. Se asume que "alguien" crea un Recurso a partir de una URI y después le pasa la referencia a un Inspector. Algo como:

zip = InspectorZip(ResourceHTTP("http://example.org/cosas/trabajo.zip"))

Pero desde el punto de vista de TP debe haber una forma automágica de crear Recursos a partir de URI, algo que es en principio muy sencillo, basta mirar lo que hay antes del ://.

Pero además debe haber una forma de elegir el Inspector más adecuado y también tener la posibilidad de cambiarlo si el usuario quiere. Un .tgz se puede ver con un inspector de "gzip" pero también con uno de "unp".

En muchos casos eso se puede hacer mirando la extensión del fichero pero en otros no es tan fácil. Por ejemplo, un directorio que contiene un repo subversion... ¿cómo se sabe que lo es? "ssh://example.org/repos/mi_proyecto". Lo que hace subversion concretamente es crear una URI del tipo "svn+ssh://example.org/repos/mi_proyecto". Bueno, es una opción, pero estaría bien algo un poco más inteligente si es posible.

Otro caso es un objeto tipo "ice://objeto1 @ adaptador". Aquí el Recurso es Icd pero ¿qué Inspector usas? La forma de determinarlo es invocar el método ice_ids() del objeto y buscar inspectores que lo puedan manejar. Algo que es MUY distinto a mirar la extensión o el prefijo de la URI porque implica USAR el recurso.

Obviamente puede haber Inspectores que solo tengan sentido con un Recurso concreto pero eso no significa que deban estar acoplados, precisamente porque puede haber muchos Inspectores que pueden usar un mismo tipo de Recurso y algunos de ellos pueden no tener esa limitación.

Y para terminar, imagina que el zip del que hablaba antes contuviera a su vez un .tgz o una base de datos sqlite... También queremos verla...

Bueno, cómo véis, más problemas que soluciones... pero bueno, estamos capturando requisitos.

Recapitulemos

2009-11-05T02:04:00.000-08:00

Creo que podemos hacer un breve resumen de las cosas que tenemos hasta ahora. Por ejemplo, seguiremos pensando en usar patrones, pues eso nunca fué mala idea. Así pues, el MVC se seguirá respetando. Con lo que las entidades "inspector" y "skin" (por lo menos, lo que representan) seguirán estando presentes.

Twin Panel seguirá siendo un sistema plugable, por lo que no podemos dejar de usar una factoría, aunque su estructura cambie bastante.

Otra cuestión interesante que discutir, y que siempre ha sido bastante difusa, es la relación entre los métodos de acceso (los antes llamados "methods"), y los dominios; conceptos que siempre han dado que hablar.

Creo que una muy buena manera de ver los componentes y sus relaciones es utilizando un diagrama de secuencia. Voy a intentar esbozar uno, y con la ayuda de todos, lo vamos mejorando, ¿vale? :p Intentaré ser lo más genérico posible, puesto que todavía no hay nada determinado.

Un usuario desea explorar su carpeta personal. Para ello, lanzaría TP de una forma parecida a esta: $ tp file:///home/user .
tp (el binario/script que se ejecute) deberá analizar la URL, convertirla a la estructura que sea necesario, y pedir a "alguien" que se encargue de instanciar/despertar/... los componentes que entrarán en juego para la tarea. Lo podemos llamar "factoría", con comillas, pues puede que me cuele.
La "factoría" determina los componentes a usar, siempre que no se hayan especificado antes (como opciones de configuración, u otra cosa). Esta se encargará de que esos componentes estén accesibles, bien instanciándolos, bien despertándolos, etc.
Alguien deberá encargarse de configurar estos componentes. Por ejemplo, al "inspector" deberá decirsele la URL que está inspeccionando, o al skin dónde debe pintar.

Mmm, creo que faltan muchas cosas intermedias, pero seguramente que en estas cuatro básicas, ya he metido la pata...

Bueno, empieza la audiencia :D

Casos de uso

2009-11-04T04:45:00.000-08:00

En vista de los cambios que pronto afrontaremos, debemos tener siempre presente aquello para lo que, en principio, queremos usar Twin Panel. Este post intentará recoger los casos de uso, para así capturar requisitos y poder emprender el diseño.

Twin Panel debe ser una herramienta que permita explorar conjuntos de objetos. Casi cualquier cosa puede ser tratada como un objeto, desde un fichero hasta una máquina, o un mensaje. Dada esta pluralidad, es muy difícil concretar todos los casos de uso. Si encuentras alguno que falta, puedes comentarlo y se tendrá en cuenta.

Consideramos "contenedor" al elemento del sistema que posee al resto de elementos, siendo posible que estos, a su vez, sean "contenedores". Para evitar duplicar el texto, definimos los grupos de acciones permitidas:

Acciones Mínimas: listar elementos del "contenedor".
Acciones Básicas: las acciones mínimas, más: copiar, cortar, pegar, crear y eliminar elementos, entre nodos del mismo "contenedor".
Acciones Ampliadas: acciones básicas entre nodos de "contenedores" diferentes (compatibles).

La lista de casos de uso es la siguiente:

Exploración local de ficheros. Es el caso más obvio. Deber permitir explorar cualquier sistema de ficheros local (obviamente, que esté soportado por el kernel). Debe soportar las Acciones Ampliadas. El mecanismo de acceso podría ser GVFS.
Exploración remota de ficheros. La extensión al caso anterior. Los mecanismos de acceso pueden ser variados: SSH, FTP, Ice... Debe soportar las Acciones Ampliadas.
Explorar el conjunto de máquinas de una red. Deberían poderse listar tanto las máquinas (con sus nombres, IP's u otros identificadores), como los servicios que proveen. El conjunto de acciones permitido serían las Acciones Mínimas.
Visualizar los elementos que componen un documento web. Dependiendo del método de acceso, debería soportarse el conjunto de Acciones Básicas o Acciones Ampliadas.

Podríamos tener descripciones similares para los siguientes casos:

Objetos Ice
Elementos de UPnP
Servidor POP3
Dispositivos Bluetooth
Nodos ZigBee
Redes y AP's WiFi
Procesos del sistema
Puertos abiertos con sus servicios asociados
Bibliotecas multimedia (picassa, flickr, youtube...)
Entornos sensibles a localización (GIS)
Dispositivos X10 de un entorno
...

Examinando estos casos, surgen algunas cuestiones que tratar:

Debemos definir un mecanismo preciso para la interacción entre diferentes mecanismos de acceso a estos "contenedores" (por ejemplo, para copiar un fichero desde un SF remoto a uno local, usando SSH), algo que todavía no se había abordado.
Debemos ser muy estrictos con las interfaces que cada "plugin" debe cumplir. Uno de los problemas que presenta la versión actual es que no hay un conjunto bien definido de interfaces, lo que permite registrar plugins incompletos que desestabilizan el sistema.
Es necesario disponer de una buena documentación desde el principio. Si un desarrollador hace un plugin, pero no dispone de toda la documentación necesaria, perderá mucho tiempo, hará cosas duplicadas, y posiblemente causará otros problemas al resto del sistema.
Pruebas. He aprendido (por fin :D) que es un aspecto clave a la hora de desarrollar software. Como dice incansablemente David: "las pruebas merecen la pena", y yo añado "sin pruebas, se pierde tiempo y es muy difícil abordar problemas complejos (sin causar otros)".

Con el nuevo diseño que se está planteando, algunas de estas cosas se resuelven. Por ejemplo, el uso de interfaces; utilizando Zeroc-Ice, se fuerza la utilización de interfaces.

Sigamos discutiendo aspectos del diseño.

Requisitos nuevos flamantes

2009-11-04T03:07:00.000-08:00

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

2009-10-28T11:35:00.000-07:00

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

2009-09-17T02:16:00.000-07:00

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

2009-04-09T09:55:00.001-07:00

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

MItem

2008-10-04T07:53:00.000-07:00

Bueno, pues después de oir las duras críticas de Óscar, Magmax y las mías propias le he hecho algunos cambios al ModelCol. No supone un cambio muy importante, de hecho internamente no hay ningún cambio, solo en el API.

Lo primero es que ha cambiado de nombre, ahora se llama MItem, que viene a ser algo así como "elemento del modelo". Si el modelo es una tabla, el MItem puede describir una columna, que es el caso habitual, pero también se podría ver como una fila si se requiere.

No está ligado a TreeModel o TreeView, ni siquiera a GTK. A pesar de ello, lo voy a describir como el modelo de ListStore para que la explicación no quede tan abstracta. El MItem tiene los siguientes campos (todos opcionales):

title (str): Es el título de la cabecera de la columna.

render (str): Identifica al encargado de representar el dato en ese columna (en el caso de TreeView, será un CellRenderer). Si no se indica, el render por defecto es "text". El significado real del render depende del encargado de representar el modelo, por ejemplo, el skin_list.

id (int). Es una prioridad para esa columna. Lo usamos para crear los índices de ordenación. El "id" más alto es la columna de ordenación por defecto. Si una columna no tiene "id", no se puede ordenar por ella.

var (bool). Indica (si es True) que para una misma fila, los valores de esa columna pueden cambiar con el tiempo. Por ejemplo, en un inspector que muestra la lista de unidades de disco, la columna de "espacio libre" sería "var". Si no se indica, es "False" por defecto.

Los parámetros de MItem se indican como un diccionarios (kargs que se dice en Python). A parte de los anteriores, se pueden indicar como clave cualquier palabra que pueda ser utilizada para identificar una propiedad de la columna que describe, en nuestro caso, hasta ahora solo los hemos utilizado para indicar propiedades de los CellRendereres de los TreeViewColumn.

El valor de esas propiedades se puede indicar de dos modos:

Por instancia (o fila). En este caso, el identificador va precedido de un guión bajo (_nombre) y el valor es el nombre de un atributo de un objeto del modelo. Cada fila tiene un valor propio para esa propiedad. Suena complicado, pero en los ejemplos vais a ver que es muy sencillo.

Fijo (por columna). En este caso, el identificador debe ir precedido de un doble guión bajo (__nombre). El valor indicado se interpreta como un literal y se aplica a toda la columna.

Limitaciones

Los nombres de las propiedades no pueden empezar por guión bajo.

Los nombres de las propiedades tienen que ser identificadores Python válidos. En el caso de propiedades gobject, como "stock-id" el consumidor del metamodelo deberá hacer las transformaciones oportunas.

Ejemplos:

Voy a poner la versión MItem de los mismos ejemplo que para ModelCol. Si los comparáis veréis que el interfaz es más genérico y para el mismo caso es más corto casi siempre.


MItem(title='Name')
- Etiqueta de la columna: 'Name'
- Renderer: 'text'
- Asignar a la propiedad 'text' del renderer, el valor del atributo 'Name'

MItem(title='Name', _text='filename')
- Asignar a la propiedad 'text' el valor del atributo 'filename'

MItem(title='Name', id=10)
- Ordenar por esta columna, prioridad: 10

MItem(title='Value', _text='val', __xalign=1)
- Asignar a la propiedad 'text' el valor del atributo 'val'
- Justificar el texto de esta columna a la derecha

MItem(title="Level", _markup="level", id=10)
- Asignar a la propiedad 'markup' el valor del atributo 'level'
- Ordenar por esta columna, prioridad: 10

MItem(title='Variable', _text='key',
 __background='gray', __background-set=True)
- Asignar a la propiedad 'text' el valor del atributo 'key'
- Fijar color de fondo de esta columna a 'gray'

MItem(render='pixbuf', __stock-id='gtk-file')
- Columna sin título
- Renderer: 'pixbuf'
- Fijar la propiedad 'stock-id' a 'gtk-file' para cualquier fila

MItem(title='Identity', _text='key', _markup='format')
- Asignar a la propiedad 'text' el valor del atributo 'key'
- Asignar a la propiedad 'markup' el valor del atributo 'format'

MItem(render='pixbuf', _stock-id='icon')
- Columna sin título
- Renderer: 'pixbuf'
- Asignar a la propiedad 'stock-id' el valor del atributo 'icon'

MItem(title="Installed", render="toggle", _active='installed',
 __activatable=True)
- Renderer: 'toggle'
- Asignar a la propiedad 'active' el valor del atributo 'installed'
- Fijar la propiedad 'activatable' a True para todas las filas

Chrome tabs?

2008-09-18T00:49:00.000-07:00

En los primeros prototipos de twinpanel, teníamos la "barra de direcciones" dentro de la página del notebook pero la barra de herramientas fuera. Pensamos que por "usabilidad" era mejor dejar las dos cosas fuera del notebook como hacen (hacían) todos los navegadores.

El problema es que eso complica un poco la construcción del interfaz, porque al cambiar de solapa hay que configurar tanto la uri como la barra de botones de acuerdo al panel activo. Luego salió Google Chrome con su diseño "innovador" y me lo estoy volviendo a plantear: solapas arriba o solapas abajo? Tened en cuenta que de hacer el cambio, TwinPanel tendría una barra de herramientas y otra de URI en cada "side", lo que obviamente nos hace desperdiciar algo de espacio en la interfaz (no mucho).

by Google Chrome

ModelCol

2008-09-01T16:53:00.000-07:00

Como ya explicaba hace tiempo disponemos de un sistema muy versátil y sencillo para construir TreeView, gracias a los skin_list y skin_treeview y una especificación desacoplada del modelo (un metamodelo). Hasta ahora hemos podido implementar cualquier listado utilizando unicamente estos dos skins independientemente del número de columnas o su tipo. Un metamodelo está formado por una lista (vector de Python) de instancias de la clase ModelCol. Nombre muy largo por cierto, seguramente lo renombraré a MCol o algo más corto.

Lo siguiente es una lista de ejemplos de uso de ModelCol comentados. Quede aquí para futuras referencias. Este mismo listado lo meto en el fichero HowTo.ModelCol que está(rá) en el repo, y que iré ampliando.


ModelCol(title='Name')
- Etiqueta de la columna: 'Name'
- Renderer: Text
- Asignar a la propiedad 'text' del renderer, el valor del atributo 'Name'

ModelCol(title='Name', attr='filename')
- Asignar a la propiedad 'text' el valor del atributo 'filename'

ModelCol(title='Name', id=10)
- Ordenar por esta columna, prioridad: 10

ModelCol(title='Value', attr='val', static={'xalign':1})
- Asignar a la propiedad 'text' el valor del atributo 'val'
- Justificar el texto de esta columna a la derecha

ModelCol(title="Level", attr="level", id=10, prop='markup')
- Asignar a la propiedad 'markup' el valor del atributo 'level'
- Ordenar por esta columna, prioridad: 10

ModelCol(title='Variable', attr='key', static={'background':'gray',
                                       'background-set':True})
- Asignar a la propiedad 'text' el valor del atributo 'key'
- Fijar color de fondo de esta columna a 'gray'

ModelCol(render='pixbuf', static={'stock-id':'gtk-file'})
- Columna sin título
- Renderer: pixbuf
- Fijar la propiedad 'stock-id' a 'gtk-file' para todas las filas

ModelCol(title='Identity', attr='key', props={'markup':'format'})
- Asignar a la propiedad 'text' el valor del atributo 'key'
- Asignar a la propiedad 'markup' el valor del atributo 'format'

ModelCol(attr='icon', render='pixbuf', prop='stock-id')
- Columna sin título
- Renderer: Pixbuf
- Asignar a la propiedad 'stock-id' el valor del atributo 'icon'

ModelCol(title="Installed", render="toggle", prop="active", attr="installed",
      static={'activatable': True})
- Renderer: Toggle
- Asignar a la propiedad 'active' el valor del atributo 'installed'
- Fijar la propiedad 'activatable' a True

Aunque tiene muchas posibilidades, no es la panacea. Le faltan algunas cosas, pero creo que se podrá hacer sin demasiado problema. En especial:

- Soporte para desactivación/ocultación de columnas del modelo, a elección del usuario. Esto requiere un gestor de configuración que es en si mismo todo un reto (hablaremos de esto otro día)
- Soporte para formato de las columnas. Los datos se almacenan en crudo en el modelo. Por ejemplo, las fechas se almacenan en tiempo UNIX. Es el usuario el que elige el formato en el que desea que se representen (año-mes-día, mes-año, con hora, GMT, etc). De nuevo esto tiene mucho que ver con el gestor de configuración.

Después de lo cual concluyo que el soporte de ModelCol y de los skins es casi lo de menos. Necesitamos un gestor de configuración, que por la pinta va a ser casi tan complejo como el propio TwinPanel... mañana hablamos del tema...

PD: Una de las limitaciones que comentaba en el post de "probando, probando" está solventada como veis en los ejemplos. Me refiero a la que decía:

Cada elemento del metamodelo sólo puede afectar a un atributo de la columna correspondiente. Esta puede que sea una limitación inadmisible, habrá que discutirlo. Puede que en este caso esté justificado enriquecer el metamodelo para hacerlo posible.

PD: No dejéis esa cantidad abrumadora de comentarios que se me van a quitar las ganas de seguir escribiendo ;-)

Seguimos vivos

2008-08-31T15:24:00.000-07:00

A pesar de que el blog ha estado completamente parado durante prácticamente un año, el desarrollo de TwinPanel ha avanzado muchísimo. Aunque ha habido altibajos, el desarrollo no ha estado completamente parado en ningún momento. Gran parte de la culpa de la "desconexión" con el blog se debió al cambio de gnome-vfs a GIO por parte de GNOME.

Como ya comenté, decidimos utilizar gnome-vfs como backend para todos los inspectores relacionados con el sistema de ficheros, sftp, ftp, samba y demás. Al producirse el cambio a GIO, decidimos dejar en suspenso el desarrollo de esos inspectores hasta que estuvieran disponibles los bindings de Python para GIO, que por fin ha llegado. No pensé que tardaran tanto...

Aunque hay disponibles algunos inspectores funcionales, tengo claro que son demasiado específicos como para que TP pueda llamar la atención de potenciales usuarios beta-testers. Sin duda, disponer de los inspectores básicos de manejo de ficheros (gracias a GIO) permitirá dar un uso cotidiano a TP y podremos plantearnos en breve lanzar una primera release funcional que pueda descargarse, instalar y usar cualquiera que tenga interés en ello.

En breve escribiré un post hablando del diseño de TP, que en esencia ha seguido las directrices iniciales. También está en la recamara otro post sobre el sistema de instlación de plugins y su interacción con el sistema de gestión de paquetes de la distro. Óscar está escribiendo un tutorial para desarrollar un inspector desde cero. Espero que sea la primera piedra del futuro "Manual de TwinPanel para Desarrolladores". Y no menos importante, en los próximos días subiremos al repo de GNA! la primera versión funcional del core de TwinPanel y algunos inspectores y skins(las antiguas "vistas") para ir abriendo boca.

Hasta pronto.

¿Sabias que... usamos python-sexy?

2008-08-18T08:13:00.001-07:00

Si instalas el paquete python-sexy, ciertos widgets tendrán una apariencia y herramientas diferentes. Por ejemplo, es común que el 'GtkEntry' que aparece en los mensajes de error ahora tenga un icono para copiar la URI malformada y pegarla donde desees.

Probando, probando

2007-09-16T12:27:00.001-07:00

Pues como íbamos diciendo en posts anteriores, ya es hora de ir escribiendo algo de código. He puesto en el repo de twinpanel un ejemplo mínimo de inspector/vista/controlador llamado mvc.py.

Tal como hablábamos Oscar y yo, no es posible desacoplar totalmente vista y modelo cuando se usa "gtk.TreeView", ya que obliga a que el formato del modelo (colores y demás atributos) también esté en el modelo. A pesar de que rompe la idea de MVC, parece conveniente apostar por TreeView porque nos da gran parte del trabajo ya hecho.

Otro problema de TreeView es que, al menos en el uso habitual, la configuración de las columnas "visibles" (TreeViewColumn, TVC) se realiza en base al modelo (store) disponible, con lo cual hay mucho acoplamiento entre ambos. Y esto va totalmente en contra de nuestra idea de hacer vistas "plugables" que puedan utilizarse con muchos inspectores diferentes.

Afortunadamente, TreeView dispone de un mecanismo que permite rellenar las columnas utilizando un callback en lugar de indicar una columna de un store: set_cell_data_func(). Utilizando esta alternativa y definiendo un metamodelo (que describe el modelo) es posible hacer vistas totalmente genéricas, que se autoconfiguran en base a la información facilitada por cada inspector concreto.

En cualquier caso, TreeView sigue necesitando un store. Hemos optado por hacerlo lo más simple posible: un array de objetos. La clase de esos objetos la define cada inspector, y su metamodelo indica cómo obtener los datos a partir de los objetos contenidos en el store. De modo que es muy flexible y con el acoplamiento más pequeño posible (de los que se nos han ocurrido).

Tal cómo está implementado en el programa que refería, este sistema tiene algunas limitaciones:

Cada elemento del metamodelo corresponde a una columna de la vista. Por cada TVC, se crea un único 'cellrenderer' (indicado en el metamodelo). Se podría enriquecer el metamodelo para soportar varios cellrenders pero personalmente aquí aplicaría KISS.
Cada elemento del metamodelo sólo puede afectar a un atributo de la columna correspondiente. Esta puede que sea una limitación inadmisible, habrá que discutirlo. Puede que en este caso esté justificado enriquecer el metamodelo para hacerlo posible.
El store es una lista (ListStore) lo que implica que, en principio, no sería posible hacer vistas arbóreas. Yo creo que esto no es una limitación perjudicial en lo referente al store.
Raramente será admisible cargar toda una jerarquía en el modelo. Yo creo que sería más adecuada una solución similar a la de nautilus: sólo se cargan los hijos cuando se expande el árbol. Para lograr eso podríamos crear un nuevo inspector para ese directorio y combinar los nuevos objetos en el store existente. Aquí hay varias alternativas de implementación que habría que probar.
Al ser el store un array de objetos, las modificaciones en esos objetos no actualizan la vista. Esto sólo pasa con cambios asíncronos, por ejemplo, si cambia la fecha de un fichero cuando ya ha sido representado en la vista, ese cambio no se muestra. Se puede solucionar de una forma sencilla aunque no sé si muy elegante, forzando una modificación del store cuando sea necesaria. A la vez también es una ventaja, puesto que podemos modificar el modelo real sin que eso implique necesariamente que la vista deba recargarse.

Secuencia de operaciones:

Lo que voy a describir a continuación es un posible método para instanciación de inspectores y vistas. Una parte de esto es lo que pretende ser el ejemplo mvc.py.

Al arrancar TP se registran en una 'factoría abstracta' todos los inspectors y vistas disponibles.
El 'manager' recibe una petición para gestionar un uri.
El 'manager' pide a la factoría un inspector que pueda manejar esa uri (puede haber varios). Se instancia el inspector pasándole una referencia al manager.
El inspector crea un modelo básico, No hace falta calcular todos los datos hasta que sean necesarios (los pida la vista). Es decir, puede ser un modelo creado bajo demanda.
El 'manager' pide a la factoría una vista que pueda representar ese inspector (puede haber varios). Se instancia la vista pasándole una referencia al inspector.
La 'vista' se configura utilizando el metamodelo del inspector que se le pasa.
El 'manager' pide a la vista el 'gui' y lo incrusta en la UI dónde corresponda.

Como ya he dicho, el ejemplo del repo no tiene factoría ni manager (aún) pero creo que sirve para hacerse una idea.

Saludos, y espero comentarios.

Vistas e inspectores

2007-09-15T11:23:00.000-07:00

Después de discutirlo, hemos decidido que lo que antes llamábamos "frontends" pasarán a llamarse "vistas" (lo siento Oscar) y los "backends" pasarán a llamarse "inspectores", dado que los nombres anteriores eran demasiado genéricos.

Aparte de este pequeño apunte sobre nomenclatura, hay una cuestión que debemos decidir lo antes posible porque puede afectar mucho a la estructura, funcionalidad e interfaces de TP. Probablemente vamos a tener dos tipos de inspectores:

Los que manipulan un modelo compuesto, es decir, manejan una lista. Esto incluye los que pueden representar un tgz como la lista de ficheros que contiene, y similares.
Los que manipulan un objeto concreto (una hoja), es decir, un inspector que puede manipular una imagen, una película, etc. Normalmente TP utilizará aplicaciones externas para manejar hojas, pero es muy posible que se nos presente la necesidad de desarrollar algunas que no existen, dado el ámbito en el que pretendemos movernos con TP.

En el caso de los inspectores de archivos ('archives', o sea tar, zip, etc) parece claro que al explorarlos se crea un inspector cuya vista substituye a la actual (como hace Total Commander), pero, en el caso de los "inspectores de objetos discretos", ¿qué hacemos?

Sustituyen en el panel a la vista que los lanzó.
Crean una nueva solapa
Aparecen en una ventana diferente.

Me podéis decir que esto es simplemente una cuestión de configuración como hace firefox, pero en el caso de TP, esta decisión tiene implicaciones que no hay en firefox. Dado que TP asume que "el panel activo es el origen y el otro es el destino", elegir la opción 3 invalidaría ese principio. De modo que estaríamos dejando en la configuración algo que afecta mucho a las posibilidades de uso del inspector. Por otra parte, tenerlo como solapa (substituya o no a la que lo lanza) supone un problema de ortogonalidad puesto que rara vez tendrán sentido operaciones "inspector de discreto" <-> "inspector de compuesto", o sí?

No lo sé, ¿qué pensáis? ¿qué casos se os ocurren? Espero comentarios

Interfaces

2007-09-15T10:57:00.001-07:00

Mmmm, esto va despacito, pero al menos parece que no se nos va de la cabeza, y eso es señal de que queremos que tire para adelante.

Lo cierto es que la idea tras TP da para mucho, casi cada día se me ocurren posibles funcionalidades que TP podría tener con relativamente poco esfuerzo (y no soy el único). Visto con cierta perspectiva, TP va camino de convertirse en el programa con más features de la historia de la informática, de llegar a hacerse, claro. Un buen slogan para el proyecto sería: "The most featured thing manager in the world" :-)

Ahora en serio, las conclusiones de nuestras primeras reuniones deberían dar lugar a un documento de diseño importante: el diagrama de clases, como forma de concretar esas decisiones. También deberíamos escribir (aquí mismo) una Especificación de Requisitos del Sistema. Aquí el problema básico es que los requisitos de usuario son prácticamente imposibles de fijar. Dado que la potencia de TP está en su flexibilidad, cada restricción le resta interés.

Las "interfaces" (en el más amplio sentido de la palabra) van a determinar cuan flexible podrá ser TP, pero está claro que las necesitamos. Elegir mal las interfaces, hará que la complejidad sea pronto inmanejable. Resumiendo, dudo que seamos capaces de definir unas interfaces perfectas a la primera (ni a la segunda). Por eso, creo que lo mejor es pensar que estamos desarrollando un prototipo evolutivo/desechable que nos permitirá probar nuestras ideas y a su vez capturar nuevos requisitos. Pero tenemos que tener claro desde el principio que habrá que tirarlo casi todo a la basura unas cuantas veces antes de llegar a un compromiso entre flexibilidad y complejidad. A partir de ese momento, nos podremos poner a programar plugins como locos, pero no antes.

Conclusiones (2007-08-28)

2007-08-30T01:30:00.000-07:00

Motivación

El día 2007-08-28 celebramos una reunión David, Óscar y yo Miguel Ángel, con el objetivo de definir con mayor precisión el ámbito de la aplicación. Así mismo se pretendía comenzar la construcción de la aplicación.

Este texto recoge la mayor parte de las conclusiones de dicha reunión.

Ámbito

¿Hasta qué punto es bueno casarse con GTK? ¿Existirá la posibilidad de utilizar otra librería gráfica en el futuro (QT, ncurses, ...), de manera que reutilice la mayor parte de la aplicación? Si dependemos de GTK, la aplicación será más rápida, pero si no lo hacemos, será más dinámica.
La conclusión final es que no nos importa demasiado depender de GTK, ya que, al fin y al cabo, realmente no vamos a implementar ninguna otra interfaz.
Se utilizará un patrón modelo-vista-controlador. Las vistas serán componentes GTK que pueden cambiarse (árbol, lista, iconos, ...).
Por definición, la aplicación contendrá en todo momento dos paneles. Cada panel, un notebook y una línea que indique la URI actual, que sea editable y permita también el cambio de URI. Un cambio de URI puede provocar la destrucción del backend asociado a la página del notebook para cargar otro (ejemplo: estábamos en "/home" y pasamos a "smb://192.0.0.1"). Además, contendrá un log ocultable (que será un objeto que admite escribir partes de un texto - bien un treestore, bien un textarea - con formato).
Existirá una línea de órdenes global a ambos paneles, aunque siempre actuará sobre el panel activo.
Siempre existirá un panel activo y uno no activo. Sin embargo, esto no se puede tratar mediante el foco, ya que es probable que el foco pertenezca a la línea de órdenes anteriormente citada.
Un plugin puede contener una vista, un backend o bien una vista y un backend.

Operaciones del backends

En principio, se pueden dividir las operaciones realizables por el usuario en tres tipos:

Unarias: Siempre tendrán como origen y destino un único panel.
Binarias: Se requiere un panel de origen y uno de destino.
Externas: Requieren de un elemento externo a TwinPanel.

Operaciones unarias

Obtener lista de elementos que se pueden crear para un vector de URI determinadas. Si se solicita sin URI, se devolverá una lista de todos los objetos que el backend es capaz de crear. Si se proporciona más de una URI, el resultado serán los objetos creables en todos ellos.
El resultado se ofrecerá de la forma: id, cadena (nombre a mostrar), tipo (indefinido, folder, leaf), id del icono.
Obtener lista de elementos para una URI.
Obtener identificación y versión del backend.
Eliminar lista de URIs.
Mover lista de tupla de URIs.
Obtener lista de acciones soportadas para una lista de URIs. Si no se proporciona la lista, se devolverán todas las acciones soportadas por cualquier elemento del backend.
Existirán dos métodos: uno para las acciones más comunes (Abrir, borrar, copiar, pegar, ...) y otro para las propias del backend. La existencia de estos dos métodos queda justificada, ya que las acciones comunes serán una Hash, mientras que las acciones propias se devolverán en forma de lista.
Obtener un descriptor de fichero. Éste puede ser de lectura o de escritura.

Operaciones binarias

Copy. Se descompone en leer origen, escribir destino. Los permisos dependen de estas operaciones unarias.
Move. Se descompone en leer origen y borrar origen, escribir destino. Los permisos dependen de estas operaciones unarias.

Se obtiene el descriptor de fichero de origen de solo lectura.
Se obtiene el descriptor de fichero de destino de solo escritura.
Se van copiando los datos del origen al destino.

Esta opción siempre estará disponible para todos los backends.

Como bien me recuerda Oscar, existe la posibilidad de que un backend sea capaz de crear otro y cargarlo internamente para realizar distintas opciones (como las arriba citadas del archivo zip).

Operaciones externas

En principio no nos interesan. Se trabajará con el clipboard.

Glosario

Panel: Cada uno de los lados de nuestra aplicación.
URI: Cadena de texto que permite volver a generar un acceso a un punto
determinado de una estructura jerárquica de forma unívoca.
Backend: Objeto que permite tratar en última instancia un contenedor de
la estructura jerárquica.

What is Twin Panel?

2007-08-11T11:10:00.000-07:00

Usually navigators like MS IExplorer, Nautilus or Konqueror have not all the capabilities we want. And they have only one panel to operate.

There are a lot of programs with two panels: FreeCommander, TotalCommander, ... But all of them have any problem: or they are very limited, or they are non-free.

Now we want to forget everything we have found in these navigators, and we want to wonder "what in the hell I really need". We want to use it as a Computer Engineering practice, by using so many patterns as possible in design.

The result... Well. It must be the very best of the navigators, the last project in the bin or something in the middle. We will see it in the future.

How can you help us? Easy:

By using the betas and reporting the bugs.
By speaking about it to your friends.
By adding any plugin.

And that's all. Here you will find our Twin Panel, free like "freedom", and not like "free beer".

Thank you.

Obviedades

2007-08-11T10:35:00.000-07:00

Pues como dice el título, este post va sobre asunciones de perogrullo, o no tanto... El objetivo es que todos tengamos claros cuales son los elementos y objetivo básico de Twin Panel (TP). Aprovecho también para definir un poco de nomenclatura para que podamos discutir detalles sin volvernos locos.

Paneles

El panel es el componente esencial de TP. En principio la aplicación está pensada para facilitar las clásicas operaciones con ficheros que involucran un origen y un destino, idea más que explotada en aplicaciones como Midnight Commander, Total commander y otros tantos. Por esa razón, TP presentará por defecto 2 paneles (de ahí su nombre) aunque nuestra idea es que sea lo suficientemente flexible para soportar 2 bloques de n paneles cada uno.

Arquitectura

TP consta de tres elementos principales, que encajan perfectamente en el clásico modelo de tres capas.

Backends (persistencia). Son clases especializadas en filesystems, entendiendo filesystem de una manera un tanto peculiar como se verá después. TP sólo incluirá de serie un backend para gestión de ficheros y directorios. Los demás se distribuirán como plugins.

Frontends (presentación). Son clases especializadas en representación. Cada panel está ocupado por únicamente por un frontend. El frontend básico es una lista con columnas. Aunque están desacoplados, lo habitual será que los plugins traigan frontends específicos; por ejemplo una vista de mapa para ver la topología de una red ofrecida por el backend correspondiente. A parte de los frontends que representan listas de elementos, también existen otros que representan preferencias y opciones de usuario, como por ejemplo los datos de conexión de un FTP.

Core (modelo). El core de la aplicación es el encargado de cargar frontends y backends y asegurar la consistencia. Por ejemplo puede cargar un frontend "lista" y otro "árbol" para renderizar el contenido de un mismo backend "ftp". El core también se encarga de realizar operaciones sobre los backends y entre ellos. Por ejemplo, copia de ficheros desde un backend "samba" a uno "ftp". También provee los mecanismos para determinar qué operaciones tienen sentido sobre cada backend.

Ámbito

O sea, ¿qué cosas se van a poder navegar con TP? En general cualquier cosa que esté estructurada como un árbol (un grafo es un árbol con "enlaces").

Siendo más específicos podemos distinguir dos tipos de elementos "listables":

Hojas: elementos terminales no manejables con TP a menos que exista un backend para ellos, por ejemplo un fichero .zip. Cuando un backend cargue un elemento "hoja" usando un backend ha de abrirse un nuevo panel. Es decir, no se pueden mezclar en el mismo panel elementos gestionados por diferentes backends.

Compuestos: son elementos que pueden contener elementos hoja y también elementos compuestos. El ejemplo evidente es un directorio.

Tanto las "hojas" como los "compuestos" pueden contener cualquier número de propiedades, pero, para un mismo backend, todos los elementos deben tener las mismas propiedades, aunque para algunos de ellos estén vacías (como una tabla en un base de datos). Cada propiedad tiene un nombre (de tipo cadena) y un valor que ha de ser un escalar (cadena, entero, flotante, fecha, permisos)

Y esto es todo por ahora. ¿comentarios?