Sur gimp, le projet a été très têtu pendant tres longtemps sur des choix tres douteux, [...] Idem sur macOS, ou X11 était nécessaire pour le lancer, tout en cassant tous les raccourcis clavier (ctrl vs cmd) a fait beaucoup de mal a la réputation du projet.
Autant sur les fenêtres flottantes tu as peut-être raison, autant là tu fais passer le besoin de X11 sur macOS comme un choix. Et je doute très fortement que ce soit par gaieté de cœur que X11 a été longtemps une dépendance de GIMP sur macOS, avec tous les problèmes que ça implique.
macOS est une plate-forme très hostile à plusieurs égards.
macOS est une plate-forme hostile pour les projets bénévoles car les utilisateurs ne contribuent pas, l’utilisateur est surtout un consommateur c’est à dire qu’il exprime essentiellement des attentes. Il y a une économie sur macOS car il y a une clientèle et il est donc possible de travailler (même à contre cœur) sur macOS si on y a des clients, mais GIMP est un projet bénévole. Qui paie pour GIMP sur macOS, en argent ou en investissement personnel ?
macOS est une plateforme hostile pour les projets libres car les briques libres sont souvent gratuites, ce qui amène le problème du bénévolat précité, ou même quand il y aurait des gens payés à bosser sur telle ou telle brique libre, ils ne sont pas payés pour les porter sur macOS. Par exemple il y a certainement des gens payés pour bosser sur GTK, mais qui paie pour GTK sur macOS, en argent ou en investissement personnel ? Donc par exemple si tel composant de GTK ne marche pas correctement en dehors de X11, cela peut contraindre GIMP à requérir X11.
la masse critique de macOS est trop faible pour y susciter suffisamment de développeurs libristes, à la différence de Windows par exemple (ça plus le fait que la base utilisateur est surtout une population qui exprime principalement des attentes, ça ne laisse plus grande chose).
beaucoup de choses sur macOS sont très spécifiques ou obsolètes.
Je ne participe pas à GIMP, mais je maintiens un autre logiciel cross-plateforme qui partage certaines technologies avec GIMP comme GTK, NetRadiant. En 2022 on utilise encore GTK2. Le logiciel a été porté sur GTK3 mais c’est pas encore 100% fonctionnel même sous Linux, car les ressources en main d’œuvre sont limitées et donc les besoins de production des utilisateurs passent avant, nous rencontrons d’ailleurs des problèmes pour lesquels nous ne savons pas si ce sont des limitations de GTK3 ou de notre façon de faire, et nous ne pouvons pas exclure que ces limitations ne viennent pas de GTK3. J’ai clairement identifié des fonctionnalités qui décrivaient une réponse à notre besoin mais qui ont été supprimées, et je n’ai pas encore trouvé si ça avait été implémenté autrement. Sous macOS, ni GTK3 ni GTK4 ne sont prêts pour nos besoins de toute façon : on utilise OpenGL avec GTK et on partage le contexte entre plusieurs fenêtres. GTK2 ne l’est pas non-plus mais j’ai réussi à ressusciter un vieux patch oublié et à l’entourer d’une montagne de hacks immonde pour que ça marche. Par exemple pour dissimuler un onglet d’arrière plan qui se dessine par erreur sur l’onglet d’avant plan je réduis sa taille à un carré d’un pixel de côté comme ça même s’il est toujours devant mais il cache pas le premier plan, LOL. Ou encore pour réafficher correctement l’onglet courant quand la fenêtre est dé-minimisée je fait en sorte que le logiciel bascule à l’onglet suivant et revient immédiatement à l’onglet courant pour forcer le redessin, re-LOL. Et grâce à ces hacks immonde j’obtiens un NetRadiant qui tourne sans X11. Avant ça... la seule solution c’était GTK2 avec X11 sous macOS. Ce n’était pas un choix.
Je ne connais pas les écueils que rencontre GIMP sous macOS (mes problèmes sont surtout liés à OpenGL et GIMP ne fait pas beaucoup d’OpenGL), mais je n’ai aucune difficulté à imaginer la taille de ces écueils. Je n’ai aucune difficulté à comprendre sans qu’on ai besoin de me donner des détails précis pourquoi GIMP est toujours en GTK2, pourquoi GIMP a longtemps nécessité X11 sur macOS, etc. Je ne connais personne qui ferait ces choix autrement que « si on quitte GTK2 ou si on quitte X11 c’est pire : pour tel projet ça ne s’affiche pas correctement, pour l’autre ça n’est pas utilisable du tout, et pour encore un autre ça ne compile pas du tout.
X11 c’est vraiment pas une bonne solution sur macOS, mais l’alternative est généralement « il n’y a pas d’alternative viable à un coût acceptable ».
Mon expérience du coût de chaque plateforme des projets cross-plateforme auxquels je touche (unité pifométrique pas mentionnée) :
Coût de la spécificité Linux
🮋🮋
Coût de la spécificité Windows
🮋🮋🮋
Coût de la spécificité macOS
🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋
🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋
🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋🮋
Porter un logiciel Linux sur macOS c’est un truc à maintenir seul un fork d’un composant de GTK pour un seul utilisateur déclaré.
La ou libre office était occupé à singer ms office [...] Google s’est pointé ni vu ni connu avec Google docs et a mit la tannée a tout le monde.
C’est tout à fait normal, car LibreOffice répond aux besoins de ceux dont les besoins sont satisfaits par ce genre d’outil (y compris MS Office).
Google docs répond à d’autres besoins.
Google docs est un service.
Pour que LibreOffice ait damé le pion à Google il aurait fallu que les développeurs de LibreOffice considèrent pour eux-même que ces autres besoins étaient prioritaires sur ce que les utilisateurs de LibreOffice attendent de LibreOffice (par exemple le rendu des documents et les fonctionnalités de Google Docs sont toujours très limitées même en 2022), tant de risques pour que des gens se satisfassent que LibreOffice ait doublé Google sur un nouveau produit en délaissant celui pour lequel on les attend pour produire ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Ça n’est pas parce qu’on peut faire quelque chose des outils qu’ils ne sont pas ...
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal PAO, graphisme et colorimétrie dans le libre. Évalué à 10.
Autant sur les fenêtres flottantes tu as peut-être raison, autant là tu fais passer le besoin de X11 sur macOS comme un choix. Et je doute très fortement que ce soit par gaieté de cœur que X11 a été longtemps une dépendance de GIMP sur macOS, avec tous les problèmes que ça implique.
macOS est une plate-forme très hostile à plusieurs égards.
Je ne participe pas à GIMP, mais je maintiens un autre logiciel cross-plateforme qui partage certaines technologies avec GIMP comme GTK, NetRadiant. En 2022 on utilise encore GTK2. Le logiciel a été porté sur GTK3 mais c’est pas encore 100% fonctionnel même sous Linux, car les ressources en main d’œuvre sont limitées et donc les besoins de production des utilisateurs passent avant, nous rencontrons d’ailleurs des problèmes pour lesquels nous ne savons pas si ce sont des limitations de GTK3 ou de notre façon de faire, et nous ne pouvons pas exclure que ces limitations ne viennent pas de GTK3. J’ai clairement identifié des fonctionnalités qui décrivaient une réponse à notre besoin mais qui ont été supprimées, et je n’ai pas encore trouvé si ça avait été implémenté autrement. Sous macOS, ni GTK3 ni GTK4 ne sont prêts pour nos besoins de toute façon : on utilise OpenGL avec GTK et on partage le contexte entre plusieurs fenêtres. GTK2 ne l’est pas non-plus mais j’ai réussi à ressusciter un vieux patch oublié et à l’entourer d’une montagne de hacks immonde pour que ça marche. Par exemple pour dissimuler un onglet d’arrière plan qui se dessine par erreur sur l’onglet d’avant plan je réduis sa taille à un carré d’un pixel de côté comme ça même s’il est toujours devant mais il cache pas le premier plan, LOL. Ou encore pour réafficher correctement l’onglet courant quand la fenêtre est dé-minimisée je fait en sorte que le logiciel bascule à l’onglet suivant et revient immédiatement à l’onglet courant pour forcer le redessin, re-LOL. Et grâce à ces hacks immonde j’obtiens un NetRadiant qui tourne sans X11. Avant ça... la seule solution c’était GTK2 avec X11 sous macOS. Ce n’était pas un choix.
Je ne connais pas les écueils que rencontre GIMP sous macOS (mes problèmes sont surtout liés à OpenGL et GIMP ne fait pas beaucoup d’OpenGL), mais je n’ai aucune difficulté à imaginer la taille de ces écueils. Je n’ai aucune difficulté à comprendre sans qu’on ai besoin de me donner des détails précis pourquoi GIMP est toujours en GTK2, pourquoi GIMP a longtemps nécessité X11 sur macOS, etc. Je ne connais personne qui ferait ces choix autrement que « si on quitte GTK2 ou si on quitte X11 c’est pire : pour tel projet ça ne s’affiche pas correctement, pour l’autre ça n’est pas utilisable du tout, et pour encore un autre ça ne compile pas du tout.
X11 c’est vraiment pas une bonne solution sur macOS, mais l’alternative est généralement « il n’y a pas d’alternative viable à un coût acceptable ».
Mon expérience du coût de chaque plateforme des projets cross-plateforme auxquels je touche (unité pifométrique pas mentionnée) :
Porter un logiciel Linux sur macOS c’est un truc à maintenir seul un fork d’un composant de GTK pour un seul utilisateur déclaré.
C’est tout à fait normal, car LibreOffice répond aux besoins de ceux dont les besoins sont satisfaits par ce genre d’outil (y compris MS Office).
Pour que LibreOffice ait damé le pion à Google il aurait fallu que les développeurs de LibreOffice considèrent pour eux-même que ces autres besoins étaient prioritaires sur ce que les utilisateurs de LibreOffice attendent de LibreOffice (par exemple le rendu des documents et les fonctionnalités de Google Docs sont toujours très limitées même en 2022), tant de risques pour que des gens se satisfassent que LibreOffice ait doublé Google sur un nouveau produit en délaissant celui pour lequel on les attend pour produire ?
ce commentaire est sous licence cc by 4 et précédentes