Journal Projet Ridley (gtk+-3.0 ?)

Posté par .
Tags : aucun
0
22
août
2005
Le projet Gtk+ va integrer tout un tas de fonctions/widgets utiles issus de bibliotheques existantes (genre libegg, libgnomeui...) pour :
1) Que gtk+ soit une plateforme plus complete
2) simplifier les dependances
2) Que les developpeurs aient moins de questions a se poser (j'utilise ou pas cette bibliotheque ?)

...Et tout ca s'appellera peut-etre bien Gtk+-3.0

http://mail.gnome.org/archives/desktop-devel-list/2005-August/msg00(...)
  • # bravo !

    Posté par (page perso) . Évalué à 4.

    Excellente idée. N'oublions pas que l'exclusion de la slack vient directement du bordel que représente la compilation de Gnome.

    Avec ce projet Ridley on obtient :
    1/ un GTK+ qui devient plus complet et donc plus utile
    2/ une simplification de la compilation et des dépendances de Gnome
    3/ un regroupement des devs autour d'un seul projet solide (GTK+) ce qui évite d'avoir des librairies périphériques peu/mal maintenues
    4/ un projet clair et enthousiasmant pour GTK+ 3.0


    La page du wiki :
    http://live.gnome.org/ProjectRidley(...)
    • [^] # Re: bravo !

      Posté par . Évalué à 5.

      Je me méfis beaucoup de ces grosses bibliothèques. Et cela pour plusieurs raisons:
      - C'est plus difficile à maintenir et de tenir à jour une version stable. Quid de la réactivité face aux bugs critiques ?
      - C'est plus difficile pour un programmeur de se plonger dans l'API.
      - Pour des petits projets, une grosse parties des fonctionnalités proposées ne sont pas utilisées.
      - On s'éloigne du concept KISS (Keep it simple, stupid).

      En outre, je ne suis pas sûr
      - que les développeurs des bibliothèques qui doivent être intégrées au projet acceptent facilement de voir leur travail changer de licence (GPL-> LGPL).
      - que les mainteneurs des bibliothèques acceptent d'intégrer l'équipe GTK (pour des raisons diverses).
      • [^] # Re: bravo !

        Posté par (page perso) . Évalué à 1.

        >> je ne suis pas sûr...< snip >...que les mainteneurs des bibliothèques acceptent d'intégrer l'équipe GTK

        Faudrait vérifier mais est-ce que la plupart des devs des bibliothèques Gnome ne sont pas des salariés de RedHat ? auquel cas ils obéiront et ils se conformeront à ce nouveau projet qui émane directement de RedHat.
        • [^] # Re: bravo !

          Posté par . Évalué à 1.

          Ce sont des bibliothèques non maintenues qui rejoindraient GTK. Dans ce cas là, je ne vois pas de problèmes...
          • [^] # Re: bravo !

            Posté par . Évalué à 1.

            Ce sont des bibliothèques non maintenues qui rejoindraient GTK. Dans ce cas là, je ne vois pas de problèmes...

            Euh... On refile aux développeurs de GTK des bibliothèques "undermaintained, and buggy" (voir l'annonce) et on leur demande se démerder avec. Sympa le cadeau. Il aurait été de bon ton de leur demander leur avis et de faire un peu le ménage avant. Cette annonce donne plus l'impression de vouloir se débarrasser de trucs encombrants dont on ne sait pas trop quoi faire.
    • [^] # Re: bravo !

      Posté par (page perso) . Évalué à 2.

      L'intégration libglade pourra déjà aider au développement multi-plateforme... Et c'est vrai qu'entre les vieilles libs et les docs pas forcément à jour, tu sais pas forcément ce que tu dois utiliser...
      • [^] # Re: bravo !

        Posté par (page perso) . Évalué à 1.

        L'intégration libglade pourra déjà aider au développement multi-plateforme...

        libglade aide au développement d'interface graphique via Glade. Même si elle est multi-plateforme elle n'aide en rien à ce sujet.
        Par contre c'est une bonne nouvelle, car c'est vraiment triste de voir de nombreux développeurs qui perdent du temps à coder leur IHM à la main...
        Il ne faut pas s'étonner de voir des IHM laides et peu fonctionnelles.

        L'intégration de libglade est une bonne avancée pour GTK+ et permettra de faire connaitre cette bibliothèque qui me parait indispensable à tous développeurs utilisant GTK+.
        • [^] # Re: bravo !

          Posté par (page perso) . Évalué à 1.

          De ce que je sais, tu te trompes. Glade permet la génération de code pour créer une IHM. Mais libglade permet l'interprétation du fichier .glade (format XML) pour générer à la volée l'IHM.

          Pour l'instant libglade est une bibliothèque GNOME. En la plaçant dans GTK (qui lui est porté), cela permettra de pouvoir utiliser libglade sous windows, et donc sa capacité à générer de l'IHM à partir du XML, sans recompilation.

          Moi je vois une différence...
          • [^] # Re: bravo !

            Posté par (page perso) . Évalué à 3.

            De ce que je sais, tu te trompes. Glade permet la génération de code pour créer une IHM. Mais libglade permet l'interprétation du fichier .glade (format XML) pour générer à la volée l'IHM.

            Oui merci je suis au courant c'est moi qui ai écrit ce texte :)
            http://www.gtk-fr.org/wakka.php?wiki=LibGlade(...)


            Pour l'instant libglade est une bibliothèque GNOME. En la plaçant dans GTK (qui lui est porté), cela permettra de pouvoir utiliser libglade sous windows, et donc sa capacité à générer de l'IHM à partir du XML, sans recompilation.

            Désolé libglade existent depuis longtemps pour Windows.
            http://gladewin32.sourceforge.net/(...)

            La seule différence c'est bien ce que je disais, libglade sera plus connu car intégré dans GTK+.
            • [^] # Re: bravo !

              Posté par (page perso) . Évalué à 2.

              ah, autant/au temps pour moi alors, je ne connaissais pas l'existence de ce projet...
              Mais dans ce cas pourquoi il y a tant de monde qui se prend la tête à coder des interfaces en GTK+ directement, plutôt que d'utiliser libglade ?
              • [^] # Re: bravo !

                Posté par (page perso) . Évalué à 3.

                Déjà parce que peu de dev connaissent finalement l'existence de la libglade.
                Ensuite le générateur de code de Glade a fait beaucoup de mal, en générant du code pas très maintenable et verbeux. Ils ont donc rejetté Glade. Mais de toute manière le générateur va disparaitre des prochaines versions de Glade.

                Ensuite certains bricolent pas mal au niveau du GObject et se sentent limités par libglade.
                Enfin cela fait dépendre un soft en GTK+ vers une bibliothèque externe supplémentaire, ce qui peut être contraignant pour certains.
  • # Ce qu'il faudrait à Gtk+...

    Posté par . Évalué à -9.

    Bonjour,

    Je pense que ce qu'il faudrait à Gtk+ 3.0, c'est surtout d'abandonner ce vieux reliquat qu'est le C et qui ne fait que l'handicaper, et passer à un véritable langage orienté objet, tel que C++ ou Java.

    Je pense que c'est comme ça que cette belle bibliothèque, fleuron du libre, pourra entrer de plein pied dans le 21ème siècle - et non pas en utilisant un vieux langage qui n'a pas évolué depuis les années 70.
    • [^] # Re: Ce qu'il faudrait à Gtk+...

      Posté par . Évalué à 2.

      >Je pense que ce qu'il faudrait à Gtk+ 3.0, c'est surtout d'abandonner ce vieux
      >reliquat qu'est le C et qui ne fait que l'handicaper, et passer à un véritable
      >langage orienté objet, tel que C++ ou Java.

      ...et pourquoi pas Objective-C ?


      --
      eric bachard
      • [^] # Re: Ce qu'il faudrait à Gtk+...

        Posté par . Évalué à -5.

        «...et pourquoi pas Objective-C ?»

        La dernière personne que j'ai vu travailler sur des bindings Gtk+ pour objective-C m'a lancé un escargot à la figure, alors franchement, non.

        Et puis, Objective-C, c'est aussi mort que le C tout court, y'a bien que les Maceux pour s'en servir encore un peu.
    • [^] # Re: Ce qu'il faudrait à Gtk+...

      Posté par (page perso) . Évalué à 9.

      Troll detected...
      Faut arrêter de croire que le C c'est encore le langage à papy...
      • [^] # Re: Ce qu'il faudrait à Gtk+...

        Posté par . Évalué à 5.

        Y'a que les électroniciens pour croire que le C est un langage de haut niveau.
        Il suffit de voire la quantité de modifications qui ont été apportées au langage par ses utilisateurs pour contourner ses limitations (genre le préprocesseur et la tonne de macros qui étendent encore plus la sémantique).
        Ou encore le volume occupé par la spécification de sa sémantique.
        Bien sûr que l'on peut faire de l'orienté objet en C. Bien sûr que l'on peut faire de l'orienté aspects. Merci Turing pour ce résultat fondamental - celui de l'équivalence de l'expressivité des langages Turing-complets.
        Combien de lignes de code à maintenir pour faire un héritage d'objets en C? (pas droit au préprocesseur, sinon c'est trop facile, ce n'est plus la sémantique de C)
        Combien de lignes de code pour mapper un objet sur un système de persistance?

        Si effectivement tu prends plus ton pied à recoder pour la 158ème fois une implantation de listes doublement chainées, je comprends que tu dises que le C soit bien. Sinon, si tu préfère te concentrer sur des aspects de plus haut niveau, il faut faire confiance à un langage de haut niveau, au compilateur, et à sa bibliothèque de base.
    • [^] # Re: Ce qu'il faudrait à Gtk+...

      Posté par . Évalué à -5.

      Tu voudrais remplacer un truc qui va vite par un truc qui rame c'est ça l'idée ? (je ne parle meme pas de java parceque je te vois meme plus à travers tout ces poils)

      Ouais.. ben bof...

      non en fait

    • [^] # Re: Ce qu'il faudrait à Gtk+...

      Posté par (page perso) . Évalué à 3.

      La conclusion est bonne, dommage que l'argument soit aussi bidon.

      D'abord le C a évolué depuis les années 70 puisque la dernière norme ISO date de 1999. Ensuite le C est sans équivalent pour de nombreuses applications (programmation système, embarqué...)

      Par contre je pense que GTK gagnerai à être réécrit dans un language de plus haut niveau (java, python, Eiffel - on peut rêver non ?). Le programmeur pourrait alors oublier de nombreux problèmes largement résolus avec ces langages comme le "memory management".
      • [^] # Re: Ce qu'il faudrait à Gtk+...

        Posté par . Évalué à 5.

        Pour le coup (Java, Python) on peut craindre d'énormes problèmes de performances si l'ensemble des applications venaient à être réécrites dans ces langages.
      • [^] # Re: Ce qu'il faudrait à Gtk+...

        Posté par . Évalué à 8.

        Ce qui t'intéresse en tant qu'utilisateur des librairies (c'est à dire développeur qui les utilise), c'est de pouvoir t'en servir dans le language qui t'intéresse.

        Or il y a une nombre assez important de bindings pour GTK+ - y compris en java, python et eiffel. Donc tu n'es pas pénalisé, et les dév de GTK utilisent ce qui leur semble le plus approprié. Et comme ca, tout le monde est content.

        Je suis pas persuadé de la pertinence de faire des librairies graphiques en un language de trop haut niveau, parce que c'est un endroit ou la performance brute est la plus importante, sinon l'utilisateur va trouver que ca rame. Exemple avec Java, qui subit un peu moins ces critiques depuis qu'il y a des toolkits natifs.
    • [^] # Re: Ce qu'il faudrait à Gtk+...

      Posté par (page perso) . Évalué à 6.

      Utiliser le C permet d'avoir une bibliothèque portable (hein parcque la compatibilité des compilateurs C++ c'est pas encore ca), et surtout facile à utiliser dans un autre langage :
      La quasi totalité des langages savent communiquer avec un API "plat" non objet écrit en C. Conclusion : On peut utiliser GTK dans pratiquement tous les langages.
      A moins d'exporter tous l'API C++ en C (à coup d'extern "C"), ce qui ferait perdre beaucoup de son intérêt à l'utilisation de C++, il est beaucoup plus difficile de "binder" ce langage dans d'autres langages.

      C'est facile à constater :
      combien de binding GTK ?
      combien de binding Qt ?

      Allez quelques indices :
      http://developer.kde.org/language-bindings/(...)
      http://www.gtk.org/bindings.html(...)
      • [^] # Re: Ce qu'il faudrait à Gtk+...

        Posté par (page perso) . Évalué à 1.

        Exactement.
        Personellement, je préfère le C++ et Qt mais je pense que GTK doit rester en C. C'est ce qui fait sa force et qui permet d'avoir une bibliothèque graphique disponible dans plein de languages.

        Si vous voulez programmer dans des langages de haut niveau avec GTK, vous pouvez : ex python, C# avec GTK# etc...
        GTK est dispo partout et c'est ça qui est bien.
      • [^] # Re: Ce qu'il faudrait à Gtk+...

        Posté par . Évalué à 2.

        il est beaucoup plus difficile de "binder" ce langage [le C++] dans d'autres langages.

        Ah bon ?
        Moi j'utilise ceci : Reflex[1] qui permet automatiquement de generer des bindings en python de mes classes favorites.
        Bon quand je dis automatiquement, il faut bien fournir un fichier xml pour specifier les differentes classes pour lesquelles je veux generer un dictionnaire (qui ensuite servira a binder le tout) et aussi accessoirement specifier les donnees membres que je veux "persistifier" (si besoin est).

        Une fois que l'introspection pour les differentes classes est realisee, c'est facile (TM) et cégagné(re-TM).
        Et ce, sans instrumentation du code C++.

        [1] http://seal-reflex.web.cern.ch/seal-reflex/index.html(...)
        • [^] # Re: Ce qu'il faudrait à Gtk+...

          Posté par . Évalué à 2.

          À encore un bon logicielle de chez HEP.

          Sur le papier c'est parfait. Le seul petit problème: gcc-xml est un hack non maintenu. Si ça ne rentre pas officielement dans gcc, c'est les emmerdes garantie ... Mais sa ils aiment.

          Je préferre donc SWIG, même si l'idée de reflex me séduit.
      • [^] # Re: Ce qu'il faudrait à Gtk+...

        Posté par (page perso) . Évalué à 3.

        > il est beaucoup plus difficile de "binder" ce langage dans d'autres langages.

        Faire un binding par dessus C++ a la mano oui c'est chaud.
        En revanche automatiser la creation d'un binding par dessus C++ c'est apparemment "facile".

        Le C++ est plus "verbeux" que le C: on a plus d'informations:
        classes, methodes privees/public, heritage... Toutes ces informations peuvent etre exploitees (ou non) par un parseur (par exemple doxygen). Plus celui-ci a d'informations mieux c'est car il pourra generer un binding plus efficacement contrairement a C ou l'on a juste des structures et des fonctions.

        Richard Dale qui s'occupe des bindings pour KDE l'avait explique dans une interview. Le probleme des bindings KDE c'est qu'il n'y a pratiquement personne pour travailler dessus. De plus beaucoup de devs sont satisfaits avec C++/Qt alors que pour C/GTK+ il y a une vrai demande.
        • [^] # Re: Ce qu'il faudrait à Gtk+...

          Posté par (page perso) . Évalué à 2.

          Je ne parle même pas de la génération automatique de binding, je parle simplement de l'interopérabilité "technique" :
          La plupart des langages proposent une méthode d'appel de fonction C uniquement, et pas de C++.

          Ce que font les outils "automatique" c'est créer une "couche" de glue qui exporte les API en C, bref en perdant tout l'intérêt de C++ tout en ajoutant une couche d'indirection.

          Pour KDE c'est encore pire : c'est pas du C++ standard, c'est encore plus galère à binder, et donc à maintenir, c'est pourquoi personne ne s'en occupe.
          Enfin tu le dis toi même : les gens sont satisfait de C++/Qt : effectivement, un API en C++, c'est bien pour coder en C++. C'est pas top du tout pour utiliser dans un autre langage.
  • # Pouquoi dans GTK ?

    Posté par . Évalué à -1.

    Le projet Gtk+ va integrer tout un tas de fonctions/widgets utiles issus de bibliotheques existantes

    C'est bizarre, partout où cette news a été publiée les réactions semblent enthousiastes mais je ne suis pas trop emballé par cette nouvelle. GTK était jusque là indépendant de Gnome. Gnome utilise GTK mais on peut très bien se servir de GTK sans se trainer tous les trucs dont on n'a rien à foutre comme Gconf. C'est d'ailleurs ce qui a attiré pas mal de développeurs vers ce toolkit. Les gens qui veulent justent faire une bête interface graphique muli plateforme pour leur appli se tournaient souvent vers GTK. Revers de la médaille de cette popularité : Il y a beaucoup d'appli GTK mais très peu d'applis Gnome, ce qui semble bien emmerder les développeurs de Gnome. Solution : On fourre tout dans GTK, comme ça qu'on le veuille ou non on se traine tout le framework même si on veut juste un pauvre panneau avec 2 boutons et 3 checkboxes et une appli GTK deviens d'office une appli Gnome. Bilan si on veut un toolkit léger et cross-plateforme il va falloir se tourner vers autre chose.
    • [^] # Re: Pouquoi dans GTK ?

      Posté par . Évalué à 1.

      Bilan si on veut un toolkit léger et cross-plateforme il va falloir se tourner vers autre chose.

      J'me lance ?
      Heuu... Qt ?

      Je n'ai encore jamais utilise Qt, ni GTK d'ailleurs, mais est-ce que ca parait plausible (comme remplacement) ou bien est-ce que Qt est deja une (un ensemble de) bibliotheque(s) trop volumineuse(eux) ?

      Cela etant dit, j'ai cru comprendre qu'avec Qt4, il y avait un decoupage plus fin (mieux pense?) des differentes bibliotheques...
    • [^] # Re: Pouquoi dans GTK ?

      Posté par (page perso) . Évalué à 9.

      nan, c'est pas ça le but. Le principe c'est que pour le moment il y'a plein de bout de librairies partout qui traine et qui ne sont ni dans gnome ni dans GTK.

      L'exemple le plus frappant est libegg, censé contenir juste des essais et des expériences. Mais y'a tellement d'auteurs qui l'utilise que c'est plus tellement un truc expérimental.

      où bien libeel, qui est un fourre-tout contenant tout ce que les développeurs de nautilus pre-1.0 ne savait pas où mettre.


      Et bien, si j'ai bien compris, le but est de reprendre les bouts de tout ça qu'on utilise quotidiennement dans GTK et les mettre dans GTK.
    • [^] # Re: Pouquoi dans GTK ?

      Posté par . Évalué à 2.

      Tu n'as pas lu et pas compris le but.
      Pour ce qui est de l'intégration d'une partie de la libgnome, il s'agit bien entendu uniquement de ce qui peut etre multi-plateforme. Je cite http://live.gnome.org/ProjectRidley(...)
      As Owen said in a recent GTK+ meeting, when looking over the list of APIs that we are discussing here, there are basically three categories:

      1. Cross-platform API - things that make sense on Windows / OS X
      2. X / freedesktop.org-specific API
      3. GNOME-specific API

      APIs in category A. are clearly suitable for moving to GTK+, APIs in category B. may or may not be suitable, and things in category C. are better off in a GNOME-specific library.


      On ne parle nulpart de Gconf. L'esprit GTK est bien gardé ici. On augmente juste la puissance du toolkit.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.