Barrapunto

Perdona pero la opinión de tu blog no me parece estar muy fundamentada ni acorde a lo que dice el documento. Hace unos días el documento también fue comentado el planet.gnome y según lo que recuerdo no dice que gtk2 este muerto, sino que se esta volviendo cada ves más difícil agregar nuevas funcionalidades y mejoras sin romper la compatibilidad. Lo que se propone es empezar a desarrollar gtk3 antes de que el desarrollo de gtk2 se vuelva insostenible. Las próximas versiones de gkt2 servirían de puente a la versión 3 en la cual se rompería la compatibilidad y se quitaría mucho código obsoleto.

En el "informe" (una presentación en realidad) no pone en ningún sitio que GTK esté obsoleto, ni mucho menos "muerto". La expresión usada, que aparece dos veces, es dead-end, que significa callejón sin salida, carretera cortada. Que no se puede avanzar más. Y explican que es así por decisión, para no romper compatibilidad, y que esta compatibilidad se tendrá que acabar en la versión 3.0, para la que hay que prepararse.

¿Está preparada la comunidad de GTK+ para soportar un cambio tan grande como el que ha soportado el reciente KDE4? El debate de fondo aquí es sobre "romper la compatibilidad", es decir, cambiar la forma en la que se accede a los recursos de la biblioteca de modo que haya que reprogramar los programas que la usan.

Esto es un tema muy delicado. Por ejemplo, cuando hablamos de un proyecto de software libre, en el que los desarrolladores de la biblioteca son sus mismos usuarios, que la utilizan en sus programas, ¿cómo convencer a los desarrolladores que cambien la biblioteca de forma que sus propios programas tengan que ser modificados también? De ahí se entiende que digan que están poniéndose serios, y difícilmente van a conseguir el consenso total sin mostrar ni una sola línea de código, pero realizar cambios drásticos en la biblioteca requerirá el apoyo de una gran cantidad de desarrolladores (un círculo vicioso bastante problemático).

Otra cuestión: No se puede hacer un cambio "general" en un proyecto de software grande, sino que este se compone de pequeños cambios concretos, tanto funcionales como estratégicos, y estos no siempre está muy claro si van a sustentar o no el propósito general. ¿Podrán aunar su visión de futuro definiendo algunos miles de cambios específicos que realmente les lleven a ese fin?

Están intentando modificar GTK+, pero realmente están repitiendo el eterno discurso sobre compatibilidad hacia atrás de las bibliotecas de software. Este es un debate que tiene que darse de todos modos, porque ningún software va a permanecer siempre igual, y cuando cambie deben haberse definido unas políticas muy claras sobre cómo va a ocurrir el cambio.

Su propuesta sobre modificar gradualmente las futuras versiones 2.x para obligar a los programas que usan la biblioteca a realizar un acceso más estricto y controlado es una solución sumamente interesante, pero necesitan mucho poder para llevarla a cabo, o muchas agallas, y mucha inteligencia también. Ojalá tengan suerte.

Una característica que sería muy interesante es una propuesta que leí en algún blog de compiz, hacer que el dibujado lo realizara OpenGL directamente. Con Cairo se puede realizar pero hasta la fecha tengo entendido que no se le ha dado toda la grasa posible, como contrapunto que para los que no tengan acel 3d sería peor. Aunque hoy día eso rara vez suele ser problema, hasta los dispositivos embebidos los nuevos suelen contar con OpenGL ES. Lástima de la gp2x.

Interesante, personalmente prefiero KDE a GNOME por varios motivos entre ellos que las aplicaciones de gnome aparentan ser mucho mas "arcaicas" que las de kde, es una buena noticia que alguien se pare a pensar que anda mal en GTK para que cada vez estas diferencias parezcan mas grandes, aunque creo que esto no debe salir de una sóla empresa que programe para gnome, deberían hacer muchas reuniones para ponerse de acuerdo y crear unas librerías que sean buenas de verdad, capaces de competir y superar a QT4 y a Avalon. Suerte con ello.

Propuesta número 1: Tener un poco de sentido común y usar un lenguaje orientado a objetos para implementar objetos (los widgets) en lugar de empeñarse en usar un lenguaje imperativo con la excusa de que es más rápido. Y parándose un momento a pensar que a lo mejor un lenguaje más rápido es equivalente a un procesador un poco más rápido pero que lo que importa es que los algoritmos sean más eficientes, por no mencionar que las ventajas de un diseño más elegante y más fácilmente mantenible son muy superiores a la ventaja que pueda haber por usar C en lugar de C++.

PD: Antes de que alguien mencione a GTKMM que se pare un momento a pensar que no es más que un wrapper, que eso no arregla el problema. Qt, por ejemplo, aunque no se pueda comparar porque es un framework completo mientras que GTK sólo es una librería gráfica, son objetos diseñados e implementados en un lenguaje orientado a objetos; no necesita ponerle un pegote para que quede bonito, ya es elegante de por sí.

Anda, alguien que lee mi firma. :-D

Ahora en serio: mi firma viene porque en ella, muchos aprovechamos para enlazar con las páginas de nuestros diarios, "pet projects" o similares, y cuando la escribí, pensé "¿Y a quién le van a interesar las chorradas que ahí pongo, si son sobretodo de uso personal?"

Pero sí estoy de acuerdo en que muchas de las personas que envían noticias a Barrapunto, lo hacen por puro ego o por promocionarse, y muchas veces con contenido bastante discreto. Los que lo hacen de forma puntual, como éste, pase, nada que objetar. Pero sí que me resultan cansinos los que sistemáticamente envían cosas de autopromoción, sin "involucrarse" ni que sea discretamente en el sitio en sí. Maikelnai por ejemplo, lo encuentro aceptable, porque si miras las entradas que salen en la portada de su bitácora de barrapunto, en todas hay un enlace a su página propia, pero al menos es un usuario activo, que una vez escribe algo, participa en los comentarios. Pero uno que últimamente envía mucho, el del queso, es que ni tiene usuario registrado...

Perdón por salirme tanto de tema. Ah, y yo en todas las historias que he enviado a barrapunto, no he puesto un solo enlace a mi página, que conste. ;-)

Por mucho que me guste Qt, lo que dices está fuera de lugar. Una cosa es permitir cambios en GTK+ que rompan la API y la ABI, y que fuercen a retocar código, o a actualizarlo a la nueva API. Pero pasar de GTK+ a Qt, es reescribirlo todo. Resultaría menos trabajo hacer un fork de KDE que se adaptara a las HIG de GNOME.

Y además está el cambio de C a C++, que también sería controvertido.

Esta bien. Que se demuestre la superioridad de la plataforma GNOME a la mierda de KDE

Si para demostrar que Gnome es mejor que KDE es necesario que hagan unas NUEVAS Gtk... significa que entonces de momento KDE es mejor que Gnome, ¿no? entonces la superioridad de la que hablas es falsa, ¿no?

Tío babas.

Comparto la opinión sobre qt4. Me parece mucho mejor diseñado desde hace tiempo. Sin embargo, es injusto comparar qt4 con gtk+, porque uno es en C++ y otro en C (diferente filosofía de desarrollo, utilidades, etc.)

Sin embargo, en Gnome tienes Gtk-- (http://www.gtkmm.org), que es una verdadera maravilla de ingeniería, y que convierte todo el arsenal Gtk+ a clases C++. Si yo tuviera que hacer una migración, empezaría por pasar todo a C++ usando Gtk-- y rediseñar desde ahí.

Por último, aunque QT4 está mejor diseñado, no por ello es perfecto. Por ejemplo, el uso del precompilador MOC es una auténtica pesadilla (incompatibilidades, generación de código, un modelo de desarrollo más complejo, etc.). En Gtk--, con la libsigc++, las señales se envían y reciben sin necesitar ningún preprocesador, de forma mucho más natural.

Y sí, C es muy bonito, es magnífico, pero usar C a estas alturas donde la diferencia de eficiencia entre C y C++ es inexistente, me parece un aferrarse al pasado (Un ejemplo es buscar el patrón RAII y ver cómo se aplica a C++ de forma automática, mientras que en C hay que liberar los recursos de forma explícita).

Un saludo,
diego.