Le 10 oct. 09 à 17:00, Jean-Baptiste Faure a écrit :
Alors, en tant que développeur, et pour prouver le contraire, et
*ensupposant que c'est faisable*, je propose de lancer le port.
Bonjour Éric et tous,
Bonjour Jean-Baptiste,
Un tel projet me laisse perplexe : je me demande si ce n'est pas
une illustration du piège maintes fois dénoncé de toujours plus de
nouveautés
En fait, il n'est pas question de nouveautés ici : juste arriver à
faire fonctionner quelque chose dans un monde qui n'est pas celui
qu'OpenOffice.org connait. Au passage, c'est assez marrant d'avoir à
expliquer qu'OpenOffice.org n'est pas en Java et que c'est ça qui
pose problème pour le port sur Android (sinon, ça fonctionnerait
tout seul).
AMHA, si quelque chose est possible, ce sera une version très très
light par rapport à ce qui est connu d'OpenOffice.org. Par exemple,
juste un lecteur d'odt et ods, ce serait déjà génial.
qui détourne des ressources vers l'implémentation de ces nouveautés
Encore une fois, il n'y a rien de nouveau à implémenter. Ce n'est
que dans la manière de compiler que beaucoup de choses vont changer.
au détriment de l'amélioration et de la stabilisation de l'existant,
Non plus
correction de bugs dont certains très anciens, nettoyage du code,
interopérabilité.
Je ne pense pas : ce sont des *étudiants* qui vont travailler sur le
sujet: leur confier un vrai problème, en les formant à
OpenOffice.org (via OOo4Kids) ne peut être que motivant pour eux.
Ensuite, le port, dans ce cas, ne va pas consister à ajouter quelque
chose, mais à reprendre ce qui existe, et ariver à le compiler et à
le packager. On verra comment ça fonctionne plus tard :)
Est-ce que le portage sur une plateforme "exotique" peut être
bénéfique pour l'ensemble du projet OpenOffice.org ?
Oui et je vais tenter d'illustrer.
Avoir des étudiants qui travaillent, apporte de la visibilité à
OpenOffice.org, à l'école, à ceux qui font le travail : c'est du
gagnant-gagnant-gagnant (surtout si le projet aboutit sur quelque
chose de positif).
Dégraisser le mammouth, nous force à analyser, et par suite, à
revoir en profondeur chaque application :
- cela valide la portabilité du code (normalement c'est déjà ok)
- cela aide à la modularisation car si nous devons isoler quelque
chose, c'est en essayant qu'on y arrivera
- côté compilation : le SDK c'est quelque chose de nouveau, et on va
se pointer avec quelque chose qui rentre pas dans la boîte -> c'est
aussi quelque chose qui permet de progresser.
- côté performances : je ne vais pas trop parler de ce que j'ai en
tête, mais je peux assurer que cela va aider à vérifier des chose
- factorisation de code, modules superflus .. etc
Mon point de vue est que l'important n'est pas d'avoir
OpenOffice.org sur toutes les plateformes possibles, mais que le
support du format ODF
soit assuré sur toutes les plateformes et que OpenOffice.org soit
le meilleur sur les principaux OS pour PC.
OpenOffice.org fonctionne déjà sur les plateformes ou Android tourne
( x86 et ARM), donc le problème ne se pose pas exactement en termes
de port, sinon, un port qui serait ici "virtuel", puisque sous Java
Bien sûr si Android devient un OS pour PC cela changera la donne,
mais en attendant qu'est que OOo y gagne ?
Une revue de code, un travail en profondeur sur la modularisation,
les performances et la méthode de compilation.
Et comme c'est fait par des étudiants ( == la communauté), on aura
progressé dans l'appropriation du code par des non Sun. C'est pas rien.
Sans doute des développeurs connaissant OOo en profondeur mais
pourront-ils apporter quelque chose à OOo dans son ensemble ?
Oui, vraiment : plus il y a de monde à comprendre, et plus les
améliorations pourront un jour arriver. Tu ne peux pas savoir le
recul que j'ai pris sur le code source d'OpenOffice.org en faisant
OOo4Kids. Juste un exemple : la factorisation de code : entre Draw et
Writer, il y a des tas de similitudes, et un document Draw n'est pas
si différent que ça d'un document Writer quand on y pense. Pareil
pour l'application, dont les arborescences sont très très similaire
par certains aspects. Tout cela est un progrès, vior un passage
obligé.
À l'inverse, si on donne un chèque en blanc, à une équipe
limitée, qui ne fait que ce qu'elle a envie de faire, ou qui
simplement se protège, et on va tomber dans la dépendance. Cela ne
rappelle rien à personne ?
Pour information, je demande toujours que tout soit documenté, en
même temps que le code est écrit (au passage, j'essaye de m'imposer
la même chose chaque fois que j'écris du code)
D'un autre coté pour assurer le support du format ODF sur Android,
peut-être serait-il préférable de porter des applications comme
Abiword
et Gnumeric (mais supporte-t-il vraiment ODF ?) réputées plus
légères.
Curieusement le problème d'Abiword et de Gnumeric est le même que
pour OpenOffice.org : si pas écrit en Java, point de salut. Je
rappelle qu'Android, c'est, de façon assez caricaturale, un micro
noyau Linux + Java pour l'API graphique.
La pression est -me semble-t-il- grande pour Google qui a commencé à
ouvrir les vannes avec le NDK, car il y avait beaucoup de mécontents.
Autre solution OpenGL (je suis un fan de l'écriture d'un canvas
OpenGL pour OpenOffice.org), qui serait pas mal non plus. Mais là, il
y a vraiment plus de boulot.
Voila ce ne sont que mes interrogations.
J'apprécie cette discussion, car je vois que tu t'es osé un peu les
mêmes questions que moi ici (j'était aussi très dubitatif au début).
Bon week end
eric
--
qɔᴉɹə
