GTK+ 4.0 ne sera pas GTK+ 4

GTK+ Hackfest 2016 (© Matthias Clasen)

Le GTK+ Hackfest 2016 se déroule en ce moment même à Toronto. Plus d’une quinzaine de développeurs s’y sont retrouvés pour trois jours de développement et de discussions, décidant ainsi du futur de cette bibliothèque utilisée pour concevoir les interfaces graphiques des applications GNOME et d’un certain nombre d’autres projets majeurs.

L’une des discussions ayant fait le plus de bruit concerne le versionnage des prochaines versions majeures (GTK+ 4, 5, 6…).

Depuis la sortie de GTK+ 3.0 en février 2011, les nouvelles versions mineures se sont succédé ces dernières années, apportant à chaque fois leur lot de nouvelles fonctionnalités, mais également de problèmes, cassant régulièrement l’API ou les thèmes utilisateurs. À tel point que ce manque de compatibilité ascendante est désormais l’une des critiques les plus courantes, et que différents projets ont préféré abandonner GTK+ au profit de Qt, ou de retarder leur migration de GTK+ 2 vers la version 3.

Pour rappel, GTK+ 1 est sorti en 1998, GTK+ 2 en 2002 et GTK+ 3 en 2011. Des écarts toujours plus grands, qui obligent à apporter régulièrement de nouvelles fonctionnalités pour pouvoir coller aux nouvelles technologies ou couvrir de nouveaux besoins.

L’une des solutions envisagées, serait de sortir plus régulièrement de nouvelles versions majeures, considérées comme stables, qui ne recevraient plus que des correctifs améliorant la stabilité ou la sécurité (pour de plus amples informations, je vous conseil la lecture des deux billets de blog d’Allison Lortie, Gtk 4.0 is not Gtk 4 et Gtk 5.0 is not Gtk 5).

Après la sortie de GTK+ 4, qui ne devrait probablement pas avoir lieue avant 2018, une nouvelle version majeure sortirait approximativement tous les deux ans. Et entre chaque nouvelle version majeure, nous continuerions comme aujourd’hui de bénéficier de nouvelles versions mineures tous les six mois, qui apporteraient leur lot de nouveautés.

Mais c’est là que ça se gâte. Pour le moment, on semble se diriger vers un GTK+ 4 qui ne correspondrait pas à GTK+ 4.0. Et il en irait de même pour GTK+ 5 ou 6. En gros, durant les dix-huit premiers mois (ce qui correspond à trois versions mineures), les développeurs seraient libres d’ajouter de nouvelles fonctionnalités et de casser l’API autant qu’ils le souhaitent. Une fois le code stabilisé, il sera alors décidé que GTK+ 4.6 ou 4.8 pourra devenir le nouveau GTK+ 4.

GTK+ Hackfest 2016 (© Matthias Clasen)

À ce moment de l’article, vous ne pouvez vous empêcher de trouver ça idiot et de vous demander pourquoi ils ne travailleraient pas plutôt sur une branche de développement qui, une fois stabilisée, donnerait GTK+ 4.0, première version stable de cette nouvelle branche ?

De l’avis des développeurs, il semble y avoir deux publics, qui ont chacun des besoins différents. D’un côté des projets comme GNOME, qui souhaitent pouvoir bénéficier rapidement des dernières nouveautés sans avoir besoin d’attendre deux ans. Projets qui, de par leur taille, auront toujours la main d’œuvre nécessaire pour adapter les différentes applications aux éventuelles nouveautés ou autres cassures d’API. Et de l’autre, les développeurs d’applications tierces, qui préféreront plutôt se baser sur une version stable qui ne bougera plus, et ne nécessitera donc plus une maintenance incessante et régulière.

Maintenant, il faut savoir que les discussions ont toujours lieues et qu’aucune décision ne sera prise avant le prochain GUADEC, qui se tiendra cette année du 12 au 14 août en Allemagne. Il est donc possible que le versionnage change encore d’ici là. Mais une chose est sûre, de l’avis même des développeurs, des versions stables plus régulières devraient faciliter et accélérer le développement, ce qui devrait nous apporter plein de bonnes choses dans les années à venir.

Une inconnue demeure néanmoins. Combien de branches seront maintenues en parallèle ? Surtout quand on sait que GTK+ 2, qui en est actuellement à la version 2.24.30, est toujours maintenu, près de quinze ans après sa première apparition.

3 thoughts on “GTK+ 4.0 ne sera pas GTK+ 4”

  1. Salut les GtkIstes,

    étant l’un des nombreux développeur tiers utilisant GTK+-3.* pour mes interfaces graphiques,

    j’ai été fortement surpris et outré quand dans j’ai mis a jours ma distribution Linux (Ubuntu-Gnome) passant de gtk+-3.18 a gtk+-3.20…

    Je suis encore en train d’adapter mes programmes au changements de version MINEURE (ce qui ne devrai rien changer mais simplement apporter de nouvelle choses !)…
    Mais lors du passage j’ai remarquer des changements, pas seulement l’apport de nouveautés mais désagréablement aussi certains changement de comportement des widgets de gtk.
    Les widgets sont ce qu’il y a de plus basique et ne devrai en aucun cas changer de comportement lors de leurs manipulation lors d’un changement de version mineure.
    Et d’autre part le comportement d’un programme entier qui est issue d’un long labeur (it-edit mon éditeur a terminaux intégrées) se trouve fortement perturber.
    Étant le développeur de it-edit je me suis accrocher malgré tout et je suis obliger d’écrire une nouvelle version de it-edit a cause d’un changement de version MINEURE.

    C’est trop tôt pour moi de dire que que c’est honteux de ne rien respecter en parlant de rétro-compatibilité entre version de gtk+-3.*.

    Mais je pense que dans notre époque nous oublions nos racines,
    car il fût un temps, époque sur laquelle se base les outils que nous avons maintenant,
    ou les développeurs avaient vraiment la vie dure (encore plus que de nos jours) et blesser ses utilisateurs, par la liberté que prennent certains développeurs de casser une bibliothèque fût inconcevable pour nos pères.

    Alors je conseille vivement a tous les responsables de bibliothèques sur lesquelles nous nous basons de faire preuve d’un peu de bon sens avant de détruire des projets par milliers, issue d’un long labeur, par des décisions absurdes d’évolution de leur bibliothèque. Comme la casser simplement.
    Si ils désire casser leur code et bien qu’ils écrivent une nouvelle version majeure.

    Je pense aussi que les développeurs de gtk veulent trop satisfaire des projets comme le bureau gnome laissant les autres dans une belle m€rde.

    Quand vous parler de passer a Qt, facile a dire !

    Personnellement j’utilise gtk depuis plusieurs années en python, C et C++.

    Et cela prends des années avant a maîtriser gtk correctement.

    Alors un passage a Qt serai peut-être une bonne chose pour le futur mais

    jeter des années d’expériences à la poubelle tout cela a cause de développeurs irresponsables oubliant des principes qui ont permis la perpétuité des ordinateurs et les principes et les règles (les racines) de base qu’ils ne faudrait jamais bafouer comme cela se fait de plus ne plus de nos jours.

    Concernant le versioning d’une bibliothèque il y a quelques règles connaître comme:

    Si l’on enlève une fonction de la bibliothèque et l’on est obliger d’incrémenter le numéro de version majeurs et de faire paraître une nouvelle version.
    Il est inconcevable pour moi de violer celui ou ceux qui utiliseront la fonction qui serai enlever.

    Mais il y en a d’autres des règles pour respecter ses clients, voyez comment le monde informatique a été construit, sans parler des problèmes de comptabilités systèmes, pour vous apercevoir que nos systèmes sont issue d’un long labeur et de besoin de cohérence afin de construire un futur.

    Car il y eu aussi des catastrophes dans l’évolution de l’informatique:

    je pense a UNIX qui est devenus propriétaire a un moment de l’histoire,

    blessant ainsi tout ceux qui ont travailler pour bâtir un OS meilleur et non seulement les employés de AT&T mais les milliers de bénévoles auquel ont a volé leur liberté.

    A cause d’une histoire de fric.

    1. Dans un futur proche, une version stable avec support long est prévue, ce qui sera sans doute le meilleur choix pour les développeurs tiers qui n’ont pas forcément le temps ou l’envie d’adapter sans cesse leur code. Encore un peu de patience, et tous ces désagréments seront bientôt du passé.

  2. C’est une bonne nouvelle !
    Je garde un œil sur le fameux GUADEC.
    Merci pour l’info.
    Pour moi ce fût le premier vrai désastre.
    Avant le look de GTK-2 changeait, mais bon…
    (c’est sûrement une histoire de thème).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *