Un grand merci Jehan pour ta réponse très détaillée. Cela correspond bien à l'idée que je m'en faisais, mais c'est super d'avoir le point de vue des premiers concernés !
Mais hormis cela, oui bien sûr que c'est prévu à terme. Cela reste une dette technique de rester sur une version qui n'évolue plus.
C'est bien le point que je voulais soulever. Et d'après ta réponse, cela va relever une fois de plus du parcours du combattant.
À long-terme, cette tendance à la simplification de GTK, quelles qu'en soient les raisons (considérations ergonomiques, simplification du code à des fins de maintenance) et qu'on les considère bonnes ou mauvaises, est une bombe à retardement pour les applications de bureau complexes telles que GIMP.
Non seulement cela alourdi considérablement la charge de travail des développeurs d'applications pour toutes les raisons que tu cites, mais cela va inéluctablement conduire à une plus grande fragmentation du code et à une moindre intégration de ces applications avec l'environnement de bureau. En effet, les applications seront forcées de ré-implémenter chacune à leur manière ces mêmes fonctionnalités, sans aucune garantie d'homogénéité entre elles (e.g. rendu visuel, navigation au clavier, etc.). Cela ne fera qu'impacter l'expérience des utilisateurs, ce qui est un comble pour GNOME GTK.
De telles discussions existent-elles avec les mainteneurs de GTK ? Renault soulève qu'ils sont probablement peu nombreux, mais en considérant tout le travail fourni par les développeurs d'applications pour recréer ces fonctionnalités, il est vraiment dommage que cela ne puisse pas être mutualisé en amont.
Par exemple, avec GTK4, on perd les menus. Ils ont décidé que les menus à l'ancienne étaient peu utilisés (seulement tous les logiciels majeurs que j'utilise ont des menus! Faut croire que c'était pas assez! 🙄) et trop compliqué. À la place, ils conseillent maintenant d'utiliser des menus popover (le fameux menu hamburger quoi). Puisqu'on n'est pas d'accord, ça veut dire qu'on va devoir réimplementer les barres de menu et tous les autres composants de telles interfaces, les intéractions, etc.
[...]
Déjà qu'ils ont décidé de retirer les tooltips (info-bulles) sur les éléments de menu dans GTK+3 parce qu'ils considèrent que ce n'est pas une bonne idée. Pour ça aussi, j'ai du faire pas mal de code additionnel pour faire notre propre code de génération de menu.
[...]
Le second autre gros point noir qui va demander beaucoup de travail est la disparition de GtkTreeView.
Pour répondre à Renault, au delà de la simplification du code, il y a probablement des considérations ergonomiques derrière ces disparitions, à commencer par la démocratisation des écrans tactiles. Cependant, il semble à l'heure actuelle illusoire d'envisager une utilisation productive de logiciels aussi complexes que GIMP autrement qu'à la souris et au clavier.
Pour reprendre mon point précédent, dans l'idéal, GTK pourrait continuer à offrir ces fonctionnalités. Prenons l'exemple du menu burger, cela pourrait être le comportement par défaut lorsque l'on installe GIMP et il contiendrait l'ensemble des menus de premier niveau (ce qui évidemment nécessite un clic supplémentaire à chaque fois que l'on accède au menu). Et ce même widget pourrait également afficher le menu au format horizontal et de manière permanente, ce qui serait disponible via un paramètre dans les préférences.
Évidemment, cela nécessite que l'ensemble des fonctionnalités du menu de GIMP soient implémentées dans GTK (case à cocher, boutons radio, icônes personnalisées, etc.). Mais une fois encore, il serait dommage que le travail fourni par les développeurs d'applications ne puisse pas être mutualisé.
On fait un logiciel de création graphique, pas une démo technique d'un toolkit graphique. Et passer du temps à changer d'infra juste pour changer d'infra n'est pas la partie marrante (ni ce qu'attendent la plupart des gens qui créent avec GIMP), pour au final passer surtout du temps à réparer les régressions, les nouveaux bugs...
La situation est probablement bien plus complexe que je ne la décris ci-dessus. Et comme tu le dis si bien, dans l'idéal les développeurs d'applications devraient pouvoir se concentrer sur les fonctionnalités de leur logiciel et non sur le toolkit. Mais cela ne semble pas être le cas à l'heure actuelle. Je trouve juste vraiment dommage que l'on se retrouve dans cette situation qui, au final, ne profite à personne.
On a sorti 20 versions stables (2.10.0 à 2.10.40), soit à peu près 3 par an, à chaque fois avec de nouvelles fonctionnalités en pagaille
Tout à fait ! Il suffit d'ailleurs de suivre les dépêches que tu publies régulièrement sur le sujet et que je lis toujours avec autant de plaisir, à défaut d'utiliser toutes les fonctionnalités en question. J'espère que mon message ne laissait pas entendre le contraire :)
[^] # Re: GTK 4
Posté par Yarma22 . En réponse à la dépêche GIMP 3.0 RC1 est sorti. Évalué à 3.
Un grand merci Jehan pour ta réponse très détaillée. Cela correspond bien à l'idée que je m'en faisais, mais c'est super d'avoir le point de vue des premiers concernés !
C'est bien le point que je voulais soulever. Et d'après ta réponse, cela va relever une fois de plus du parcours du combattant.
À long-terme, cette tendance à la simplification de GTK, quelles qu'en soient les raisons (considérations ergonomiques, simplification du code à des fins de maintenance) et qu'on les considère bonnes ou mauvaises, est une bombe à retardement pour les applications de bureau complexes telles que GIMP.
Non seulement cela alourdi considérablement la charge de travail des développeurs d'applications pour toutes les raisons que tu cites, mais cela va inéluctablement conduire à une plus grande fragmentation du code et à une moindre intégration de ces applications avec l'environnement de bureau. En effet, les applications seront forcées de ré-implémenter chacune à leur manière ces mêmes fonctionnalités, sans aucune garantie d'homogénéité entre elles (e.g. rendu visuel, navigation au clavier, etc.). Cela ne fera qu'impacter l'expérience des utilisateurs, ce qui est un comble pour GNOME GTK.
De telles discussions existent-elles avec les mainteneurs de GTK ? Renault soulève qu'ils sont probablement peu nombreux, mais en considérant tout le travail fourni par les développeurs d'applications pour recréer ces fonctionnalités, il est vraiment dommage que cela ne puisse pas être mutualisé en amont.
Pour répondre à Renault, au delà de la simplification du code, il y a probablement des considérations ergonomiques derrière ces disparitions, à commencer par la démocratisation des écrans tactiles. Cependant, il semble à l'heure actuelle illusoire d'envisager une utilisation productive de logiciels aussi complexes que GIMP autrement qu'à la souris et au clavier.
Pour reprendre mon point précédent, dans l'idéal, GTK pourrait continuer à offrir ces fonctionnalités. Prenons l'exemple du menu burger, cela pourrait être le comportement par défaut lorsque l'on installe GIMP et il contiendrait l'ensemble des menus de premier niveau (ce qui évidemment nécessite un clic supplémentaire à chaque fois que l'on accède au menu). Et ce même widget pourrait également afficher le menu au format horizontal et de manière permanente, ce qui serait disponible via un paramètre dans les préférences.
Évidemment, cela nécessite que l'ensemble des fonctionnalités du menu de GIMP soient implémentées dans GTK (case à cocher, boutons radio, icônes personnalisées, etc.). Mais une fois encore, il serait dommage que le travail fourni par les développeurs d'applications ne puisse pas être mutualisé.
La situation est probablement bien plus complexe que je ne la décris ci-dessus. Et comme tu le dis si bien, dans l'idéal les développeurs d'applications devraient pouvoir se concentrer sur les fonctionnalités de leur logiciel et non sur le toolkit. Mais cela ne semble pas être le cas à l'heure actuelle. Je trouve juste vraiment dommage que l'on se retrouve dans cette situation qui, au final, ne profite à personne.
Tout à fait ! Il suffit d'ailleurs de suivre les dépêches que tu publies régulièrement sur le sujet et que je lis toujours avec autant de plaisir, à défaut d'utiliser toutes les fonctionnalités en question. J'espère que mon message ne laissait pas entendre le contraire :)