Barrapunto

Exise Algun entorno de desarrollo en GNOME como Kdevelop, en lo posible MEJOR?

Tienes Anjuta, aunque, si no me equivoco, no trae un editor de diálogos incorporado (para eso tendrías que usar Glade)

si, Anjuta. Y, mejor aun, Anjuta2, que es la unión de Anjuta y GNOME Devtools, que es lo que está actualmente en desarrollo, para GNOME 2.

Bueno yo en linux apenas inicio, pero les pregunto sin flames ni nada,

¿Cuando programar en qt y cuando en gtk+?

¿Cuál es la que tiene más futuro?

¿Porqué sólo hay aplicaciones comerciales de qt pero no de gtk+ (eagle, hancon office)?

El propio KDevelop te permite crear aplicaciones para GNOME:

"Application Wizard:
The KAppWizard offers the generation of different application frameworks to create new programs. Available are a standard KDE application with menubar, toolbar and statusbar, a mini-KDE-application with an empty Mainwindow, a complete GNOME application, a Qt-only based application also with menubar, toolbar and statusbar and finally a C/C++ Terminal application type."

1) Depende de tus gustos, ambos toolkits son bastante buenos. Muestra de ello son KDE y GNOME. Usando GTK+ y Gtkmm puedes programar usando C/C++ y Qt es C++ nativo. 3) Hay aplicaciones comerciales basadas en GTK+: Evolution GobeOffice ApplixWare Office GPS (un IDE) ....

A mí gtkmm me encanta (sobre todo sigc++ y tb bakery) pero tiene dos problemas ¿insalvables? que en mi modesta opinión son graves:

Gtk+ (la biblioteca C) no propaga los errores para una posible gestión de los mismos en un nivel más alto. Si falla, todo "explota".

Por ejemplo, no es posible tratar errores eventualmente recuperables sacando un mensajito del tipo "No hay suficiente memoria para completar la operación, detenga algunos procesos y pulse reintentar".

Esto es endémico de muchas bibliotecas C. En C es soportable pero en C++, donde hay mecanismos que solucionan esto, es horrendo y gtkmm arrastra esa losa de gtk+.

El otro problema (que en parte deriva del anterior) es que no se pueden usar excepciones de ningún tipo (entre comillas: en realidad sí se puede pero es muy delicado y propenso a fallar de forma arbitraria) dentro de clases que extiendan a clases de gtkmm (sobre todo en funciones virtuales de eventos y similares).

Qt por contra, es mucho más completa que Gtkmm (incluye por ejemplo todo un conjunto de contenedores ajenos a STL, clases para manejar xml, animaciones gif, mng, etc). También es muy divertida de programar... Pero no tiene sigc++ :-)

> ... Pero no tiene sigc++ :-)

No haré comentarios al respecto, porque creo que el mecanismo de signals/slots es mucho más productivo ;-)

De todas formas, para quien quiera formarse su propia opinión, aquí ( http://www.linuxorbit.com/modules.php?op=modload&n ame=Sections&file=index&req=viewarticle&artid=527 ) hay una entrevista con Murray Cumming, uno de los autores de gtkmm, y aquí ( HREF="http://www.telegraph-road.org/writings/gtkmm _vs_qt.html ) está la respuesta de Guillaume Laurent, ex-autor de gtkmm y desarrollador de Rosegarden (que desde que abandonó gtkmm está basado en KDE :) ).

Dos frases curiosas que dice Guillaume :

"Two weeks after taking on Qt, I was more proficient with it than I ever was with gtkmm, and I worked on the damn thing for about three years :-). "

"The bottom line is that about a month after switching to Qt/KDE, I had made more progress than in the past 3 years."

Por supuesto, es un caso particular, no siempre tiene que ocurrir igual. Pero en cualquier caso, creo que da que pensar, y creo que su respuesta en telegraph-road es de obligada lectura para todo el que quiera decidir qué librería usar.

Saludos

--
Antonio Larrosa
larrosa _@_ kde.org

Este mensaje será un poco largo, así que lo resumiré de entrada: a Gtkmm se le pueden achacar que no tiene "tantas cosas" como Qt pero nunca una arquitectura y diseño defectuoso. Gtkmm tiene una api sencilla, efectiva y muy cómoda, apoyada por un diseño muy, muy bueno.

Ahora, el resto del mensaje :-):

> No haré comentarios al respecto, porque creo que el mecanismo de signals/slots es mucho más productivo ;-)

¿Más productivo en el caso de sigc++ o más productivo con las señales propias de Qt?. Ambas bibliotecas manejan los conceptos de signals/slots de manera similar, sin embargo sigc++ tiene algunas ventajas:

No precisa de un preprocesador especial para su funcionamiento, como es el caso de Qt.

El sobrepeso por señal emitida es menor.

Sigc++ está desacoplada de gtkmm, esto la hace útil para refactorizar y añadir sin demasiadas complicaciones ni sobrepeso signals/slots aplicaciones legadas. Con Qt lo mismo también es posible pero empleando para ello una biblioteca mucho más grande, con un tamaño en memoria mucho mayor.

Es más segura en cuanto tipos se refiere. Qt emplea punteros a char para describir sus señales y Sigc objetos. El enfoque de Sigc permite una comprobación fiable de las señales en tiempo de compilación, Qt por contra traslada esa comprobación al tiempo de ejecución con su correspondiente sobrepeso.

En los enlaces que ofreces, Guillaume nos dice acerca de este tema:

> I don't care. It may hurt my sense of aesthetics, but it doesn't hinder development

De acuerdo, es feo pero funciona. Gtk+ (en C) lo hace y nadie se queja (demasiado).

> It's dynamic. You can generate these strings and decide at runtime what to connect to what.

Este es el punto que considera más importante y además:

> Try doing this with libSigC, see how "easy" it is.

Es *muy* fácil de conseguir ese dinamismo en sigc++ y me sorprende que lo dude. Si necesitas esa característica (señales generadas en tiempo de ejecución) emplea el patrón de factoría, igual que cuando quieres objetos de cualquiera otra clase generados de la misma manera. Así de simple.

Sobre la crítica de Murray Cumming a Qt de que no es "C++ estandar", Guillaume se defiende de la siguiente manera:

> What problems do you see with the use of Qt in combination with other C++ APIs ? In Rosegarden we're happily using the STL

Cierto, pero eso es más mérito de STL que de Qt :-). Los contenedores STL, los algoritmos/functors, etc son fácilmente adaptables a cualquier sistema, mucho más que si STL hubiera optado por un ancestro común para todas las clases como Qt con su QObject.

Y sobre la mejora en productividad:

> "Two weeks after taking on Qt, I was more proficient with it than I ever was with gtkmm

Guillaume menciona, por ejemplo, que el necesitaba clases para manipular xml y que en vez de tener que estudiar el api del wrapper c++ de libxml, prefiere utilizar Qt en la que viene "todo integrado".

Qt te ofrece una enorme cantidad de clases: si necesitas clases de acceso a bases de datos, xml, sonido, sockets y protocolos de red, hilos independientes de la plataforma, protocolo para comunicación entre objetos de distintos procesos, manejo de impresión, cadenas unicode... En Qt las hay, todo integrado y con una interfaz homogenea.

Gtkmm no puede competir con eso (y me atrevo a decir que ni aún en conjunción con las bibliotecas Gnome ofrecen tanta funcionalidad) pero, en lo suyo (crear interfaces gráficas) Qt no saca ventaja en productividad a Gtkmm y es "menos traumática" de adoptar para dar un lavado de cara a viejos proyectos (subjetivo, de acuerdo).

Y sobre la viabilidad de Gtkmm, Guillaume ofrece como argumento en contra que hay muchas más aplicaciones escritas con Qt que con Gtkmm.

Qt lleva en la palestra desde 1995, es una biblioteca madura, multiplataforma y con solera. Gtk+ por contra es una "advenediza", no incluye ni un tercio de las funcionalidades que incluye Qt,