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(...)
Journal Projet Ridley (gtk+-3.0 ?)
22
août
2005
# bravo !
Posté par patrick_g (site web personnel) . Évalué à 4.
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 _seb_ . Évalué à 5.
- 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 patrick_g (site web personnel) . Évalué à 1.
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 lezardbreton . Évalué à 1.
[^] # Re: bravo !
Posté par Croconux . Évalué à 1.
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 liberforce (site web personnel) . Évalué à 2.
[^] # Re: bravo !
Posté par fredix . Évalué à 1.
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 liberforce (site web personnel) . Évalué à 1.
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 fredix . Évalué à 3.
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 liberforce (site web personnel) . Évalué à 2.
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 fredix . Évalué à 3.
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 Elly . Évalué à -9.
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 revponpuneq . Évalué à 2.
>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 Elly . Évalué à -5.
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 liberforce (site web personnel) . Évalué à 9.
Faut arrêter de croire que le C c'est encore le langage à papy...
[^] # Re: Ce qu'il faudrait à Gtk+...
Posté par Jean-Baptiste Mayer . Évalué à 5.
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 rdg . Évalué à -5.
Ouais.. ben bof...
non en fait
[^] # Re: Ce qu'il faudrait à Gtk+...
Posté par HappyPeng . Évalué à 2.
Il faudrait arrêter de tout ramener à la performance ; dans le domaine du desktop il n'y a pas _que_ ça qui compte.
[^] # Re: Ce qu'il faudrait à Gtk+...
Posté par Stephane Wirtel (site web personnel) . Évalué à 3.
[^] # Re: Ce qu'il faudrait à Gtk+...
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Ce qu'il faudrait à Gtk+...
Posté par lint . Évalué à 6.
[^] # Re: Ce qu'il faudrait à Gtk+...
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
Imagine toi étant un gros C bien majuscule. Tu vas plus vite tout nu où trainant deux boulets en forme de pierres tombales ?
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Ce qu'il faudrait à Gtk+...
Posté par jcs (site web personnel) . Évalué à 3.
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 HappyPeng . Évalué à 5.
[^] # Re: Ce qu'il faudrait à Gtk+...
Posté par Sebastien Binet . Évalué à 2.
Ne peut-on pas parier sur l'avenir et se dire que des projets comme PsyCo[1], PyPy[2], Weave[3] et autres Pyrex[4] ne peuvent qu'ameliorer les performances de ce langage ?
(Sans parler des eventuelles amelioration du compilo python : pyc[5])
[1] http://psyco.sourceforge.net/(...)
[2] http://codespeak.net/pypy(...)
[3] http://www.scipy.org/documentation/weave/(...)
[4] http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/(...)
[5] http://students.ceid.upatras.gr/~sxanth/pyc/(...)
[^] # Re: Ce qu'il faudrait à Gtk+...
Posté par HappyPeng . Évalué à 3.
A mon avis ce sont des faux problèmes, il vaut mieux avoir une bonne base écrit dans un langage "généraliste" C/C++/Objective-C et choisir le langage le plus adapté à son application ensuite.
[^] # Re: Ce qu'il faudrait à Gtk+...
Posté par woopla . Évalué à 8.
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 TImaniac (site web personnel) . Évalué à 6.
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 alberthier (site web personnel) . Évalué à 1.
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 Sebastien Binet . Évalué à 2.
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 salvaire . Évalué à 2.
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 tanguy_k (site web personnel) . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 2.
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 Croconux . Évalué à -1.
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 Sebastien Binet . Évalué à 1.
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 ploum (site web personnel, Mastodon) . Évalué à 9.
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.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Pouquoi dans GTK ?
Posté par Ackira . Évalué à 2.
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(...)
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.