En route pour GTK+ 3.0
Découvrez le futur de cette bibliothèque graphique multiplateformes
Le 2009-10-08 11:15:45, par gege2061, Rédacteur
Comme je vous l'annonçai lors de la sortie de GTK+ 2.18, et suite à la réunion sur IRC, la branche 2.90 de GTK+ a été créée sur le dépôt git : http://git.gnome.org/cgit/gtk+/tree/?h=gtk-2.90
Concrètement, cette branche va permettre de préparer le terrain pour l'arrivée de GTK+ 3.0, Voici les taches prévues :
2.9 development branch tasks
La décision a donc été prise de casser la compatibilité de GTK+ 2.0 (qui date de 2002), afin de pouvoir ajouter de nouvelles fonctionnalités. Voici un résumé de ce qui est prévu :
Features planned for 3.0
Concrètement, cette branche va permettre de préparer le terrain pour l'arrivée de GTK+ 3.0, Voici les taches prévues :
- Création de la branche 2.90
- Mise à jour régulière de la branche 2.90 à partir de la branche principale
- Suppression du code obsolète
- Suppression de tous les champs publique des structures
- Désactivation des fonction obsolètes par défaut
- Faire appliquer l'inclusion d'un fichier d'entête unique
- Veillez à la possibilité d'installer en parallèle GTK+ 2.0 et 3.0
2.9 development branch tasks
La décision a donc été prise de casser la compatibilité de GTK+ 2.0 (qui date de 2002), afin de pouvoir ajouter de nouvelles fonctionnalités. Voici un résumé de ce qui est prévu :
- Un nouveau widget de base pour les barres de défilement afin de simplifier leur implémentation
- Simplification de l'API de drag & drop
- Une API simple pour la transparence des widgets
- Création d'un conteneur d'animation
- Fonctionnalités physiques (cinétique de défilement, magnétisme, friction, etc.)
Features planned for 3.0
-
liberforceModérateurErreur, c'est -DG_DISABLE_DEPRECATED pour virer les symboles obsolètes de la GLib, et -DGTK_DISABLE_DEPRECATED pour les symboles obsolètes de GTK. Pour ceux qui utilisent des bibliothèques GNOME (genre libgnome ou libgnomeui), ces bibliothèques vont complètement disparaître, la plupart des composants utiles ayant été intégrés dans GTK+ (c'est le projet Ridley).
De même les règles d'inclusion de fichiers d'en-tête ont changé pour ne pas laisser apparaître l'implémentation. Il faut compiler avec -DG_DISABLE_SINGLE_INCLUDES -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES
Et si votre application respecte toutes ces règles, et n'utilise rien qui soit obsolète, la migration à GTK+ 3.0 se fera sans problème, avec juste une recompilation...le 18/11/2009 à 13:59 -
gerald3dExpert confirméAie!!!
Gtk+3.0 pas compatible avec Gtk+2.0?
Un frein plus qu'une possibilité d'ouverture. Maintenant je comprends que cela puisse arriver pour permettre un bon en avant conséquent.le 08/10/2009 à 13:23 -
gege2061RédacteurBah oui c'est un peu le but :p
A première vue, c'est surtout la compatibilité binaire qui sera le plus touchée : je trouve déjà fort d'avoir réussi à la maintenir pendant 7 ansAu bout d'un moment ils commencent à avoir épuisé les champs réservés...
Au niveau des sources, si tu n'utilise pas les fonctions obsolètes, il n'y auras pas trop de soucis. Il ne reste plus que les utilisations des attributs publiques à remplacer (je pense par exemple à GtkDialog.vbox), travail qu'il est déjà possible de faire en désactivant les membres scellés (seal), mais je ne sais pas commentle 08/10/2009 à 13:50 -
gege2061RédacteurJe viens de trouver, il suffit d'ajouter l'option GSEAL_ENABLE lors de la compilation de ton application :
Code x : CFLAGS="-DGSEAL_ENABLE -DDISABLE_DEPRECATED" ./configure
Il faut généralement modifier le code du genre :
En :Code : Bar *bar = foo->bar;
Code : Bar *bar = foo_get_bar (foo);
le 08/10/2009 à 14:14 -
Franck.HRédacteurHa oui c'est clair que ca fait maintenant un sacré bail qu'elle existe cette branche 2.0 et je la trouvais également un peu vieillotte
Ce qui me manque le plus dans GTK+ par rapport au système de fenêtrage de Windows, c'est les fenêtre MDI soit une fenêtre mère qui peut contenir des fenêtre filles... je pense que cette fonctionnalité n'est toujours pas possible le 08/10/2009 à 20:31 -
oliviergb2Candidat au ClubCe que l'on pourrait attendre d une GTK+ 3.0 :
* plus grande facilite a construire les packages
* simplification de tous ces packages
* meilleure doc sur les styles
* la possibilite d'enregistrer une session et de la rejouer automatiquement... (systeme base sur le nom des wdigets pas sur la postion du pointeur de souris)le 27/10/2009 à 14:48 -
liberforceModérateurLes MDI sont une bouse sans nom qui a toujours dérouté les utilisateurs (un peu comme les boites de dialogue modales, atroces aussi côté intuitivité). C'est pour ça qu'on est passé aux systèmes à base d'onglets. Mais en fait pour bien faire, la gestion des onglets doit se faire dans le gestionnaire de fenêtres (metacity sous GNOME, bientôt mutter), pas dans le toolkit graphique.le 18/11/2009 à 14:02
-
liberforceModérateurQu'appelles tu les "packages" exactement ?
Dogtail te permet déjà d'enregistrer/rejouer des sessions... Du reste ce type d'outil n'a rien à faire dans GTK+, cela doit rester des outils externes...le 18/11/2009 à 14:06 -
oliviergb2Candidat au Clubcrois tu ? pour une QA correcte il faut etre capable d'automatiser les sequences interactives. Dogtail si je ne m'abuse est base sur le mouvement de la souris => donc plate-forme dependant, apparence du GUI dependant (si on a agrandi un widget, deplace un bouton ca ne marchera plus)... il existe des solutions pour Tk, Qt, qui ne suvient pas ce principe... et donc nous allons probablement abandonner GTK pour autre chose.
Ensuite si la communaute GTK veut rester uniquement sur les applications libres a diffusion reduite, c est un choix.le 06/10/2010 à 15:04 -
liberforceModérateurDéjà dans le monde Windows, ils n'ont pas franchement l'air pressés pour basculer en 64 bits. Alors c'est sûr, je ne connais pas cette plateforme là, et j'imagine qu'il doit y avoir des problèmes à la pelle, je veux bien te croire. Mais les ressources compétentes à ce niveau sont assez rares dans la communauté. Tor Lindquist est la personne qui s'occupe principalement de GTK pour Windows, mais toutes les ressources sur GTK sont rares, et cela fait longtemps que cela est un soucis. En revanche, même si GTK+ ne s'intéresse pas assez à Windows (ce que je trouve aussi regrettable), cela m'étonnerait qu'il disparaisse pour cette raison. GTK+ est encore à mon avis principalement utilisé sous Linux, et même s'ils s'ouvre moins vite que d'autres toolkits à Windows, je ne pense pas que cela soit suffisant pour estimer qu'il mourra à terme. La situation s'améliore lentement, mais constamment.
Super, au boulot on utilise sous Windows AutoIt, qui se base sur les noms des widgets pour se repérer plutôt que sur la position de la souris. Et devine quoi ? Les scripts pètent si tu changes la langue de l'application, dès qu'on corrige une chaîne de caractère de l'ihm, ou la langue du Windows qui changent le texte des boutons système. Sans compter qu'ils étaient faits pour une application par défaut en français et qu'en offshorant la maintenance, il a fallu tous les convertir en anglais.
Aucun outil n'est parfait, après à toi de voir quel est ton besoin. Selon le contexte, un outil peut être meilleur que l'autre, mais l'approche de dire "c'est nul parce que ça utilise cette méthode", ça me parait un peu réducteur: les autres méthodes ne sont pas exemptes de défauts.
Super argument, je sens que ça fait avancer le débat...le 08/10/2010 à 15:04