Thursday, September 18, 2008

Chrome tabs?

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

Monday, September 1, 2008

ModelCol

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 ;-)