Este post puede ser útil para los que utilicen el widget TreeView de Gtk+ (no importa el lenguaje mientras haya bindings), y necesiten activar por código celdas en modo edición. Hay algunas cuestiones a tener en cuenta.

Para el Proyecto Final de Carrera estamos desarrollando un sistema de nivel operativo, con funciones de facturación y demás. Necesitamos manejar un TreeView con campos editables, y al finalizar la edición de uno de ellos es necesario dar el foco a otro campo en modo edición, listo para que el usuario comience a cargar datos sin tocar el mouse.

Lo primero que hicimos fue conectar un método al evento Edited del CellRendererText de la columna correspondiente. De esta forma, cuando terminamos la edición en el primer campo, podemos colocar allí el código correspondiente para actualizar el modelo del TreeView y otras operaciones más, entre ellas (la que nos interesa) dar el foco al segundo campo en modo edición. La parte final de este método (el evento se activa al finalizar la edición) había quedado así:

/* ... */

this.tvItems.SetCursor(path,
					   this.tvcCodigoProducto,
					   true);

Hay que tener cuidado al utilizar la función SetCursor. En algunos casos, si no la usamos cuidadosamente, el TreeView no se comportará en forma correcta. Esos casos son por ejemplo cuando el usuario, al estar editando el campo, hace click en otra fila. Esto hace que se dispare el evento Edited, y por lo tanto se activa el modo edición en el segundo campo (SetCursor), pero el foco lo tiene otra fila, y esto hace que el funcionamiento sea incorrecto.

La solución es, antes de ejecutar SetCursor, verificar qué tipo de evento ha ocurrido. En nuestro caso, ejecutamos dicha función sólo si se ha oprimido la tecla Return. El código queda así:

/* Una vez editada la cantidad, automáticamente
 * pasamos el foco al campo de 'código' en modo
 * edición, pero en una nueva fila. A esto lo hacemos
 * únicamente si el usuario presionó la tecla Enter */

Gdk.Event ev = Gtk.Application.CurrentEvent;

if (ev.Type == Gdk.EventType.KeyPress) {
	Gdk.EventKey evKey = (Gdk.EventKey)ev;

	if (evKey.Key == Gdk.Key.Return)
		this.tvItems.SetCursor(path,
							   this.tvcCodigoProducto,
							   true);
}

Lo cual es más lógico también: si se hace click en otra fila, seguramente es porque se quiere editar otro ítem y por lo tanto no es correcto forzar el foco en otro lugar. Además, como se dijo, esto hacía que el TreeView quede en un estado inconsistente.

Está bueno el artículo. Hay razones que parecen estar muy justificadas para tener un flujo como el de Windows o KDE en los diálogos: realizar cambios, presionar “Aceptar” (se aplican los modificaciones y el diálogo se cierra), o “Aplicar” (se aplican las modificaciones pero el diálogo permanece), así como también otros tipos de botones como “Deshacer”.

Primero (entrando a analizar ya el artículo), me parece más correcto decir “instant apply” que “implicit save”, como alguien la corrige en los comentarios. Porque en GNOME, en uno de estos diálogos, los cambios tienen efecto instantáneamente. O sea, cuando clickeo en el checkbox los cambios ya se efectuaron. Cuando elijo una opción de un combobox, al terminar de hacer click en la opción, ya está aplicada. Los cambios no se aplican cuando hago click en “Ok” o “Aplicar”, sino cuando hago los cambios

Menciono esto porque en una de sus soluciones a este “problema”, recomienda que el botón “Close” sea “OK”, pero eso sería inconsistente con la manera de funcionar de GNOME según entiendo. No se trata de la cantidad de botones que hay en los diálogos, es toda una forma de funcionamiento.

Repito, después de la aclaración del “instant apply”, que está bueno el post, y que al terminar de leerlo parece que tiene razón. Es lo que me pasó a mí. Sin embargo después de pensarlo un poco, de los problemas o contras que menciona, yo nunca los he tenido. Por eso digo que parecen justificados, pero en la práctica (por lo menos a mí, que no soy un usuario básico) no parecen presentarse. Quizá para algún tipo de configuración muy avanzada sea correcto utilizar otro tipo de diálogos, y no este. Por ejemplo, si estoy configurando algo que reinicia el servidor X, o algún otro servicio, no sería bueno que se esté reiniciando cada vez que activo o desactivo un checkbox. Tampoco es la mejor solución para configurar la resolución de pantalla (imagínense):

Me siento muy identificado con lo que dice un tipo en este comentario. Si hago cambios y me doy cuenta de que me equivoqué, el estilo “explicit apply”, que utilizan KDE y Windows, no soluciona las cosas. Si aplico los cambios y cierro el diálogo (o sea, oprimo “Aceptar”), y luego me doy cuenta de que me equivoqué y abro el diálogo otra vez, ya no puedo revertir lo que hice (salvo que tenga algo así como un sistema de gestión de versiones para las preferencias de usuario, que me parece una locura). Entiendo que se podría oprimir “Aplicar” antes de cerrar el diálogo, y ver si todo funciona, pero ese flujo me parece extraño: no voy a estar con el diálogo abierto probando que todo esté bien y luego cerrarlo. Además, ¿qué pasa si me equivoqué en algo de lo que no me puedo dar cuenta rápido?

Yo creo que la autora del post no tiene en cuenta todos los aspectos de GNOME al evaluar esta cuestión en particular. Se olvida por ejemplo de la simpleza del escritorio. Vuelvan a ver el primer screenshot, el de las preferencias para el proxy. Es muy (muy) simple. Si lo cambio, y luego me arrepiento, no es difícil revertir lo que hice.

Otro punto a favor que le encuentro es, naturalmente, la simpleza. Un sólo botón (hasta diría que ninguno, porque se puede cerrar el diálogo con la crucecita de arriba). Éste post hace un análisis interesante de todo esto también.

Yo no estoy diciendo que no haya una mejor forma de hacer las cosas en vez de la que ofrece GNOME. Simplemente digo que yo no tengo esos problemas que menciona. Quizá sea porque no soy un usuario común, aunque no creo que sea por eso. Simplemente creo que es costumbre, y que no es algo malo como menciona la autora o como se dice en alguno de los comentarios.

Por cierto, estuve revisando las GNOME Human Interface Guidelines. La verdad que están muy buenas, y ahora entiendo el por qué de algunas opciones por defecto de Glade. Lo nombro simplemente para aclarar que esto de los diálogos, así como muchas otras cuestiones, fueron cuidadosamente pensadas. Esto no significa que no estén equivocados, por supuesto, pero no son decisiones que tomaron los desarrolladores así nomas (quizá ni siquiera sean desarrolladores los que decidieron esto). Hay (o hubo) empresas importantes atrás de estas guías, como Sun y Red Hat.

Yéndome un poco de tema, fíjense por ejemplo cómo está establecido el layout de las ventanas. Son buenas ideas, me parece, para adoptar en nuestro futuro trabajo profesional (me refiero a la idea de ser consistente y tener una forma unificada de hacer algunas cosas).

En fin, está bueno discutir estas cosas. Esto empezó como un hilo entre amigos, pero pensamos que era una buena idea extender un poco más la discusión para tener puntos de vista distintos. Creo que la vida profesional nos irá dando feedback sobre estas cuestiones.

Si hacen click derecho en algún directorio y dirigen su mouse hacia “Crear un documento” verán lo siguiente:

Siempre me pareció poco útil esa opción. Ahora me doy cuenta que nunca había leído el texto gris desactivado: “No hay ninguna plantilla instalada”

Ya habrán adivinado para qué sirve la carpeta. Si están cansados de repetir acciones al crear un documento de texto en Writer, una imágen en Inkscape, o algún texto con LaTeX, ya han encontrado la solución

Simplemente creen la plantilla y copien el archivo a ese, hasta ahora, extraño directorio “Plantillas”. Luego hagan click derecho nuevamente en alguna carpeta:

Algo que me gustaría que tenga, es la posibilidad no sólo de crear plantillas para documentos, sino también plantillas para carpetas. Algo que hacemos muy seguido con los chicos es TPs para la Facultad Los hacemos con LaTeX, y muchas veces vamos mejorando cosas, que luego hay que recordar de agregar en los nuevos documentos que se van haciendo, y como son tantos, a veces no es fácil recordar dónde habíamos hecho el cambio y qué trabajos son anteriores al mismo y que por lo tanto no lo tienen aplicado.

Una opción es crear un archivo comprimido. De esta forma sería cuestión de descomprimirlo y listo. El problema se presenta cuando tenemos que ir actualizando la plantilla con los cambios: resulta medio incómodo. Una opción que no tiene nada que ver con esto es crear un script para Nautilus, usando quizá Zenity, para copiar la “plantilla del trabajo práctico” al lugar que indiquemos. Pero no me gusta eso…