Interview de l'auteur de Sketch : Bernhard Herzog par
I n t e r v i e w

Pour ceux qui ne connaissent pas encore Sketch, il s'agit d'un projet de programme de dessin vectoriel qui offre déjà des fonctionnalités intéressantes à son niveau. Vous trouverez un site complet en Français sur Sketch à cette adresse : http://www.linuxgraphic.org/section2d/sketch/index.html
En plus d'une documentation complète sur ce programme, vous y trouverez également une galerie de "cliparts" directement utilisables.

Linuxgraphic.org:
Bonjour Bernhard, vous êtes l'auteur et le mainteneur de Sketch, un logiciel de dessin vectoriel pour Unix, pouvez-vous nous expliquer pourquoi vous avez choisi de commencer ce projet?

Bernhard Herzog :
La première fois que j'ai pensé à écrire un programme de dessin vectoriel j'étais en train d'écrire ma thèse. J'utilisais la plupart du temps LaTeX sur une station Sun et sur mon petit pc Linux à la maison. J'ai utilisé Xfig pour quelques illustrations, mais je n'en étais pas très satisfait, principalement à cause de son interface utilisateur que je n'ai jamais complètement utilisée et j'ai aussi trouvé l'utilisation des splines difficile (je n'ai jamais réussi à les obtenir dans les formes que je voulais); je voulais aussi avoir des dégradés. J'ai également trouvé Tgif mais même s'il avait une meilleure interface utilisateur, ses possibilités graphiques étaient les mêmes que Xfig.

J'ai pensé que je pouvais faire mieux  et qu'écrire un logiciel de dessin vectoriel serait un projet vraiment très intéressant, mais je n'avais pas vraiment le temps de le faire. C'était évident, pour moi que cela représenterait beaucoup de travail qu'écrire un tel programme.

Au même moment, pendant l'été 1996, j'ai découvert Python et il m'a semblé que ce serait un langage idéal pour un programme de dessin vectoriel. Les langages de programmation orientés objets conviennent naturellement pour les programmes de dessin vectoriels et pour la programmation d'interfaces utilisateurs. La flexibilité de Python serait plus facile que le C ou C++ pour expérimenter différents concepts.
Enfin, cela permettait d'avoir un langage simple à apprendre pour des scripts utilisateurs qui donneraient accès à la totalité de sketch.

Toutefois, je n'étais pas encore certain que Python serait assez rapide et je ne connaissais absolument rien à la programmation sous X. Donc , 1 an plus tard, j'ai commencé à apprendre ce type de programmation avec l'extension X de Python, une interface à Xlib basée sur les widgets de Xt comme Arena et Motif et j'en écrivis une certaine quantité pour la toute première version de sketch. C'était relativement simple et assez rapide même sur un 486 que j'utilisais à ce moment là pour me convaincre que cela pouvait être fait.

Le développement de Sketch continua lentement jusqu'à mi 1997 quand je décidai de concentrer mes développements de logiciels libres sur Sketch; je l'ai porté de l'extension X à Tkinter et j'ai commencé à ajouter davantage de fonctionnalités comme les courbes de béziers et l'intégration des images.

Linuxgraphic.org :
Hé bien, c'est un travail de longue haleine et ardu que vous avez mené ; avez-vous rencontré beaucoup de contributeurs au projet ? Et pourquoi choisir par la suite Tcl/tk pour l'interface ?

Bernhard Herzog :
Je suis toujours le seul développeur au projet, mais parfois je reçois des patchs ou des scripts. Cependant la situation s'est améliorée un peu ces derniers mois. Le nombre de patchs a un peu augmenté et il y a maintenant plusieurs personnes qui semblent sérieuses pour implémenter de nouvelles fonctionnalités dans Sketch. Quoi qu'il en soit, je serais plus heureux si davantage de développeurs rejoignaient le projet.

Pour répondre à la seconde partie de la question, j'ai choisi Tk pour l'interface car c'était la chose la plus délicate à réaliser à ce niveau. Le jeu de gadgets (widget) Athena que j'utilisais avant était très primitif et très difficile à utiliser, tant du point de vue de l'utilisateur que du programmeur. C'était dans une certaine mesure tout à fait compréhensible car ils étaient prévus comme un exemple d'implémentation de widgets basés sur Xt. Cependant, cela ne l'a pas empêché de devenir pendant un moment le gadget par défaut du logiciel libre, car c'était le seul à être libre et largement diffusé.

Sketch en version TCL/TK

C'était clair que je voulais quelque chose de mieux comparé aux autres jeux de gadgets disponibles, et Tk avait beaucoup d'avantages. Les attaches (bindings) Python pour TK sont appelées Tkinter et sont incluses dans la distribution standard de Python ce qui en fait d'office le toolkit d'interface utilisateur pour Python. Tk était aussi très stable et était arrivé à maturité. Le principal inconvénient de Tk était son étroite intégration avec Tcl. Tk inclue un interpréteur Tcl complet, ce qui semble inutile mais offre la façon la plus simple d'interfacer TK.

Gimp était à ce moment là dans la série 0.9.x et GTK en était à ses débuts. Ces bibliothèques m'ont semblé trop instables pour moi, je n'étais pas certain que le crash soit dû au Gimp, à GTK ou plus probablement aux deux. Si ma mémoire est correcte, il n'y avait pas encore d'attaches Python pour ce toolkit.

Donc, je décidais de me concentrer sur Sketch et non sur le débogage du jeu de widgets, et je choisis Tkinter.

Linuxgraphic.org
Donc votre projet a démarré bien avant le Gimp, comment peut-on expliquer que Sketch n'ait pas connu le même engouement auprès des développeurs que le Gimp, bien que Sketch utilise un langage plus souple (Python) et ne pose pas de problème de widget comme nous venons de le voir?

Bernhard Herzog :
Non, le Gimp est plus ancien que Sketch. La première version du Gimp a été disponible au début 1996, 6 mois avant que je commence à écrire Sketch.

Je pense que le manque d'enthousiasme pour Sketch de la part des développeurs est plus précisément dû à l'utilisation de Python et de TK. Pratiquement n'importe quel individu qui écrit des programmes sous Linux, ou des systèmes similaires, a des bases de langage C. Ceci simplifie les choses pour les développeurs qui veulent contribuer à des projets comme le Gimp car la plupart du code est en C. Le nombre de développeurs Python est très faible. La personne qui veut contribuer au développement de Sketch doit d'abord apprendre le langage Python, ce qui veut dire simplement que beaucoup ne désirent pas le faire. Par chance, le langage Python est en train de devenir de plus en plus populaire.

La situation du "toolkit" a aussi beaucoup changé depuis la décision de changer pour TK. Au même moment que je délivrais la première version de Sketch à la fin octobre 1998, GTK était devenu stable et plus avancé que TK. Aujourd'hui TK n'est pas très intéressant pour le développeur.

On peut aussi expliquer ce faible enthousiasme par d'autres raisons, comme une base utilisateur relativement faible. Dans l'ensemble on peut dire que c'est un ensemble de facteurs et non un seul.

Linuxgraphic.org
Aujourd'hui il semble que le développement de Sketch ait pris une nouvelle tournure avec l'utilisation de GTK Python et de la libArt, quels avantages apporte le remplacement de Tk par Gtk, et pourquoi Sketch n'est-il pas intégré au projet Gnome Office?

Bernhard Herzog :
Je suis passé de Tk à GTK pour plusieurs raisons. D'abord GTK offre plus de fonctionnalités que Tk comme les vues en arborescence et les listes à plusieurs colonnes ou, plus particulièrement pour les vues antialiasées,  un gadget (widget) peut afficher n'importe quel tampon RVB (image) sur n'importe quelle vue, tout cela sans que j'ajoute une ligne de code dans Sketch. GTK 2.0 sera aussi très intéressant pour Sketch. En effet, Pango nous permettra d'obtenir très facilement une internationalisation de bonne qualité pour le support du texte (comme pour le Chinois ou l'Arabe) dans Sketch.

Sketch en version GTK

La version GTK de Sketch sera aussi très facile à intégrer au projet Gnome. Gnome offre une infrastructure très pratique, plus particulièrement pour les applications graphiques grâce à gnome-print. Le modèle de Gnome-print est une extension de ce que le Postscript peut faire car il offre, par exemple, le support de la transparence, ce qui est délicat à réaliser pour l'impression Postscript comme Sketch le fait actuellement. J'espère aussi qu'il y aura un peu de coopération entre Sketch et Gimp pour quelques éléments de l'interface, comme la boîte de dialogue de sélection des couleurs par exemple. C'est là que Sketch et Gimp ont des besoins plus avancés que la plupart des applications GTK ou Gnome.

Ensuite, ce sont les utilisateurs qui m'ont poussé à passer sur GTK pour la version 0.8. Quelques utilisateurs m'ont demandé pourquoi j'avais choisi Tk et m'ont suggéré de faire le portage vers GTK.

Pour ce qui est de Gnome Office, je pense que le fait que Sketch ne fasse pas partie du projet est simplement dû à un manque de volonté de ma part. Je ne vois pas de raisons techniques qui priveraient Sketch d'en faire partie. Je pense même que ce serait bien pour Gnome Office et cela aiderait Sketch à être plus connu.

Linuxgraphic.org
Avec la récente annonce du passage à la licence GPL de Staroffice, les sources de StarDraw (composant de dessin vectoriel) seront disponibles et déjà le portage vers GTK/Gnome est annoncé avec le concours de Sun. Peut-on envisager une fusion de Sketch et de Stardraw  ? Sinon, quelles sont les prochaines fonctionnalités que vous prévoyez d'implémenter dans Sketch ?

Bernhard Herzog :
Bien, je pense qu'il est un peu tôt pour spéculer sur l'impact de StarDraw sur Sketch. Toutefois, il y a déjà certaines raisons qui expliquent pourquoi on ne peut envisager une fusion.

Tout d'abord, le mot fusion n'est pas le terme que l'on devrait employer. Etant donné la "dimension" de StarDraw et le fait que c'est Sun qui pousse derrière, toute incorporation de certaines parties de Sketch deviendraient des parties de StarDraw et Sketch ne pourrait plus exister comme un projet à part entière. C'est quelque chose que je ne voudrais pas voir arriver.

Ensuite, il y a certaines raisons techniques. Sketch est écrit, pour la plupart du code, en Python alors que Stardraw est écrit en C++ à ma connaissance. Ce qui signifie qu'il serait possible d'utiliser certaines structures de données d'un programme vers l'autre mais réutiliser du code de l'un vers l'autre serait très difficile.

Quoi qu'il en soit, une fois que le code sera livrée à la communauté, ce sera très intéressant de voir comment l'équipe de StarDraw a résolu certains problèmes de design pour un programme de dessin vectoriel.

En ce qui concerne le développement de Sketch, notre objectif actuel est d'abord de terminer le port vers GTK, étendre le support du texte et éventuellement sortir une version 0.8. Les nouveautés graphiques comme le support de la transparence apparaîtront à partir de la version de développement 0.9.

Linuxgraphic.org
Je suis développeur et je connais un peu Python, cela me sera-t il suffisant pour participer au projet et aider au développement de Sketch ? ou bien, quels sont les pré-requis indispensables pour participer ?

Bernhard Herzog :
Bien, si vous connaissez déjà un peu Python,  l'obstacle le plus difficile à surmonter sera de vous familiariser avec le fonctionnement interne de Sketch.

Le guide du développeur, qui est inclus dans les paquetages sources et RPM contient quelques informations qui vous permettront de démarrer. Par exemple l'organisation du code source, les types de données spécifiques à Sketch et le fonctionnement des plugins y est expliqué. Ce guide du développeur n'est pas pour autant complet, vous devrez donc souvent lire le code source pour en apprendre plus ou bien me le demander directement.

Pour avoir une expérience pratique dans la programmation de Sketch, l'étape suivante serait d'écrire des scripts utilisateurs. Puisque les scripts utilisateurs et Sketch lui-même utilisent Python, ces scripts ont un accès complet à la structure interne de Sketch et utilisent exactement les mêmes objets et interfaces que les composants internes. C'est une façon de commencer à faire de petites choses sans avoir à toucher directement au code interne et ensuite de partir de là vers des développements plus pointus.

Linuxgraphic.org
Cette interview touche à sa fin, pouvons-nous savoir pour quelle entreprise vous travaillez actuellement et si votre travail est en rapport avec le développement d'outils graphiques ? Sketch vous a apporté un plus dans votre vie professionnelle?

Bernhard Herzog :
Je travaille actuellement pour Intevation en Allemagne, une jeune et petite entreprise de consultants et services OpenSource qui est en pleine expansion. Je travaille pour eux depuis le mois d'octobre.

Je ne travaille pas directement sur des outils graphiques, mais une des activités d'Intevation est l'expertise en GIS ( Geographic Information Systems), ce qui a une relation directe avec l'imagerie numérique. Intevation s'occupe entre autres de Free Gis, un ensemble d'outils libres pour GIS. Le premier projet sur lequel j'ai travaillé à Intevation a un rapport avec le GIS, il s'agit d'un simple composant pour serveur web qui permet de tramer les cartes, il s'appellle Maplt.

Oui, mes travaux sur Sketch m'ont beaucoup apporté car j'ai obtenu ce travail grâce à cela. Maintenant je suis payé pour travailler à temps complet sur des projets libres et même si je ne suis pas payé pour travailler sur Sketch , il n'y a aucun problème à utiliser l'équipement de la société ou d'autres ressources pour travailler sur Sketch ou d'autres logiciels libres. Occasionnellement, même mes chefs contribuent à Sketch, comme Bernhard Reiter (membre cofondateur de la FSF Europe) qui a récemment posté un script pour l'exportation d'images sur la liste de diffusion de Sketch.

Linuxgraphic.org
Merci beaucoup Bernhard de nous avoir accordé cette interview, nous vous souhaitons une bonne continuation dans vos travaux.