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

  • From: Skar Cat <skarmiglione.sk4r@xxxxxxxxx>
  • To: haiku-es@xxxxxxxxxxxxx
  • Date: Wed, 25 Nov 2009 04:47:51 -0500

Yo pienso que lo que mas puede parar el proyecto haiku es la falta de
software util
si no tenemos lo basico sea nativo port no tenemos nada.
Ademas mucho software puede ser venetualmente portado al api nativo de
haiku, eso lo he visto en Mac osX donde algun software GNU fue primero
portado con X y gtk y luego portado a AQUA por ejemplo Open office.
sinceramente haiku necesita mucho soft para hacerse visible y yo creo que
con estas iniciativas lo lograra. por otra parte a mi no me parece que el
proyecto penda de un hilo pues ultimamente he visto mucho movimiento y
maduracion en cosas ....claro eso si, yo no soy desarrollador, pero
haikuware casi todos los dias tiene soft nuevo para ofrecernos, wifi va para
arriba, gnash....ya en el sistema en si, si he visto que hay devs que son
los main de verdad...
de todos modos si hacen falta mas desarrolladores, y visibilidad, pero yo
creo que ya estan madurando muchas cosas y son visibles.

El 24 de noviembre de 2009 17:51, Enrique Medina Gremaldos <
quiqueiii@xxxxxxxxx> escribió:

> El futuro de Haiku pende de un hilo. Hacen falta mas desarrolladores, de lo
> contrario no sera un problema de paciencia, sera un problema de proyecto
> abandonado. Gente como Axel, llevan 3 o 4 cosas críticas a la vez. Yo mismo
> soy programador, pero me es imposible aportar nada porque no consigo montar
> una máquina donde poder trabajar, voy a intentarlo con vmware que ya coge
> los usb muy bien.
>
> Qt tampoco es plato de mi gusto, pero es necesario para darle vidilla al
> proyecto. Porque crees que publicaron una Alpha 1 ?
>
> El 24 de noviembre de 2009 23:11, Jorge G. Mare <koki@xxxxxxxxxxxxx>escribió:
>
> 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: