Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
De GNOME a KDE | 57 comentarios (57 temáticos, editoriales, 0 ocultos)
La accesibilidad SUN y el soporte multilenguaje (5.00 / 3) (#3)
por jorginius ("jorginius" en Google Mail) a las Sun May 30th, 2004 at 09:41:52 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

En mi opinión, la introspección de los widgets que provee ATK y tener los métodos de entrada como módulos intercambiables en tiempo de ejecución es lo único que podemos echar de menos en KDE viniendo de Gnome.

El Gnome Accesibility Project usa ATK, que es prácticamente un calco para sistemas Unix de la MSAA (que lleva ahí desde Windows 95): los clientes (como lectores de pantalla) hacen sus peticiones únicamente a la capa proveedora de servicios y les es indiferente lo que haya detrás. Siempre que el toolkit disponga de una conexión con la esa capa (un bridge) y los widgets implementen los interfaces adecuados, a un lector de pantallas le dará igual si la ventana que lee es una ventana Swig de Java, o Gtk... O Qt, porque también hay en desarrollo un bridge ATK para Qt que espero se añada oficialmente detro de poco, con lo que se aprovecha todo el esfuerzo de SUN en KDE. Por ejemplo, podremos usar las herramientas de Gnopernicus para leer las ventanas de Konqueror.

De acuerdo que, en teoría, la accesibilidad en Gnome no es sólo ATK, pero la contribución de otros aspectos como la organización de los widgets, de las opciones, de los atajos de teclado, etc. Es más subjetivo: quiero decir que habrá gente a la que todo eso le parezca una traba a la accesibilidad, más que una ventaja... Yo mismo, por no ir más lejos, me siento totalmente desorientado cada vez que uso una aplicación Gnome. No encuentro las opciones "donde deben estar" (es decir, donde están en Windows y en KDE) y algunos widgets son bastante anti intuitivos por el mismo motivo.

Se podrá discutir si es más accesible "a lo Gnome" o no, qué hay que ser bruto para poner los atajos de "cerrar pestaña" y de "cerrar aplicación" tan cerca en Konqueror o que las barras de herramientas de KDE sean monstruosas... Ahora, lo que puedo constatar es que yo soy más productivo "a lo KDE", con ese interfaz "tan malo", quizás a causa de mi formación anterior pero.. De eso se trata, de ser productivo, ¿no?.

La segunda ventaja de Gnome, la entrada modular, sí que es apabullante y no hay nada planeado a corto plazo que se le asemeje en KDE. Por desgracia, KDE no tiene un soporte real para lenguas no europeas: existen las traducciones pero no hay un soporte bueno para escritura.

El caso que conozco es el del japonés. KDE está traducido a ese idioma, internamente todo es Unicode, el motor de fuentes de Qt permite representar los caracteres japoneses sin problemas... Pero al final resulta bastante frustrante usarlo en ese idioma, a veces por limitaciones de XIM, a veces por fallos de Qt. Qt se empeña en crear conexiones XIM por cada widget sea o no sea apropiado, tanto para un cuadro de texto (bien) como para una barra de menús (mal) lo que no les sienta nada bien a la mayoría de los clientes XIM (los que no incluyen hacks específicos para tratar con Qt), tampoco notifica la destrucción de los widgets a los clientes XIM y hay estilos de entrada que no funcionan como deberían.

En Gtk, por contra, la entrada japonesa funciona de maravilla. Aparte de que las aplicaciones Gtk (tanto 1.2.x como 2.x) son respetuosas con XIM, el soporte modular de métodos de entrada de 2.x permite cambios en caliente del lenguaje por aplicación y en cualquier momento, lo que es infinitamente mejor que la alternativa de KDE (XIM) y bastante mejor que el MS Global IME de Windows. También permite añadir soporte para nuevas arquitecturas de entrada de texto como IIIMF (también de SUN, que por cierto sustituye ya a XIM en Fedora Core 2), de forma limpia y sencilla.

La buena noticia es que el grupo de usuarios de KDE de Japón ha publicado parches para dotar a Qt de entrada modular semejante a la de Gtk (enlace en inglés). También han desarrollado un módulo para Uim. El problema está en que esos parches rompen la compatiblidad del ABI de Qt, con lo que no basta con aplicar el parche y recompilar Qt, sino que además habría que recompilar todas las aplicaciones que dependen de ella (como KDE). Estaría bien que para Qt 4.0, la proxima revisión de la ABI, se incluyesen esos parches de serie. No obstante, el principal autor, Daisuke Kameda, mantiene paquetes Debian de KDE enlazados con qt-immodules.

[ Padre ]


Others have rated this comment as follows:
Faro 5
melenas 5
rrey 5

De GNOME a KDE | 57 comentarios (57 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda