Discussion :

[gege2061]

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 :

• 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

Et vous, qu'attendez vous de cette nouvelle version majeur ?
Pensez-vous que cette nouvelle version puisse populariser d'avantage GTK+ ?

[gerald3d]

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.

[gege2061]

Gtk+3.0 pas compatible avec Gtk+2.0?

Bah 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 ans Au 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 comment

[gege2061]

désactivant les membres scellés (seal), mais je ne sais pas comment

Je viens de trouver, il suffit d'ajouter l'option GSEAL_ENABLE lors de la compilation de ton application :

Code x :

Sélectionner tout - Visualiser dans une fenêtre à part

CFLAGS="-DGSEAL_ENABLE -DDISABLE_DEPRECATED" ./configure

Il faut généralement modifier le code du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Bar *bar = foo->bar;

En :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Bar *bar = foo_get_bar (foo);

[Franck.H]

Ha 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

[oliviergb2]

Ce 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)

[liberforce]

Je viens de trouver, il suffit d'ajouter l'option GSEAL_ENABLE lors de la compilation de ton application :

Code x :

Sélectionner tout - Visualiser dans une fenêtre à part

CFLAGS="-DGSEAL_ENABLE -DDISABLE_DEPRECATED" ./configure

Erreur, 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...

[liberforce]

Ha 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

Les 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.

[liberforce]

Ce que l'on pourrait attendre d une GTK+ 3.0 :
* plus grande facilite a construire les packages
* simplification de tous ces packages

Qu'appelles tu les "packages" exactement ?

* 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)

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...

[oliviergb2]

Qu'appelles tu les "packages" exactement ?

la recompilation des librairies sur les differentes plateforme. Nous avons finance le portage WIN64 et ca a ete un fatras pas possible.
Si GTK+ ne si'nteresse pas assez la plateforme windows, il disparaitra.

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...

crois 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.

[liberforce]

la recompilation des librairies sur les differentes plateforme. Nous avons finance le portage WIN64 et ca a ete un fatras pas possible.
Si GTK+ ne si'nteresse pas assez la plateforme windows, il disparaitra.

Dé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.

crois 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.

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.

Ensuite si la communaute GTK veut rester uniquement sur les applications libres a diffusion reduite, c est un choix.

Super argument, je sens que ça fait avancer le débat...