GNOME, la integración y QT

Escrito el y tuvo 2 comentarios

En mi artículo anterior les comentaba el nivel de integración que Unity logra con las aplicaciones en Ubuntu, y vía twitter el amigo @x11tete11x me comentaba al respecto, donde me decía que el problema no son las librerías Qt, sino las GTK y me pasaba este enlace de Phoronix.

El artículo trata sobre la muerte anunciada de oxygen-gtk, un tema creado para hacer visualmente compatible las aplicaciones GTK dentro de KDE, siempre y cuando se use Oxygen como estilo. El problema radica que GTK cambia constantemente con cada lanzamiento, y ahora hace uso de CSS para el estilo de las aplicaciones, y oxygen-gtk utiliza GtkThemingEngine la forma antigua de hacerlo.

Portar oxygen-gtk a CSS conllevaría a Hugo Pereira Da Costa (el desarrollador que portó este tema) trabajar prácticamente desde cero y es algo que no está dispuesto a hacer, y no soy yo quién se le va a reprochar. Lo que me molesta, es la actitud de los desarrolladores de GNOME, especialmente Ben Otte cuando dice:

As for oxygen-gtk in particular, I’m actually happy that it’s stopped working because its codebase has been explicitly violating the contract for theming engines since its inception.

¿No hubiese quedado mucho mejor decir: Ok Hugo, yo te ayudo en lo que necesites? A mi me da la sensación que los de GNOME quieren ir a su bola, a lo Apple, a lo Windows.. si en tu escritorio mi código no funciona, es problema tuyo.. o te adaptas a mi o no usas mis aplicaciones.

En el foro de Phoronix un usuario comenta:

Since GNOME 3 exists, I’ve always heard that the themes will have to be converted to CSS. What did the third-party devs expect? That the old theme engines will be un-deprecated after a few years?
GNOME has spent a lot of effort converting their own themes to CSS, it’s not their job to convert all the themes that ever existed on the platform.
They warned a long time ago; the concerned devs did nothing; it’s not working now: that is perfectly normal and for sure I won’t blame the GNOME devs, they did everything by the book!

The only thing left is the fact that the major version is not bumped… Well, as said before, they had years to convert their themes; where they waiting to see GNOME 4 to start redoing their work?

O sea, desde que salió GNOME 3 sus desarrolladores avisaron que iban a ocurrir cambios, y por ende el resto tenía que adaptarse al cambio.. Ok, eso está bien, pero si con cada lanzamiento cambias algo al punto de que lo que funciona en GTK 3.14 no funciona en GTK 3.16 ¿de quién es la culpa?

Repito, la actitud de los desarrolladores de GNOME me molesta por el hecho de que lo ideal sería que todos trabajen en armonía, para que los usuarios de KDE u otros escritorios que usen Qt tengan una buena experiencia, pero no les interesa.. ¿saben por qué no? Porque como bien me comentaba @x11tete11x, al contrario de GTK, Qt se adapta a lo que sea, y por ende los desarrolladores de GNOME no tienen que mover un dedo.

Por suerte, la gente si piensa en KDE y en sus usuarios y con la llegada del nuevo tema para Plasma, está en proceso un nuevo tema GTK para hacer que las aplicaciones luzcan iguales. De hecho ya se puede usar con la condición de que tengamos instalado GTK 3.16 o superior y los motores gtk Pixmap/Pixbuf.

Ojo, todo esto es simplemente mi opinión, pues no soy desarrollador y no sé realmente quién sigue una filosofía mejor, si GTK o Qt.

Comparte:

¿Ideas? ¿Comentarios?

  1. Sinceramente yo apoyo a GTK. La filosofía de Qt es del estilo «vamos a hacerlo todo nosotros, da igual que alguien ya se lo haya currado». Intenté programar Qt y si te sales de QtCreator, QMake y todo el universo Qt, se vuelve un infierno. Qt no es una librería, prácticamente es un lenguaje de programación propio. ¡El C++ estándar no se puede usar en Qt! Te obligan a usar el Meta-Object Compiler, un compilador solo para Qt. Define palabras reservadas nuevas (signal, slot, etc). Ninguna, repito, ninguna otra librería hace esto tan mal. Luego implementa toda la librería estándar de C++ de nuevo. QString (tenemos std::string), QList (tenemos std::list), QVector(tenemos std::vector) y un largo etc (y por cierto QString/std::string son incompatibles entre sí, hay que convertirlos manualmente, etc…). Luego está el hecho de usar C++. No es algo que me disguste especialmente pero las librerías hechas en C++ son mucho más difíciles de usar en otros lenguajes como Haskell, Node.js, Rust o Go. GTK al estar en C (y poder usarse en C++ si se desea con GTKMM) permite una mayor variedad de lenguajes. En el fondo se compara mal. GTK solo es una librería gráfica y Qt es un mastodonte que tiene un módulo (varios en el fondo) de librería gráfica. GTK, FLTK, EFL, wxWidgets me parecen mucha mejores opciones que usar Qt. Ahora bien, Qt puede empezar a hacer limpieza. Me gustaría que Qt6 fuese una alternativa seria.

    Responder
    1. mariela 7 años atrás
      @Adrián Arroyo Calle:

      Estás comparándolo desde el lado de desarrollador, que supuestamente es más fácil, pero se te olvida la dimensión «real». ¿De qué te sirve tanta facilidad si ellos cambian las reglas, y hay que reescribir? Coincide con lo de ”limpieza». En GTK+ 3.20 volvieron a ”limpiar» la API/ABI, repitiéndose este post. La cuestión real es que un cliente mío lleva pagado 3 veces por todas las reescrituras de su programa. Es el problema de ser Bleeding Edge.

      Responder

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.