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.
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.
- 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.
- 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.
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.
2 comments:
Hola!
Sólo un par de dudas/apuntes:
1.- ¿Al final existe distinción entre acciones comunes y propias del backend? ¿Un método para retornar ambas clases?
2.- Comentar que el backend, aunque directamente no sepa realizar una operación binaria por si mismo, quizá le sea posible crear un nuevo backend (o varios) para manipular esta operación. Aunque esto es interno al backend, creo que es importante tenerlo presente, sobre todo a la hora de escribir las API's.
Esto es todo amigos.
hola!!
1- Sí, ya que las operaciones comunes se proporcionarán mediante una hash mientras que las propias serán una lista.
Es lógico, ya que las comunes son las que ya tienen un sitio fijo en el popup, e iremos preguntando de la forma "dame el puntero para este valor", mientras que las propias no las conocemos y tendremos que iterarlas.
2- Hecho.
PD: He reeditado el documento para aclarar ambos puntos.
Post a Comment