La manera de averiguar la disposición óptima de las teclas es hacer un estudio de la geometría del teclado y de la mano del usuario que lo va a utilizar, así como de la dificultad que entrañan ciertas combinaciones de movimientos para éste. Existe un software en estado beta dedicado especialmente a la construcción de teclados teniendo en cuenta esos parámetros. Una vez definida la dificultad de acceso a las teclas y el resto de parámetros del modelo de escritura del usuario, se le alimenta uno o más textos, un corpus, para los que ese teclado se tendrá que optimizar. En mi caso, para definir un teclado castellano, había pensado en usar obras selectas de Cervantes como corpus y así obtener el “mapa de teclado de cuyo nombre no quiero acordarme”, apropiado para que un manco de Lepanto redactara a su aire la obra cumbre de la literatura española. Lo único que no encaja es que la mano impedida de Cervantes era justamente la izquierda.
Tras un rato de empaparme de la teoría de construcción de teclados con CarpalX, decidí ponerme manos a la obra y comprobé con desánimo que el autor del software todavía no había publicado el código o facilitado un binario (también llamado ejecutable, para los ajenos a la terminología de la comunidad GNU/Linux). Mi gozo en un pozo.
Visto lo visto, y sin ganas de programar mi propio creador de teclados, me dispuse a diseñar a mano alzada “la mano izquierda de la oscuridad”, mi versión personal del teclado de acordes. Las pocas decisiones de diseño que he tomado son éstas:
El teclado debe contener todas las teclas necesarias para escribir en castellano y catalán, programar en C y manejar en mi entorno de trabajo.
Es prioritario que las teclas que cuenten con mayor facilidad de acceso generen los 14 caracteres del Toki Pona (esto me facilitará los artículos que pronto poblarán esa categoría).
El resto de teclas se distribuye por presencia estadística en el castellano hasta los rincones de peor acceso de la matriz del mapa de teclado.
Para restarle dificultad a la confección del teclado, he tenido en cuenta sólo de forma difusa criterios como la alternancia de dedos o permanencia en una fila, dejándome llevar por la intuición de qué me parecería más fácil de teclear. Como preveo que el teclado sufrirá modificaciones en un futuro cercano, le he asignado la versión 0.1. Según me vaya sintiendo más a gusto con este teclado o con una futura revisión del mismo, colgaré las actualizaciones o incrementaré el número de revisión para reflejar su estabilidad.
El teclado que he escogido para llevar a cabo el experimento es un MiniBuddy KeyBoard de la casa BenQ. El teclado es sencillo y de letras muy pequeñas con tacto de portatil. Con una mano se puede abarcar la práctica totalidad del espacio de teclas. Espero que eso facilite mi adaptación al nuevo mapa de teclado.
Y ya que la mano izquierda se libera del yugo calórico de la superficie del reposamanos de mi portátil, me parece apropiado abandonar el touchpad en favor del pequeño ratón que se vende conjuntamente con el teclado mencionado.
Antes de describir el mapa que emplearé inicialmente, querría hacer un par de comentarios acerca de la utitilidad que puede tener. Como se puede entrever de mi apuntes iniciales del experimento, yo no tenía demasiado claro el uso que se le podía dar a un teclado zurdo (más allá de aguantar la cabeza con la mano derecha mientras se teclea). Además de la utilidad que puede tener un teclado zurdo para una persona impedida del uso de la mano derecha, una lectora del weblog me ha hecho notar que las actividades en las que el uso del ratón predomina sobre el uso del teclado (diseño con AutoCad, retoque fotográfico, …) seguramente se desarrollen de forma más cómoda si no es necesario abandonar el ratón para pulsar unas pocas teclas (o hacer estiramientos manuales propios de un virtuoso del piano para alcanzar lo humanamente inalcanzable).
Bueno, y ahora sí, con ilustraciones a todo color, paso a describiros el teclado con el que pronto voy a escribir mis textos y código (cosa que espero que no afecte al ritmo de la actualización de esta página).
Éste es el aspecto inicial que presenta el mapa de teclado. La mano izquierda se debe situar originalmente con el meñique sobre el cuadrado rojo, el anular sobre la ’s’, el medio sobre la ‘n’, el índice sobre la ‘e’ y el pulgar sobre la tecla de espacio.
Los carácteres dibujados son accesibles mediante pulsación simple. La tecla de tabulador y la de borrar tienen un sitio especial en la fila de partida, a tiro del meñique. En ningún momento se le pide al usuario que estire su mano por encima de más de dos teclas para llegar a pulsar otra. Las teclas coloreadas son teclas de función, que permiten redefinir el comportamiento de las teclas ocupadas por letras en la imagen.
Al pulsar el modificador de la fila de partida, las teclas marcadas en la imagen adquieren la capacidad de generar los símbolos de puntuación habituales en nuestra escritura.
El conmutador verde da acceso cómodo a los símbolos empleados en la programación.
La tecla amarilla, a su vez, pone a disposición del usuario un teclado numérico.
El modificador azul permite llevar a cabo algunas de las funciones que habitualmente utilizo más en mi entorno. Los números del uno al seis indican el salto a la consola de trabajo numerada de esa manera. El siete sirve para entrar en el modo gráfico.
La ‘C’, la ‘D’, la ‘L’, la ‘U’ y la ‘Y’ indican la pulsación de esas mismas teclas acompañadas del modificador de Control. Sus funciones bajo un sistema GNU/Linux son las de “interrupción”, “fin de entrada”, “limpiar pantalla”, y “cortar” y “pegar” una línea de comandos entera, respectivamente.
De momento he terminado la construcción del fichero que describe este mapa de teclado para su uso en la consola de Linux.
Si estáis familiarizados con Linux, tan sólo tenéis que descargar ese fichero, ingresar en una línea de comandos fuera del modo gráfico y cargar el nuevo mapa de teclado con el comando “loadkeys toki.kmap”. Espero que os sepáis defender bien con él. Podéis regresar al modo gráfico para anular el uso de ese mapa de teclado mediante otra llamada de “loadkeys”, si resulta que no os aclarais demasiado de buen principio.
Uso del mapa de teclado en modo gráfico
Teóricamente, X11, el sistema gráfico estándar en distribuciones GNU/Linux, es capaz de manejar hasta ocho modificadores simultáneos, así que debería ser capaz de gestionar las teclas de Control, Alt y Shift, además de los cuatro modificadores propios del mapa de teclado.
Unas cuantas pruebas frustradas que he llevado a cabo esta noche y un mucho de navegar esta mañana me han convencido de que la integración directa de este mapa de teclado en el entorno gráfico de Linux no es posible.
Por suerte, hace dos días se liberó la versión 0.2 de un software llamado usbhotkey que puede tomar eventos de un dispositivo USB (en este caso mi teclado) y transformarlos de una forma muy flexible en eventos del entorno gráfico X11. De momento todavía no he podido probar ese maravilloso trocito oportuno de código, pero tiene muy buena pinta y promete estar disponible en un futuro próximo para FreeBSD, MacOS y Windows, además de para Linux. En una de las próximas entradas ya os hablaré de él y de cómo configurarlo y usarlo para la integración total del mapa siniestro de teclado en nuestras vidas.
Tras un rato de empaparme de la teoría de construcción de teclados con CarpalX, decidí ponerme manos a la obra y comprobé con desánimo que el autor del software todavía no había publicado el código o facilitado un binario (también llamado ejecutable, para los ajenos a la terminología de la comunidad GNU/Linux). Mi gozo en un pozo.
Visto lo visto, y sin ganas de programar mi propio creador de teclados, me dispuse a diseñar a mano alzada “la mano izquierda de la oscuridad”, mi versión personal del teclado de acordes. Las pocas decisiones de diseño que he tomado son éstas:
El teclado debe contener todas las teclas necesarias para escribir en castellano y catalán, programar en C y manejar en mi entorno de trabajo.
Es prioritario que las teclas que cuenten con mayor facilidad de acceso generen los 14 caracteres del Toki Pona (esto me facilitará los artículos que pronto poblarán esa categoría).
El resto de teclas se distribuye por presencia estadística en el castellano hasta los rincones de peor acceso de la matriz del mapa de teclado.
Para restarle dificultad a la confección del teclado, he tenido en cuenta sólo de forma difusa criterios como la alternancia de dedos o permanencia en una fila, dejándome llevar por la intuición de qué me parecería más fácil de teclear. Como preveo que el teclado sufrirá modificaciones en un futuro cercano, le he asignado la versión 0.1. Según me vaya sintiendo más a gusto con este teclado o con una futura revisión del mismo, colgaré las actualizaciones o incrementaré el número de revisión para reflejar su estabilidad.
El teclado que he escogido para llevar a cabo el experimento es un MiniBuddy KeyBoard de la casa BenQ. El teclado es sencillo y de letras muy pequeñas con tacto de portatil. Con una mano se puede abarcar la práctica totalidad del espacio de teclas. Espero que eso facilite mi adaptación al nuevo mapa de teclado.
Y ya que la mano izquierda se libera del yugo calórico de la superficie del reposamanos de mi portátil, me parece apropiado abandonar el touchpad en favor del pequeño ratón que se vende conjuntamente con el teclado mencionado.
Antes de describir el mapa que emplearé inicialmente, querría hacer un par de comentarios acerca de la utitilidad que puede tener. Como se puede entrever de mi apuntes iniciales del experimento, yo no tenía demasiado claro el uso que se le podía dar a un teclado zurdo (más allá de aguantar la cabeza con la mano derecha mientras se teclea). Además de la utilidad que puede tener un teclado zurdo para una persona impedida del uso de la mano derecha, una lectora del weblog me ha hecho notar que las actividades en las que el uso del ratón predomina sobre el uso del teclado (diseño con AutoCad, retoque fotográfico, …) seguramente se desarrollen de forma más cómoda si no es necesario abandonar el ratón para pulsar unas pocas teclas (o hacer estiramientos manuales propios de un virtuoso del piano para alcanzar lo humanamente inalcanzable).
Bueno, y ahora sí, con ilustraciones a todo color, paso a describiros el teclado con el que pronto voy a escribir mis textos y código (cosa que espero que no afecte al ritmo de la actualización de esta página).
Éste es el aspecto inicial que presenta el mapa de teclado. La mano izquierda se debe situar originalmente con el meñique sobre el cuadrado rojo, el anular sobre la ’s’, el medio sobre la ‘n’, el índice sobre la ‘e’ y el pulgar sobre la tecla de espacio.
Los carácteres dibujados son accesibles mediante pulsación simple. La tecla de tabulador y la de borrar tienen un sitio especial en la fila de partida, a tiro del meñique. En ningún momento se le pide al usuario que estire su mano por encima de más de dos teclas para llegar a pulsar otra. Las teclas coloreadas son teclas de función, que permiten redefinir el comportamiento de las teclas ocupadas por letras en la imagen.
Al pulsar el modificador de la fila de partida, las teclas marcadas en la imagen adquieren la capacidad de generar los símbolos de puntuación habituales en nuestra escritura.
El conmutador verde da acceso cómodo a los símbolos empleados en la programación.
La tecla amarilla, a su vez, pone a disposición del usuario un teclado numérico.
El modificador azul permite llevar a cabo algunas de las funciones que habitualmente utilizo más en mi entorno. Los números del uno al seis indican el salto a la consola de trabajo numerada de esa manera. El siete sirve para entrar en el modo gráfico.
La ‘C’, la ‘D’, la ‘L’, la ‘U’ y la ‘Y’ indican la pulsación de esas mismas teclas acompañadas del modificador de Control. Sus funciones bajo un sistema GNU/Linux son las de “interrupción”, “fin de entrada”, “limpiar pantalla”, y “cortar” y “pegar” una línea de comandos entera, respectivamente.
De momento he terminado la construcción del fichero que describe este mapa de teclado para su uso en la consola de Linux.
Si estáis familiarizados con Linux, tan sólo tenéis que descargar ese fichero, ingresar en una línea de comandos fuera del modo gráfico y cargar el nuevo mapa de teclado con el comando “loadkeys toki.kmap”. Espero que os sepáis defender bien con él. Podéis regresar al modo gráfico para anular el uso de ese mapa de teclado mediante otra llamada de “loadkeys”, si resulta que no os aclarais demasiado de buen principio.
Uso del mapa de teclado en modo gráfico
Teóricamente, X11, el sistema gráfico estándar en distribuciones GNU/Linux, es capaz de manejar hasta ocho modificadores simultáneos, así que debería ser capaz de gestionar las teclas de Control, Alt y Shift, además de los cuatro modificadores propios del mapa de teclado.
Unas cuantas pruebas frustradas que he llevado a cabo esta noche y un mucho de navegar esta mañana me han convencido de que la integración directa de este mapa de teclado en el entorno gráfico de Linux no es posible.
Por suerte, hace dos días se liberó la versión 0.2 de un software llamado usbhotkey que puede tomar eventos de un dispositivo USB (en este caso mi teclado) y transformarlos de una forma muy flexible en eventos del entorno gráfico X11. De momento todavía no he podido probar ese maravilloso trocito oportuno de código, pero tiene muy buena pinta y promete estar disponible en un futuro próximo para FreeBSD, MacOS y Windows, además de para Linux. En una de las próximas entradas ya os hablaré de él y de cómo configurarlo y usarlo para la integración total del mapa siniestro de teclado en nuestras vidas.
