Temas de investigación

Yo una vez me detecté éstos:

• cambiar vocales (esto en Dvorak, porque están juntas)
• acentuar varias letras seguidas (en mi teclado)
• poner letra con y sin acento: máas, etc. O eñne
• duplicar consonante equivocada (Bolle en vez de Boole, etc.)
• añadir más vocales de las necesariaas
• equivocarme con símbolos porque en cada modelo de teclado los tengo en un sitio
• ninguna de las anteriores :-)

Quizás iría bien saber cuáles son los errores de tecleo más comunes, para intentar evitarlos al crear una distribución de teclado.

Desde <21.m03.2010>

Hay muchas funcionalidades que se le piden a una distribución de teclado:

• diferentes alfabetos, conmutables: ahora escribo en ruso, ahora en español, ahora en griego
• teclas modificadoras crean varias combinaciones para cada tecla; además en cada plano (alfabeto) pueden ser otras
• hay diferentes métodos de entrada; ej. para chino; cada uno muy complejo y que necesita tecnologías aparte
• ha de funcionar en diferentes teclados, por eso hay que tener en cuenta:
  • los códigos de tecla cambian
  • hay combinaciones de 3 y 4 teclas que no son posibles en teclados baratos
  • no es lo mismo apretar A+B+C y soltarlas que B+A+C y soltarlas
• hay implicidas tecnologías muy complejas de configurar (XKB) que deberían ser más sencillas y mejor documentadas
• la creación de este mapa de teclado ha de ser sencilla

Se puede hacer un análisis muy extenso de todo esto, y mejorar muchas cosas. Un trabajo de investigación podría tener dos partes: preparación de la infraestructura para definición de teclado cómoda en GNU/Linux y luego Creación de una distribución de teclado cómoda, potente y razonada.

Yo llevo peleándome con esto desde hace años; avísame si te interesa.

Desde <21.m03.2010>.

Dar instrucciones para configurar un Linux completamente para que use Unicode, en cualquier escenario:

• en la terminal (Ctrl+Alt+F1, etc.)
• en xterm (explicar diferencia entre xterm y uxterm)
• en el sistema de ficheros
• al grabar un CD
• en el navegador web cuando abre páginas locales y remotas
• etc.

Y explicar cómo convivir con el resto de codificaciones una vez que usemos Unicode.

<21.m04.2006>

Buscar programas (ej. en el repositorio de Debian) que aún no funcionen bien con Unicode. Arreglarlos, y por el camino crear un documento explicando cómo se hace y qué problemas da la transición, para que sea más fácil arreglar el resto.

<25.m03.2006>

Hacer una guía que facilite la transición a Unicode, pero estudiando los problemas que da en Internet:

• codificaciones de caracteres (definidas en varios sitios),
• navegadores en los que va y en los que no,
• HTML o XHTML, diferencias en cuanto a codificaciones
• servidores web en los que se puede configurar Unicode
• etc.

También hay que hablar de los nuevos problemas que da Unicode, y cómo evitarlos (ej: letras parecidas, o tipos de letra no disponibles del todo).

Además irá bien pensar cómo se escribe en Unicode, qué editores web permiten incluir cualquier carácter, o dónde encontrar grandes tablas para copiar+pegar caracteres de forma fácil al hacer una web.

<25.m03.2006>

Hice un trabajo con LyX en el que quería escribir en varios idiomas con varias codificaciones (como árabe, griego, japonés y catalán), todo mezclado. Tuve que abandonar esa idea porque LyX no permite usar Unicode, y eso es debido a que LaTeX también tiene algún problema con codificaciones de más de 256 caracteres, creo.

Me gustaría que Unicode funcione en LaTeX, pero en un solo LaTeX; no entiendo por qué hay que hacer versión para CJK (chino/japonés/koreano) y otra para el resto. Después, que se pueda usar en LyX.

Por cierto, al final mezclé idiomas a base de chapuzas; el trabajo (y código) está en: Lógica y lenguajes.

<21.m04.2006>. <21.m03.2010>: toca revisar

Quiero un programa (que sea software libre) que permita extraer los ficheros de un archivo ZIP dañado (uno que no se abre con los programas normales).

Y lo mismo, para otros algoritmos de compresión: gzip, bunzip2, RAR, … Puede estar bien un solo programa que lo haga todo. Si no se puede por problemas de patentes, investigar y dejarlo explicado en algún lado.

<04.m04.2006>

Hay varias alternativas para extender: links2, conkeror, … y otros. Con conkeror las adaptaciones para hacerlo usable son pocas.

El editor GNU Emacs es un universo de funcionalidades y de código instructivo. Le he dedicado una página para las pequeñas tareas que voy encontrando: tareas para Emacs.

Pero lo listo aquí porque también hay varias utopías que merecen ser realizadas, ej: hacerlo rápido, multinúcleo (esp. Gnus), multiidioma, usable con Guile, capaz de incrustar GTK, capaz de tener interfaces complejas, … Además el proceso de desarrollo necesita cambios críticos: usar bazaar, una interfaz para comunicar fallos, un proceso de gestión de parches, pruebas unitarias, subcomunidades unidas, …

Es un programa que da para muchos proyectos de investigación, pues con todo lo que ofrece se hace muy entretenido.

<25.m08.2009>

El programa de control de versiones del proyecto Ubuntu y del proyecto GNU es Bazaar (bzr). Se caracteriza por ser fácil de usar (y hasta ahora, algo lento). Le he ido encontrando pequeños fallos; están en la página tareas para Bazaar.

Aunque el funcionamiento básico es sencillo de cara al usuario, hay muchos algoritmos, formatos y protocolos que aún hay que optimizar mucho para hacerlos lo más rápido posible; creo que hay mucho por descubrir y mejorar. Además las interfaces han de seguir siendo fáciles y rápidas.

Puedes aprender mucho de trabajo en comunidad con este proyecto, porque hay formas de trabajo bien definidas, gente dispuesta a ayudar a los principiantes, e infraestructura: juegos de prueba, gestión de parches, … y claro, control de versiones.

Esto es muy importante porque los proyectos de GNU van a usar el control de versiones de GNU, que es Bazaar, y necesitan que sea agradable.

<25.m08.2009>

Los paquetes en Debian pasan por las ramas unstable -> testing -> stable. Yo uso la testing, pero echo a faltar varios programas en el apt-get, que tengo que bajar e instalar a mano. Ejemplos:

• Nvu (página de Nvu en Debian), que está en unstable desde hace tiempo (escribo esto el 21-4-2006)
• MPlayer, que costó mucho de revisar por temas de patentes, pero que creo que entrará pronto (más información sobre MPlayer en Debian)
• LiVES, que al principio necesitaba MPlayer, pero que debería poder entrar ya (ver informe de LiVES en Debian)

Alguien debería ponerse con uno de estos programas y ayudar a los encargados hasta que entre finalmente en Debian. Mucha gente lo agradecerá.

<21.m04.2006>. En <21.m03.2010>: tocar actualizar

Hace falta alguna guía o programa que ayude a ver vídeos (en cualquier formato) en ordenadores no muy potentes. No hacen falta consejos como "yo uso esta opción y me va bien" o "compra un ordenador nuevo", sino un análisis completo y cierto sobre:

• qué parámetros influyen al ver un vídeo: cantidad de RAM, velocidad de la RAM, velocidad del disco duro, porcentaje de caché, opciones de compilación, etc.
• en qué medida influye cada parámetro; cómo se pueden medir en un ordenador (para esto se pueden hacer 'perfiles' con gprof para ver en qué se pierde más tiempo)
• estudiar un reproductor, como el mplayer, y medir distintas posibles formas de aumentar la velocidad. Ejemplos:
  • dejar de aplicar filtros y conversiones (que puede que ralenticen todo)
  • aplicar más filtros que, aunque requieren trabajo, evitan una cantidad mayor de trabajo durante la reproducción. Esto es muy difícil, porque hay muchos posibles filtros y parámetros
  • convertir el vídeo antes de verlo, a un formato que requiera poco trabajo. Esto también es muy difícil, porque hay muchísimos formatos y parámetros; antes hay que conocer el formato más apropiado )ver sección siguiente sobre formatos)
  • perder fotogramas de vídeo, o de audio
• etc.; hay mucho por hacer; el objetivo no es "que mi vídeo se vea bien", sino entender por qué se ve bien/mal/lento/fluido/…

<13.m02.2007>

Un fichero de vídeo está codificado según varios parámetros: contenedor, códec de vídeo, de audio, tasa de bits en vídeo, en audio, calidad, fps, … Hace falta una lista detallada y completa (que no se deje nada) diciendo en qué consiste exactamente un fichero de vídeo. Todas esas cosas influyen en la reproducción.

Entonces, para cada una de ellas, habría que comparar cómo se puede cambiar para conseguir el máximo rendimiento en la reproducción (o sea, que el vídeo se vea fluido). Ver sección anterior para más detalles. El objetivo es conseguir el parámetro óptimo en cada una de las opciones. Naturalmente, hay que definir qué significa "óptimo"; eso es subjetivo y habrá que hacer varios grupos (configuración para que se vea con la máxima nitidez, configuración para que se vea fluido, para que la sincronización sea lo prioritario, etc.).

<13.m02.2007>

Hay muchísimos; estudiar por qué. Buscar qué grupos de necesidades lingüísticas hay en el mundo, y razonar por qué no puede haber un solo "idioma perfecto". Estudiar cómo debería ser un buen idioma, y uno malo, para cada una de esas necesidades, sin dejarse influir por los idiomas ya existentes ni por la pertenencia a uno de esos grupos de necesidades.

Un fenómeno curioso es el de los idiomas medianamente buenos que se venden como la solución universal a todos los problemas (ejemplo: Fasile; ahora no va la web pero fue (ej.). Si tuviera tiempo, me gustaría dar una visión más razonada; por ejemplo, si alguien inventa un idioma, debería poder justificar que es el idea para la finalidad que ha sido diseñado.

También habría que estudiar la (¿típica?) pregunta de: ¿qué idioma artificial me recomiendas aprender? Para eso hace falta una visión muy general del tema.

<25.m03.2006>

• conseguir arreglar el Lojban for beginners; hay una lista de erratas en algún lado
• traducirlo al español. También había gente que lo empezó, y varias veces :-)

<17.m04.2006>