Alors pour le coup, je vois plein de commentaires disant "oh oui, comme tu as raison". Et bien ce ne sera pas mon cas, je suis en complet désaccord avec toi.
Il n'y a pas besoin de rappeler que le monde du bureau libre est très focalisé sur le toolkit, avec l'éternelle division entre GTK+ et Qt. L'une des premières choses qu'on dit sur une application tournant sur un bureau libre, c'est quel toolkit elle utilise.
Et pourquoi ? Parce que pendant des années il était difficile d'avoir une bonne intégration dans un desktop en utilisant des applis de toolkit différents. Ce n'est pas qu'une histoire de thème, mais aussi de design: une appli KDE et GNOME n'ont pas du tout la même tronche, même avec un thème identique. Fût un temps, tu n'avais pas 2 Go de RAM sur un desktop, mais plutôt moins de 512Mo, et utiliser des toolkits différents sur ton système te donnait une pénalité en termes de consommation mémoire. L'utilisateur averti sous Linux avait donc tendance à chercher des applications utilisant le même toolkit, parce qu'elles allaient souvent visuellement mieux ensemble, et en plus sa machine allait plus vite !
Aujourd'hui, GTK ou Qt ont des systèmes de thèmes assez puissants, et c'est surtout le design de l'application qui les distingue. Mais ça, ça dépend du développeur de l'appli, pas du développeur du toolkit.
C'est intéressant : par contraste, sous Windows, on parle rarement de ça, alors qu'il existe encore plus de toolkits différents. Et sur le Web, on ne sait même pas combien de toolkits existent; voici même une page qui en liste une quinzaine !
Tu pense que l'utilisateur Windows sait ce qu'est un toolkit ? Non, il voit juste un truc moche qui ressemble pas au reste, mais il est habitué, depuis le temps. Personne ne proposait mieux, ou il ne savait pas qu'il pouvait avoir mieux ailleurs. Une appli moche sous Windows, on s'y fait si elle marche (ex: VLC). Mais ça reste moche. Comme un salon fait de bric à brac. Il peut être très confortable, il est pourtant moche. Le même aussi confortable et joli, je ne suis pas sûr que les gens n'aiment pas.
Un autre problème, causé par l'obsession du toolkit, est bien entendu de diviser en deux le marché. Cela conduit à des situations où, plutôt que d'utiliser la meilleure application pour une tâche donnée, on en crée une nouvelle qui utilise son toolkit préféré. Je n'ai pas besoin de donner d'exemples de ça, n'est-ce pas ?
C'est le seul point où on est d'accord. Parfois le design de l'application est adapté pour s'intégrer au mieux à l'environnement de bureau, mais dans pas mal de cas c'est une pure copie.
Mais il ne faut pas oublier que GTK est né d'un réel besoin: la licence propriétaire de Qt. Une fois que l'écosystème autour de GTK était créé, et que Qt est devenu libre, que fallait il faire ? Tuer GTK ?
Enfin et surtout, l'obsession du toolkit décourage les éditeurs de logiciels indépendants de faire des portages pour nos bureaux libres. Ceci de plusieurs façons : en plaçant des attentes trop élevées en termes d'intégration ("si les combobox n'ont pas des coins arrondis, j'en veux pas")
Les thèmes sont là pour ça… Si tu n'as qu'un version utilisant un autre toolkit que ton préféré, bin tu fais comme sous Windows: tu fais avec. C'est la différence entre préférence et exigence.
À chaque fois, le résultat est le même : on n'a déjà pas les ressources qu'on voudrait pour développer les fonctionnalités centrales d'un navigateur Web, et pour faire l'intégration aux plateformes les plus importantes sur le marché. Pourquoi dans ces conditions investir dans KDE qui ne doit pas représenter plus de 0.2% du marché ?
Le problème ici, c'est les parts de marché. Si Linux avait 20% de parts de marché, et KDE 40% de ceux là, ç'aurait paru bien plus intéressant. Mais doit-on en déduire que forcément tout ce qui se fait sous Linux (qui représente 1% de PDM) n'a aucun intérêt ? 1% c'est déjà pas beaucoup, pourtant Mozilla fournit bien des binaires pour Linux, c'est bien qu'elle y trouve un intérêt, non ? La fragmentation des toolkits, cela ralentit juste la progression vers la masse critique. Mais de la même manière que tu ne peux pas demander aux fabricants de matériel de faire des drivers pour tous les OS, même les plus exotiques, il y a un moment où la communauté doit faire une partie du boulot…
Mais à ce moment-là, GTK commençait sa transition vers GTK3, et ça allait à nouveau nous causer beaucoup de problèmes, parce que GTK3 ne peut pas être utilisé conjointement avec GTK2, ce qui rend toute tentative de portage vraiment difficile, en particulier avec les plugins binaires utilisant GTK2.
On peut dire que le portage à GTK3, particulièrement difficile pour un navigateur Web comme Firefox qui utilise des widgets GTK natifs (par contraste, Chromium dessine ses propres widgets), absorbe 100 % de l'énergie que Mozilla est capable d'investir dans du travail sur GTK, et en plus de ça, bloque la possibilité de faire participer le reste de la communauté à des efforts d'intégration dans des bureaux libres, car le portage à GTK3 est un prérequis pour ça, et seuls quelques ingénieurs à Mozilla et à Red Hat ont la compétence requise pour y participer. Voir ce bug
Donc d'un côté tu utilises une bibliothèque externe ce qui te permet d'économiser en développement et en maintenance, mais de l'autre tu te plains qu'elle évolue et que migrer prend du temps de développement qui vous est précieux.
Ainsi, si GTK avait entièrement accepté l'idée qu'un toolkit, ça n'est qu'une bibliothèque comme une autre, et donc, qu'en cas de nouvelle version majeure, il faudrait permettre d'utiliser les deux conjointement, l'intégration de Firefox dans les bureaux libres serait probablement plus avancée aujourd'hui.
Tu en profites pour tacler les équipes de développement de GTK, comme si eux avaient des ressources illimitées. S'ils n'ont pas fait cette compatibilité GTK2-GTK3 dans le même binaire, c'est pour les mêmes raisons que vous: pas assez de ressources. L'autre raison étant que dans GTK2, les modifications et les obsolescences de composants se sont faites cycle après cycle. Une application GTK2 qui a été mise à jour au fur et à mesure des obsolescences est directement compatible GTK3 ! Il est aussi à noter que le but était de virer dans GTK3 tous les composants obsolètes de GTK2. Il y a 8 ans de stabilité d'ABI entre les 2 versions ! Au final, tu te plains juste qu'une bibliothèque dont tu dépends… évolue. Bienvenue dans le monde de l'informatique. Tu penses peut être que s'il n'y avait eu qu'un seul toolkit sous Linux il n'y aurait pas eu ce boulot à faire ?
De plus, il est impossible pour moi, de mon point de vue Mozilla, de ne pas y voir une leçon ici : lorsque les développeurs d'un bureau libre déclarent que ceci ou cela est la bonne façon de développer une application pour leur bureau, cette information n'est fiable qu'à court terme et sa validité se repose sur l'idée, non réaliste, que les applications vont pouvoir se re-porter à chaque version majeure suivante. Par exemple, lorsque Firefox est passé à des widgets GTK2 natifs et à Cairo/XRender pour son rendu 2D, c'était considéré comme la bonne façon de faire, mais maintenant ça n'est qu'un handicap face à un concurrent, Chromium, qui ne s'est pas embêté avec ça (dessine ses propres widgets, a sa propre bibliothèque 2D Skia, n'utilise pas d'APIs X11) et s'en porte mieux.
Tu parles de la charge de portage, mais ne prends pas en compte la charge de développement et maintenance de l'équivalent dans Chromium. Ah, et je ne veux pas te gâcher ton week end, mais GTK 4 est dans les cartons, avec sûrement fusion avec Clutter, et pour le coup, ça va faire bien plus de changements que pour la migration GTK2 → GTK3.
Quand je vois sous Windows tout le monde qui réinvente la roue parce que chacun ait sa solution proprio dans son coin, je ne suis pas sûr que ton approche soit la bonne. C'est bien… si tu as du pognon et les compétences pour maintenir ça chez toi. Sinon, tu délègues ! En plus, Google aurait eu du mal à se distinguer en disant ah, bah in utilise les mêmes technos que Firefox, mais on est mieux. Bah non, ça se passe pas comme ça, ça s'appelle la concurrence. Tout comme il y a concurrence entre Qt et GTK. Entre Windows et Linux.
Bref, ça s'appelle le choix.
Pour ça, il faut non pas insister sur un toolkit en particulier, mais au contraire accepter (comme Windows, et comme le Web) l'idée que chacun veut faire les choses à sa façon, et qu'on ne peut rien y changer.
Tu pars du principe que ce serait plus simple que le développeur d'application fasse tout à sa sauce, et pour moi c'est du syndrome NIH. Tu pars du principe que le pari de l'intégration est perdu d'avance, et là je ne suis profondément pas d'accord.
# La bonne blague !
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 10.
Alors pour le coup, je vois plein de commentaires disant "oh oui, comme tu as raison". Et bien ce ne sera pas mon cas, je suis en complet désaccord avec toi.
Et pourquoi ? Parce que pendant des années il était difficile d'avoir une bonne intégration dans un desktop en utilisant des applis de toolkit différents. Ce n'est pas qu'une histoire de thème, mais aussi de design: une appli KDE et GNOME n'ont pas du tout la même tronche, même avec un thème identique. Fût un temps, tu n'avais pas 2 Go de RAM sur un desktop, mais plutôt moins de 512Mo, et utiliser des toolkits différents sur ton système te donnait une pénalité en termes de consommation mémoire. L'utilisateur averti sous Linux avait donc tendance à chercher des applications utilisant le même toolkit, parce qu'elles allaient souvent visuellement mieux ensemble, et en plus sa machine allait plus vite !
Aujourd'hui, GTK ou Qt ont des systèmes de thèmes assez puissants, et c'est surtout le design de l'application qui les distingue. Mais ça, ça dépend du développeur de l'appli, pas du développeur du toolkit.
Tu pense que l'utilisateur Windows sait ce qu'est un toolkit ? Non, il voit juste un truc moche qui ressemble pas au reste, mais il est habitué, depuis le temps. Personne ne proposait mieux, ou il ne savait pas qu'il pouvait avoir mieux ailleurs. Une appli moche sous Windows, on s'y fait si elle marche (ex: VLC). Mais ça reste moche. Comme un salon fait de bric à brac. Il peut être très confortable, il est pourtant moche. Le même aussi confortable et joli, je ne suis pas sûr que les gens n'aiment pas.
C'est le seul point où on est d'accord. Parfois le design de l'application est adapté pour s'intégrer au mieux à l'environnement de bureau, mais dans pas mal de cas c'est une pure copie.
Mais il ne faut pas oublier que GTK est né d'un réel besoin: la licence propriétaire de Qt. Une fois que l'écosystème autour de GTK était créé, et que Qt est devenu libre, que fallait il faire ? Tuer GTK ?
Les thèmes sont là pour ça… Si tu n'as qu'un version utilisant un autre toolkit que ton préféré, bin tu fais comme sous Windows: tu fais avec. C'est la différence entre préférence et exigence.
Le problème ici, c'est les parts de marché. Si Linux avait 20% de parts de marché, et KDE 40% de ceux là, ç'aurait paru bien plus intéressant. Mais doit-on en déduire que forcément tout ce qui se fait sous Linux (qui représente 1% de PDM) n'a aucun intérêt ? 1% c'est déjà pas beaucoup, pourtant Mozilla fournit bien des binaires pour Linux, c'est bien qu'elle y trouve un intérêt, non ? La fragmentation des toolkits, cela ralentit juste la progression vers la masse critique. Mais de la même manière que tu ne peux pas demander aux fabricants de matériel de faire des drivers pour tous les OS, même les plus exotiques, il y a un moment où la communauté doit faire une partie du boulot…
Donc d'un côté tu utilises une bibliothèque externe ce qui te permet d'économiser en développement et en maintenance, mais de l'autre tu te plains qu'elle évolue et que migrer prend du temps de développement qui vous est précieux.
Tu en profites pour tacler les équipes de développement de GTK, comme si eux avaient des ressources illimitées. S'ils n'ont pas fait cette compatibilité GTK2-GTK3 dans le même binaire, c'est pour les mêmes raisons que vous: pas assez de ressources. L'autre raison étant que dans GTK2, les modifications et les obsolescences de composants se sont faites cycle après cycle. Une application GTK2 qui a été mise à jour au fur et à mesure des obsolescences est directement compatible GTK3 ! Il est aussi à noter que le but était de virer dans GTK3 tous les composants obsolètes de GTK2. Il y a 8 ans de stabilité d'ABI entre les 2 versions ! Au final, tu te plains juste qu'une bibliothèque dont tu dépends… évolue. Bienvenue dans le monde de l'informatique. Tu penses peut être que s'il n'y avait eu qu'un seul toolkit sous Linux il n'y aurait pas eu ce boulot à faire ?
Tu parles de la charge de portage, mais ne prends pas en compte la charge de développement et maintenance de l'équivalent dans Chromium. Ah, et je ne veux pas te gâcher ton week end, mais GTK 4 est dans les cartons, avec sûrement fusion avec Clutter, et pour le coup, ça va faire bien plus de changements que pour la migration GTK2 → GTK3.
Quand je vois sous Windows tout le monde qui réinvente la roue parce que chacun ait sa solution proprio dans son coin, je ne suis pas sûr que ton approche soit la bonne. C'est bien… si tu as du pognon et les compétences pour maintenir ça chez toi. Sinon, tu délègues ! En plus, Google aurait eu du mal à se distinguer en disant ah, bah in utilise les mêmes technos que Firefox, mais on est mieux. Bah non, ça se passe pas comme ça, ça s'appelle la concurrence. Tout comme il y a concurrence entre Qt et GTK. Entre Windows et Linux.
Bref, ça s'appelle le choix.
Tu pars du principe que ce serait plus simple que le développeur d'application fasse tout à sa sauce, et pour moi c'est du syndrome NIH. Tu pars du principe que le pari de l'intégration est perdu d'avance, et là je ne suis profondément pas d'accord.