1) Coller le plus possible aux standards. Ils ont fait un grand effort pour le format de fichier (standard Oasis), mais c'est moins standard quand on tombe dans les rouages de la programmation. Par exemple pour communiquer avec OpenOffice, on n'utilise pas des protocoles standard comme CORBA. Il faut passer par un protocole propre � OpenOffice: UNO. De m�me, pour ajouter de nouveaux services � OpenOffice, il faut les d�finir dans un langage qui ressemble � de l'IDL, mais qui n'est pas du vrai IDL. Les d�veloppeurs de OpenOffice disent qu'ils n'ont pas adopt� CORBA parce que les performances n'�taient pas satisfaisantes. D'accord. Mais Gnome a rencontr� le m�me probl�me et ils ont eux aussi invent� leur propre extension de CORBA. Vu la p�n�tration plus grande de Gnome chez les d�veloppeurs, se serait peut-�tre appropri� de rejoindre ce wagon l�. D'accord, la variante Gnome (j'ai oubli� son nom) est venu apr�s OpenOffice, et changer de protocole serait un changement absolument majeur qui aurait des r�percussions profondes dans la totalit� du projet. Je ne sais pas si c'est faisable, mais j'�nonce l'id�e comme un souhait.
2) Etre plus bavard dans les messages d'erreurs qui s'adressent aux d�veloppeurs. J'ai commenc� � �crire la semaine derni�re pour la premi�re fois un plugin pour Calc en Java. J'ai besoin de d�finir une nouvelle interface UNO (d'o� mon exp�rience avec l'IDL saveur exclusive OpenOffice - mon premier r�flexe na�f avait �t� de tenter de compiler mon fichier IDL avec un compilateur plus standard). OpenOffice d�tecte bel et bien mon plugin, mais quand je demande � inspecter l'interface (sans l'ex�cuter), c'est le crash. Je n'ai pas le moindre doute que j'ai d� faire une erreur, mais j'ai pass� deux jours � lire et relire les chapitres appropri�s du "Developper guide", inspecter mes interfaces mot par mot, comparer avec les exemples donn�es dans le guide, fouill� le site d'OpenOffice, r�cup�rer des exemples directement sur le CVS, tester avec OpenOffice 1.1.4 et 2.0 beta, je n'ai pas r�ussi � trouver o� j'ai bien pu faire une connerie et j'ai abandonn� pour l'instant. Un petit message d'erreur au lieu d'un crash, une petite phrase du genre "Can't load registery Foo.rdb", serait �norm�ment appr�ci� (j'avoue, j'ai la d�formation du d�veloppeur Java habitu� � toujours avoir un "stack trace" bien bavard lorsqu'il y a un bug dans mon code). Je ne remet pas en cause la qualit� du code d'OpenOffice, mais il est suffisamment complexe pour qu'il soit pratiquement certain qu'un nouveau d�veloppeur fasse des erreurs. Une plus grande robustesse face aux b�tises de nouveaux arrivants comme moi r�duirait peut-�tre les abandons (m�me si j'esp�re que dans mon cas ce n'est que momentan�).
3) Un site "r�f�rence pour les d�veloppeurs" plus �vident avec un petit lien discret � partir de la page d'acceuil. Il y a bien s�r udk.openoffice.org, mais on est un peu perdu entre les projets udk, uno, api, snippets, etc. Une page centrale qui liste toutes les ressources les plus utilis�es pour les d�veloppeurs serait appr�ci�e, avec au moins list�s bien en �vidence (et non pas enfou� dans des paragraphes d'explications) les liens suivants:
- Guide du d�veloppeur en HTML
- Documentation des interfaces IDL
- Javadoc (et chaque page de la javadoc devrait avoir un lien vers
les interfaces IDL du point pr�c�dent; voir l'option -footer de
javadoc par exemple).- Exemples et snippets.
- "Bug parade" (ou une sorte de "issue tracking" simplifi�). En Java,
la section "bug parade" du site http://java.sun.com a toujours �t�
une source fabuleuse d'informations pour moi chaque fois que je me
suis retrouv� au prise avec un probl�me que la documentation
standard ne r�solvait pas. J'ai eu moins de chance avec le
"Issue tracking" d'OpenOffice jusqu'� maintenant, mais peut-�tre
que je l'utilise mal.- Le CVS d'OpenOffice.
- T�l�chargement du SDK (il a fallu que je fouille dans les archives
de courriels de la liste anglophone pour apprendre qu'un SDK de
la 2.0 beta �tait disponible).Toutes ces informations existes, mais m'ont sembl�es un peu �parpill�es. A l'heure actuelle, la m�thode la plus pratique est souvent de faire une recherche par mot cl�s, et on tombe souvent sur des pages obsol�tes.
4) Un souhait: abandonner CVS et basculer vers SVN � la place. SVN (subversion) a �t� �crit par le m�me auteur que celui qui avait cr�� CVS, et vise � remplacer ce dernier en corrigeant ses faiblesses. Pour avoir connu les deux, je trouve que SVN est un v�ritable plaisir � utiliser comparativement � CVS. Parmis bien d'autres avantages, �a r�glerait entre autres le probl�me des pages obsol�tes mentionn�es aux paragraphe pr�c�dent (lorsque l'on visualise directement le contenu du CVS ou SVN � partir d'un navigateur web), qui ne disparaissent jamais r�ellement avec CVS; elles continuent � �tre retourn�es parfois en premier lorsque l'on fait une recherche par mots cl�s sur le site d'OpenOffice. R�f�rence: http://subversion.tigris.org
Voil� pour ce qui me venait d'abord � l'esprit...
Martin.
P.S.: J'ai mentionn� plus haut un plugin Calc que je tentais de faire. Pour me pr�senter, je suis un contributeur (parmi une quinzaine) du projet open source Geotools. Je souhaitais depuis longtemps faire des ponts vers OpenOffice pour y ajouter des fonctionnalit�s de SIG, � commencer par des formules de projections cartographiques dans Calc (pour commencer par quelque chose de plus facilement abordable). "L'issue" est document� l� depuis un an et demi, mais je commence tout juste � faire des essais: http://jira.codehaus.org/browse/GEOT-25
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
