Gimp.org

Compte-rendu du GimpCon 2006 (Conférence des développeurs de Gimp)

La Conférence des développeurs de GIMP 2006 (The GIMP Developers Conference 2006) s'est tenue lors du Libre Graphics Meeting à Lyon, France, les 17, 18 et 19 mars.

Les développeurs de Gimp

À propos de la conférence développeurs GIMP

La conférence développeurs GIMP, également connue sous l'abréviation GIMPCon est une réunion de développeurs internationaux de GIMP et de GEGL. C'est une chance essentielle pour les développeurs de GIMP de rencontrer les autres et de discuter des directions que vont prendre le logiciel dans les prochaines années.

Il y a déjà eu quatre conférences GIMP auparavant : deux à Berlin, en Allemagne accueillie par le CCC (the Chaos Computer Club), une à Kristiansand, en Norvège lors du GUADEC 2004 et une à Stuttgart, en Allemagne lors du GUADEC 2005.

Minutes de la conférence développeur GIMP 2006

Lors du LGM, il y a eu deux session dédiée à GIMP, une le samedi après-midi (16h30-18h00) et une le dimanche (10h30-16h00). Les points suivants étaient au programme :

Discussions et présentations au GIMPCon 2006

GIMP 2.4

SIOX

Gerald a expliqué le statut actuel de SIOX et ses développements futurs :

Nouveaux outils

Google's Summer of Code

Dave a mis en avant que le « Summer of Code » arrive prochainement et que des idées sont requisent. GIMP est un des projets qui peut proposer des des tâches. Les idées et les taches devront bientôt être présentées, probablement vers début mai.

Préparation pour la sortie de la version 2.4

Michael a mis en avant que certains termes de l'interface utilisateur que GIMP utilise orientent vers une mauvaise piste et sont vraiment différents des autres logiciels de manipulation d'image. Par exemple l'utilisation de « dpi » à la place de « ppi ».

Michael a proposé une PDB pour l'outil texte (Texttool PDB) ainsi que de nouvelles fonctionnalités : styles multiple sur une seule ligne de texte et plus de contrôle sur le texte. Malheureusement, GIMP ne supporte pas toutes les fonctionnalités de Pango actuellement. Les problèmes de ligatures sont parfois rencontrés avec la police « Bitstream Vera Sans ».

Il a également été question de différents autres problèmes : la gestion de l'annulation dans les opérations vectorielles, les améliorations vers le mode plein écran (différents greffons ne peuvent afficher les barres de progression), etc.

A faire

Documentation

Le manuel comporte actuellement neuf langues, dont cinq sont maintenues activement. Le russe et le norvégien vont être ajoutés après la version 0.10. DocBook/XML est une barrière pour les nouveaux contributeurs, mais il n'y a pas d'alternative viable actuellement.

Pour la création des PDF nous devrions utiliser dblatex à la place du projet abandonnée db2latex.

Plus un fichier XML comporte de traductions, plus il est difficile pour les contributeurs de se concentrer sur leur contenu. Peut-être devrions nous découper le contenu par répertoire plutot que de concentrer toutes les langues dans un même fichier.

Michael a suggéré une méthode pour que les utilisateurs puissent commenter les pages HTML comme la documentation de PHP. Les problèmes sont les suivants: que vont devenir les commentaires après la mise à jour de la documentation, comment et qui va gérer le contenu, quel système va convenir à nos besoins ?

A faire

GIMP 2.99

GEGL

Pippin a montré que GEGL ne supporte pas encore le calcul sur des régions d'intérêt. Une partie du code ne gère que 8-bits par couleur, mais l'implémentation du tampon de référence sera en 32bit flottant / pixel. Yosh a proposé de générer de le code nécessaire depuis un patron (template).

Pippin: GEGL est mort-vivant.

Mitch a suggéré que l'intégration de GEGL devrait se faire par petits pas. L'API des greffons sera totalement GEGL, mais va fournir des compatibilités ascendantes pour les anciens greffons 8bits.

Les problèmes d'ergonomie et d'utilisation sont également dûs au mode de couleurs indexées. Nous en avons conclus qu'il devrait être disponible si les utilisateurs exportent leurs images dans un format indexé comme GIF ou PCX. Pour certaines images indexées, l'ordre des couleurs dans la palette est important. Raphaël a proposé de gérer ces images au travers de GEGL comme des images 16bits avec les 8bits les moins significatifs représentant l'index de palette original. Cela permettrait de le restaurer ultérieurement à la sauvegarde. Gerald a mentionné qu'il est possible qu'Apple utilise déjà une méthode similaire.

A faire

Comment motiver des gens à rejoindre le développement de GIMP ?

La page de projet actuelle de gimp.org n'est pas vraiment structurée et il n'est pas vraiment facile de prendre contact avec les développeurs. Elle pourrait aider à montrer aux contributeurs potentiels une liste de tâches que les développeurs de GIMP considèrent comme facile et utile pour la version suivante. Nous pourrions également utiliser cette liste de tâche pour le Google Summer of Code, pour les bounties, etc.

Nous devrions nous assurer que les lecteurs des listes de diffusion de GIMP se sentent bien accueillis lorsqu'ils les lisent. Nous devrions par exemple éviter de critiquer ceux qui mentionnent GimpShop ou des programmes commerciaux comme Photoshop.

Il y a eu des discussions autour de différentes suggestions comme l'ajout de l'ancienneté dans la liste des auteurs de GIMP. Le dialogue « À propos » devrait afficher en premier les contributeurs de la version actuelle et une liste plus longue avec celle des contributeurs plus anciens. Sven et Yosh ont remarqué que nous n'utilisons pas vraiment la liste de diffusion pour discuter du développement de GIMP. La majorité des discussions se passent sur IRC ou directement entre les personnes. Cela pourrait être amélioré. Il y a également eu débat sur la façon d'éviter les discussions sans intérêt sur la liste de diffusion gimp-web.

A faire

Vision de GIMP

Peter Sikking nous a aidé à trouver une vision produit pour GIMP. Cette vision aide à définir quelle est l'installation standard de GIMP : Quels greffons sont standards et lesquels sont optionnels. Cela ne doit pas être une simple analyse « coût et bénéfices » de ce que signifie le support d'une fonctionnalité. Le problème courant de la vision produit est quelle est trop étendue pour être pratique. Peter propose que notre vision produit doit concorder avec une sorte de courbe de Gauss des utilisateurs pour lesquels GIMP est adapté. Nous avons actuellement des experts et des débutants, mais peu d'intermédiaires.

Les bons réglages par défaut devraient être choisis selon notre vision et non pas en inventant de nouveaux scénarios pour chaque chose que nous voulons évaluer. Les scénarios de l'utilisateur devraient être écrits à l'avance. Ces scénarios ne pourront pas être changés après coup car ils conduiraient vers trop de débats. Le but est de couper court aux discussions. La vision produit sert de filtre. Par exemple : Si quelqu'un arrive en demandant que l'interface de GIMP devrait être identique à celle de Photoshop, nous pourrions simplement répondre : « Nous ne tentons pas d'être comme Photoshop, nous avons une différente vision produit ». Malgré tout, cette demande de fonctionnalité doit toujours être examinée attentivement.

Base d'utilisateurs visés

GIMP vise des utilisateurs expérimentés. Si nous reconnaissons que GIMP n'est pas (en premier lieu) pour les débutants, nous supprimons de nombreux problèmes comme « Devons nous supporter ça » etc. Peter à noté qu'une « Lumière GIMP » ne doit pas seulement supprimer quelques options des menus : Il doit avoir une interface utilisateur réellement différente, même si le code sous-jasant est identique.

Certains développeurs travaillent à GIMP pour promouvoir le mouvement du Logiciel Libre et ne contribueraient probablement pas si GIMP n'était pas libre. D'autres pensent que GIMP devrait fournir un certain plaisir à ses développeurs, bien que notre base d'utilisateurs dont le but est de faire des expériences amusantes a énormément grossit. Nous avons à reconnaître que nous nous adressons à une base d'utilisateur qui pourrait être plus expérimentée en manipulation d'image que nous le sommes, les développeurs sont donc partiellement en dehors du groupe cible.

Avant de converger vers une définition des groupes cibles de GIMP et de la vision de GIMP, il y avait plusieurs discussions invoquant des exemples ou des cas d'utilisations, il est possible que GIMP doive être le meilleur programme de manipulation d'image de l'univers (meilleur pour qui ?), il est également possible que ceux travaillant sur les icônes ou ceux travaillant sur les photos aient les mêmes besoins (de nombreuses images à ouvrir, tailles relatives) ou bien il est possible que les gens aient besoin de passer fréquemment de GIMP à d'autres applications (navigateur ou éditeur pour le travail web), il est également possible que nous supportions la peinture d'après des formes ou des médias naturels, etc. Une vision de GIMP a émergé....

Qu'est-ce qu'est GIMP

Qu'est que n'est pas GIMP

A faire

Minutes écrit par Roman Joost et Raphaël Quinet.

Photos de Jean + Karine Delvare et Raphaël Quinet.

Traduction approximative en français par Olivier Gondouin.