[haiku-es] Re: Repositorio de aplicaciones Qt para Haiku

  • From: "Jorge G. Mare" <koki@xxxxxxxxxxxxx>
  • To: haiku-es@xxxxxxxxxxxxx
  • Date: Tue, 24 Nov 2009 14:11:05 -0800

Hola Ivan,

Ivan Vodopiviz wrote:
Con todo respeto Jorge, si las cosas funcionaran de esa manera ni
Windows ni OSX tendrían aplicaciones nativas. Dar soporte a un toolkit
no es "linuxificación": se trata de bajar la barrera a los
desarrolladores. Como desarrollador de software, prefiero toda la vida
utilizar QT que "atarme" a la API específica de cada sistema
operativo. Desarrollar capas de compatibilidad para cada sistema
operativo (incluyendo bellezas como código de threading) no sólo es
difícil sino que es muy costoso en tiempo y dinero. Frameworks como QT
simplefican esta tarea, aunque el resultado no siempre sea tan óptimo
como programar nativamente.

Eso de bajar la barrera de los desarrolladores lamentablemente confirma mis sospechas de que, de proliferar esta tendencia, el API de Haiku se vería relegado a segundo plano, algo que a la larga puede llevar a su estancamiento lo cual, obviamente, no sería nada bueno para Haiku.

Yo comprendo que es más fácil para el desarrollador de software. Pero al mismo tiempo quiero recalcar que es justamente esa perspectiva centrada en la necesidad del desarrollador -- en vez de la del usuario -- la que ha convertido a Linux en el monstruo que es hoy, donde multiples toolkits, DEs, windows managers, etc. se pelean unos con los otros a costa de falta de consistencia, incompatibilidades y complejidad para el pobre usuario. Yo no quiero que Haiku siga el mismo camino que Linux, ya que en definitiva llevaría a un resultado equivalente (de allí la expresión "linuxificación de Haiku").

El tomar ese mismo camino iría en contra de la posición que Haiku ha tenido desde el primer día de poner énfasis en una visión uniforme que abarque a todo el sistema. Leélo, que está en el FAQ de Haiku, específicamente en este punto:

http://www.haiku-os.org/about/faq#3

Entonces, ¿por qué usar KOffice en Haiku si lo puedo hacer en Linux?
Simplemente porque Haiku no es Linux. La experiencia de usuario va
mucho más allá que los programas que uno esté utilizando en un momento
dado. Aunque más no sea porque quiero utilizar KOffice sin tener que
pegarme patadas con X.org, porque quiero escuchar música en Amarok sin
tener que luchar contra ALSA, PulseAudio, alsa-oss y demás bicharracos
de la vapuleada capa de sonido de los sistemas GNU. De la misma manera
podría citar montones de ejemplos, pero creo que la idea se entiende.

Yo creo que la experiencia de usuario se manifiesta en gran medida a través de las aplicaciones. En la medida que uno use solamente aplicaciones que no son nativas, la experiencia de usuario de Haiku pierde toda su relevancia, ya que no llega a materializarse en todo su potencial.

Las aplicaciones que tu mencionas podrán llegar a correr en Haiku, pero no te darán nada que no puedas ya tener con Linux, ni tampoco sacaría provecho de lo que da valor a Haiku (queries, data translators, pervaisve DnD, etc. etc.). Ni que hablar de la falta de consistencia que introducirían en la GUI, no solamente visualmente, sino también a nivel de interacción de usuario (diálogos con botones en diferentes posiciones, shortcuts inconsistentes, etc. etc.). Para mí, esa es la mejor definición de una experiencia de usuario linuxificada.

Mi punto es: Con tu mismo criterio, ni Java, ni Mono tienen razón de
ser en Haiku y, sin frameworks como QT, bueno, simplemente no veo qué
programas vamos a utilizar (Firefox descontado porque es cualquier
cosa menos nativo).

El problema es que ahora la gente se ha vuelto un poco impaciente. No porque haya salido alfa 1 de repente Haiku tiene que tener de la noche a la mañana la misma cantidad de programas que otras plataformas más maduras que han existido por mucho más tiempo; esa es una expectativa irrealista. Estas cosas llevan tiempo y el camino más fácil no es necesariamente el mejor.

Los programas nativos vendrán poco a poco, pero que hay que darle tiempo a Haiku para que madure. También hay que fomentar al ecosistema de aplicaciones nativas para que se vaya formando y creciendo gradualmente, y para eso tiene que haber un enfoque en el API nativo.

Un abrazo,

Jorge/aka Koki


Other related posts: