Libertonia || Comments || De GNOME a KDE


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

De GNOME a KDE | 57 comentarios (57 temáticos, editoriales, 0 ocultos)

La plataforma de desarrollo Gnome (5.00 / 1) (#49)
por jorginius ("jorginius" en Google Mail) a las Fri Jun 4th, 2004 at 05:00:21 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

GNOME no es sólo un escritorio, sino que lo que se intenta es que también sea una plataforma de desarrollo. Y, en cierto modo, le llevan la delantera a la gente de KDE en este aspecto.

Es cierto en que tiene vocación de plataforma de desarrollo, pero no creo que lleve la delantera en ese sentido a KDE ni por asomo.

Fijémonos en algunas herramientas de desarrollo:

La gente lo suele comparar Glade con qtdesginer, aunque qtdesigner es mucho más: es todo un IDE que permite, aparte de hacer el diseño de la interfaz, manejar proyectos, subclasificar clases Qt/KDE, editar el código de los slots, integrar tus propias clases o diseñar aplicaciones contra sencillas bases de datos de forma visual. La parte del editor de código puede que no sea brillante (no obstante tiene realzado de sintaxis, ir de la declaración a la definición de un método en cualquier momento y autocompletado "a lo IntelliSense") pero como IDE es de lo mejor que tenemos en Linux (navegador de clases, asistentes de proyectos, inspector de atributos, excelente ayuda en línea... La lista es interminable)... Y es GPL y además es gratis.

Glade, por otro lado, realmente no es comparable porque es una herramienta mucho más especializada. No hay problema, se complementa con un editor externo y en paz ¿no?, pues no, porque Glade tiene un fallo y es que habitualmente no está síncronizada con los widgets de las últimas versiones de Gnome y/o Gtk (en mi Fedora Core 2 es de risa). Faltan unos, otros que están ya no existen (están obsoletos) y, si optamos por generar código, a veces accede a partes privadas de widgets que ya no son como Glade espera. El qtdesgigner siempre está sincronizado con la última versión de KDE.

Por otra parte, Kdevelop es una herramienta bastante buena también, con asistentes para varios tipos de aplicaciones KDE (KParts, contenedores, etc) pero no hay diferencias muy grandes respecto a Anjuta, así que ahí sí que va por gustos.

La documentación de Qt es excelente, cubriendo con explicaciones y ejemplos todo los aspectos de ese framework (red, multihilo, XML...) y, aunque la de KDE está en la línea de la de Gnome (quizás sea algo mejor), en el cómputo global KDE termina por tener una documentación de desarrollo superior. Más aún si programas en Gnome en algo distinto de C, que es un lenguaje para escribir interfaces tan malo como pegarle a un padre, porque la única documentación realmente actualizada y más o menos completa es para ese lenguaje.

Sobre lo que son las interfaces de programación en si: en Gnome hay muchas que, versión tras versión, siguen en beta y que parece que nadie se interesa por completar/arreglar, o al menos de darles un poco de continuidad al api. Usar GnomeVFS o GStreamer o Bonobo (en honor a la verdad, diré que este último parece que ya es estable, aunque yo no me fiaría) es una aventura para el desarrollador, que no sabe si no acabará depurando él mismo las bibliotecas o si tendrá que volver a reescribir todo el código dentro de un par de meses cuando se cambie todo de arriba a bajo. De éstas ha habido varias en Gnome y no es muy agradable de cara al desarrollador.

En fin, que KDE a lo mejor no da esa impresión de estar en la vanguardia tecnológica que da Gnome (sea ésta una impresión real o no, que también podría discutirse) pero al menos funciona, tienes buena documentación, buenas herramientas y hay la certeza de que, uses el api que uses, lo que programes hoy va a seguir funcionando mañana... O al menos va a seguir funcionando entre versiones menores. En Gnome eso es mucho decir.

Disclaimer: es muy posible que todo esto suene a flame. Empecé programando con Gnome, al final acabé quemado de tanto "movimiento bajo mis pies" y emigré a wxWidgets y a Qt, así que mi visión puede ser "un poco" partidista, pero todo lo que se ha contado es cierto, o se ha intentado que lo fuera :-).

[ Padre ]

Posición de cara al futuro (none / 0) (#50)
por osoh (imobachgs at softhome dot net) a las Sun Jun 6th, 2004 at 02:14:27 AM CET
(Información Usuario) http://www.banot.net/~imo/

Es que yo no me refería a eso exactamente. Es cierto, tengo la misma impresión que tú en cuanto a las herramientas de uno y otro.

Hay que tener en cuenta que GNOME es un proyecto que ha sufrido más de una reestructuración (como tú bien dices, una tortura para los programadores), pero parece que por fin han encontrado un camino algo más estable.

Pero yo voy más allá: con el tema de Mono (nos guste o no), GTK# y su condición de multiplataforma GPL (recordemos que KDE tiene ciertas trabas a la hora de migrar a otras plataformas con el controvertido tema de las Qt), creo que el futuro de GNOME en ese campo es muy prometedor. De acuerdo, hoy por hoy, no está por delante de KDE, pero creo que se encuentra mejor posicionado.

Igual después las cosas le salen mal a la gente de GNOME (esperemos que no, que también estan currando mucho), pero esa es la impresión que tengo ahora mismo (seguramente equívoca) ;)

PD: estoy programando en Qt (con Ruby, por supuesto ;-) y, además de que es una maravilla, la documentación está muy completa. Además, las Qt 4 prometen... y mucho.
--
Que no haya pasión que no valga el mal que cien años dura (Enrique Bunbury)
[ Padre ]

KDE no se estará quieto (5.00 / 1) (#52)
por jorginius ("jorginius" en Google Mail) a las Sun Jun 6th, 2004 at 02:14:18 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Habrá que ver si se mantienen las distancias o no. Hasta ahora pienso que no lo han hecho demasiado bien en Gnome de cara al desarrollador.

Programar en Gnome, según las empresas, es como dar un salto de veinte años al pasado. Nadie programa aplicaciones para el escritorio en C hoy en día: eso es de la época del Amiga, de Motif y del primigenio desarrollo en Windows. Así que es normal que se esté metiendo dinero (principalmente dinero estadounidense) para hacer de Gnome una plataforma de desarrollo más atractiva. Mono es una buena idea en esa línea.

Pero el caso es que KDE ahora lleva la delantera y como tarde demasiado Gnome en ponerse a su nivel también se llevará a todos los desarrolladores al huerto, a pesar del marketing y demás.

Pero yo voy más allá: con el tema de Mono (nos guste o no), GTK# y su condición de multiplataforma GPL

Gtk es multiplataforma pero Gnome no: hay una diferencia substancial entre poder desarrollar interfaces gráficas con Gtk# y poder desarrollar algún día aplicaciones para Windows con las api de Gnome o de "Gnome#" :-).

Además, la multiplataforma de Gtk (y por ende de Gtk#) es hoy por hoy bastante precaria. Los dos casos más comunes: MacOS y Windows.

En Windows, versiones de Gtk anteriores a la 2.2 no funcionan (a pesar de que la publicidad diga lo contrario... Y estaría por ver si versiones posteriores no están rotas también). La biblioteca está plagada de bugs y cualquier código medianamente complicado fallará en su ejecución por mucho que en Linux ese mismo código con esa misma versión de biblioteca funcione correctamente. También se ignoran sistemáticamente los informes de bugs de la versión para Windows, así que el soporte es el que tú mismo te puedas dar.

En MacOS no tengo referencias de primera mano, pero uno ve los screenshots de OpenOffice.org en MacOS X y se le cae el alma a los pies: las aplicaciones Gtk son un pegote que ni siquiera siguen el convenio en ese sistema de situar la barra de menús fuera de la ventana de la aplicación.

(recordemos que KDE tiene ciertas trabas a la hora de migrar a otras plataformas con el controvertido tema de las Qt)

Es Qt la que tiene "ciertas trabas" (la única traba es que tienes que pagar una licencia) y por "otras plataformas" te refieres a teléfonos móviles y a Windows, donde no está licenciada como GPL.

Aunque no tiene mucho que ver, pienso que Gtk tiene "muchas trabas" (legales) también, sobre todo si quieres hacer una aplicación cerrada enlazada con ella. Según las muchas explicaciones de la LGPL sí puedes, pero en el texto de la LGPL se lee en su punto cinco:

When a "work that uses the Library" [esto es, que no se trata de "trabajo derivado"] uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.

La licencia pone como ejemplo de uso "permitido" funciones de acceso y "pequeñas macros" (sic).

Hasta aquí lo podemos tener más o menos claro, pero ahora te pones a programar en Gtk y en algún momento decides subclasificar un control. ¿Es o no es tu trabajo derivado de Gtk?. Tu código, la nueva clase, extiende la funcionalidad de la biblioteca así que todo el programa pasa a considerase trabajo derivado y por lo tanto no puedes licenciarlo más que como LGPL. Subclasificar en la versión C de Gtk no se hace mucho más que nada porque es un dolor, pero es la forma básica de trabajar en Gtkmm o Gtk# (ambas LGPL).

Como responsable de la empresa que quiere usar Gtk o sus hermanas para sus programas cerrados, ¿qué haces?, ¿aleccionas a los diseñadores para que usen sólo patrones y prácticas de programación aceptables según la licencia?, ¿después de terminar cada programa encargas a un equipo de abogados para que audite el código?.

Qt es más clara al respecto: pagas y te olvidas. Puedes licenciar tú código como quieras. Habrá empresas en las que la tranquilidad de no dejar "cabos legales sueltos" justifique su uso.

[ Padre ]

Motif power :) (none / 0) (#53)
por ridiculum a las Mon Jun 7th, 2004 at 12:40:48 AM CET
(Información Usuario)

Pues eso, que aun queda al menos una empresa que desarrolla en Motif y en C. Algunas cosas ultimamente las hacen en Java (aun busco una explicacion al cambio tan radical), pero consideran que Motif era mejor (y tambien le busco una explicacion).

Podian usar Qt, incluso en su version GPL, por que las aplicaciones que hacen las desarrollan para X11 y al cliente creo que tienen la obligacion de darle los fuentes, asi que estos los pueden hacer GPL sin problemas. No tiene pinta de cambiar por que creo que son un poco cerrados de mollera o por que desconocen como esta el mundo del software fuera de la empresa.

[ Padre ]

Glade y xml (none / 0) (#54)
por ridiculum a las Mon Jun 7th, 2004 at 12:56:10 AM CET
(Información Usuario)

Si no recuerdo mal, a partir de gtk2 y glade2, se desaconseja la exportacion del GUI al lenguaje nativo (sea C, C++, perl, o cualquier otro) y aconsejan usar libglade. Otra cuestion es que los desarrolladores sigan esta norma o que glade este lo suficientemente desarrollado para poder hacerlo.

Sobre el desarrollo de glade, la cosa es bastante singular. La web esta practicamente abandonada y no he visto los archivos de la lista de correo en http://mail.gnome.org/archives/. Si te das un garbeo por el ftp de gnome, puedes ver hasta una version 2.6 de glade, asi que supongo que habran actualizado los widget, pero no se si algo mas. Lo cachondo esta en el cvs de gnome. Alla por el 2001 empezaron a hacer un glade2, despues aparecio un glade3, y creo que nunca mas se supo de ellos. En los changelog del cvs de glade3 se ve cierta actividad, pero no he visto ni una noticia sobre ellos, asi que por ahora seguimos con el glade viejo me parece a mi.

[ Padre ]

De GNOME a KDE | 57 comentarios (57 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

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