[eside-ghost] Flame KDE vs El resto del mundo. ERA: Visor de PDF

[Jon Ander Hernández]

Aupa Malkavian!!

> A mi me interesa mucho más la usabilidad y la integración que la belleza, 
> aunque tampoco lo desdeño. Y a mí, repito, a mí, gnome, enlightenment o 
> fluxbox me parecen tremendamente inusables.

Bajo mi punto de vista la palabra usabilidad no puede usarse como un
argumento a favor o en contra, porque no hay un consenso entre que es
usable y que no lo es. Existe el termino usabilidad... lo usamos para
reflexionar sobre la idoneidad de las interfaces de usuario, pero es un
campo donde incluso entre expertos se contradicen y cada cual saca su
estudio de la manga.
Y el tema de la belleza más de lo mismo, a mi personalmente me parece
que el tema gnome 2.12 es mucho más bonito y práctico que tu tema negro,
y el tema de gnome 2.14 traerá animaciones y demás gaitas. Aunque eso
si, aunque mejoren los temas de KDE y los de Gnome aún les queda
bastante para llegar a tener temas de la altura de estos :
http://interfacelift.com/themes-mac/index.php?sort=date y eso que el
sistema de temas de OSX es muy simplón comparado con los sofisticados
engines de KDE y Gnome.

Por otro lado si te refieres a usabilidad == features que tu necesitas
para que algo te parezca "'__usable__'", pues eso depende de muchas
cosas. Es cierto que Gnome ha ido simplificándose con el tiempo, tiene
muchas razones :

- La simplicidad es uno de los objetivos del proyecto, porque un exceso
de funcionalidad puede liar a los usuarios inexpertos, y también porque
es difícil de mantener con unos ciertos standard de calidad.

- Modularidad, si una app o un programa de gnome no te gusta normalmente
esta diseñado para reemplazarlo sin ningún problema. Por ejemplo ya hay
planes de sustituir los paneles y sus applets empotrables, lo que ocurre
es que como es mucho trabajo, quieren planificarlo bien porque no entra
dentro de un ciclo de desarrollo de 6 meses o incluso puede que en dos
ciclos, y además resultaría necesario en el Gnome 3.0 (vamos que lo de
plasma no es exclusivo de KDE, solo que los de Gnome no han ido soltando
el vaporware en cada entrevista).

- Independencia, aunque hoy día en la práctica los módulos no hayan
logrado ser muy independientes los unos de los otros, en gran parte por
culpa de bonobo (el sistema de componentes), en un principio si esta
pensado para que los programas tengan el mínimo de dependencias. Como
ejemplo podemos ver de la enorme cantidad de aplicaciones de Gnome (y no
de GTK+) que están a otras plataformas como evince, gnumeric, abiword,
etc... y por otro lado pensad en cuantas aplicaciones de KDE están
portadas a otras plataformas (jejeje ninguna porque no existe port de
KDE a nada que no sea Linux, salvo el abandonado proyecto de KDE sobre
cygwin que incluso dependía de las X, y si tu app depende de KDE
significa que TODO kdelibs tiene que estar portado).

Otras cosas que han perjudicado a Gnome han sido :

- Bonobo : Todo el mundo ha terminado aborreciendo bonobo, muy complejo
de usar, difícil de portar a otras plataformas, añade mucho peso a las
apps, hace muy difícil la optimización (ya que tienes que seguir la
pista a dos procesos diferentes)... etc. Y claro bonobo es el modelo de
componentes, es decir, lo que permitiría extender fácilmente Gnome para
que tenga nuevas funcionalidades, si quitas esto... pues significa que
donde antes podías poner un módulo, ahora tienes que diseñar un app que
admita módulos/plugins.

Pero los problemas de los componentes no es algo exclusivo de Gnome, en
Mozilla también tienen problemas similares, y OO.o más de lo mismo, e
incluso KDE.
Por ejemplo uno de los problemas que tiene (actualmente) KDE es que
tienen un problema con el futuro de KHTML. Todos hemos oído hablar de
que plasma se apoyará en KHTML para hacer todo su eyecandy, pero
jejejeje, el problema es que en la versión actual de khtml este esta
embebido en un kpart y para extender su funcionalidad admite empotrar
otros kparts, y cuando se ideó el soporte ksvg pues se dijo, vale pues
un kpart. El problema vino cuando se encontraron que con un kpart no
podían crear una implementación de SVG eficiente, porque ksvg no podía
acceder a las estructuras internas de khtml... conclusión, reescritura
de KSVG, reescritura de la implementación DOM de khtml, y ahora falta
portar el khtml a la nueva implementación de kdom. Vamos que los kparts
molan hasta que te encuentras que te limitan y tienes que reescribir
todo el diseño.

- La guerra de las runtimes : En KDE todo el mundo ama C++, en el mundo
Gnome hay gente que ama el C de toda la vida, otros que aman python
sobre todas las coas, otros que no cagan con java, otros piensan que
mono es el futuro... pero claro no se puede crear un Desktop oficial que
dependa de 3 runtimes, y claro eso limita el número de apps en la
versión oficial.

Un saludete!!

JonAn