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
3 comments:
Si nos ponemos a hacer algo grande, lo suyo es que el inspector pueda decidir lo que desea hacer (y el usuario podría configurar el inspector llegado el caso). Sin embargo, como bien dices en otro comentario, vamos a atacar el problema con prototipos desechables, así que decidámonos por uno y al abordaje.
Hablando de lo que más me gusta a mí, personalmente y sin pensar en nadie más, diré que me parece mucho más intuitivo que se abra en la ventana actual. No me gusta lo de "y que sustituya al inspector actual", porque no es del todo cierto.
Voy a poner un ejemplo: Estoy navegando por mi PC y abro un .ZIP. Espero que se abra como si fuera un container que, conceptualmente hablando, es un directorio. Por tanto, obtengo una vista de lo que contiene el Zip en primer nivel. Sin embargo, decido que ése no es el ZIP que quería abrir, y... Bueno, me gustaría encontrar un botón tipo "../" que me permita volver atrás, es decir: bajar un nivel. Eso implica destruir el inspector de zip y restaurar el inspector de SD (Sistema de Directorios) a la misma situación en la que estuviera.
Dicho de otro modo: debería haber una pila de inspectores por cada pestaña del notebook, de manera que uno de ellos (o varios) puedan quedarse en espera.
Otro ejemplo sería abrir un zip que contiene un zip (léase de forma recursiva).
Completamente de acuerdo con lo que expones. Yo me refería más bien a la organización visual del asunto.
Me parece muy adecuado el símil entre un directorio y un "archive", y además me parece bastante fácil de implementar.
Arrr, segunda vez que escribo este comentario...
No recuerdo muy bien que decía el primero, además era muy largo (maldito firefox...) así que resumo:
Me gusta la idea de: abrir "archives" en el mismo panel, abrir hojas en el panel destino (hojas como fotos, txt's, etc. nada que tenga estructura no lineal)
Pos eso, IMHO. :-d
Post a Comment