Bonjour,
Avertissement : que ceux qui n'aiment pas la technique ne lisent pas :-)
AD a écrit :
Le lundi 20 février 2006 à 19:30 +0100, eric.bachard a écrit :
Alors, pour répondre à la question, il n'y a aucune collaboration de la
part de NeoOffice : ils prennent le code d'OpenOffice.org (900 Mo),
ajoutent 10Mo, compilent le tout et cela donne NeoOffice.
Ça n'a pas l'air si compliqué que ça alors,
En fait, si, c'est vraiment très compliqué : nous sommes actuellement
plus d'une dizaine à travailler en équipe, sur le problème, et nous
avons tous beaucoup à faire.
L'illusion vient du fait que Java s'occupe de réaliser des choses très
compliquées, avec un code relativement léger en taille. Comme la
difficulté se paie à un endroit ou à un autre, Java est plus lourd en
runtime (en fonctionnement), à cause de la machine virtuelle qu'il faut
lancer. Ce sont surtout certaines opérations graphiques qui semblent
coûter cher, mais je ne suis pas spécialiste. Pour Carbon/Cocoa, c'est
plus difficile à coder, mais il n'y a pas de machine virtuelle.
> pourquoi ooo n'y est pas
parvenu.
Parvenu à quoi ??
Actuellement, nous utilisons X11, donc nous dessinons du X11. Cela peut
être très sympa, et on peut au passage utiliser les thèmes gtk ou kde.
Pour avoir une vraie apparence (comportement compris) "Aqua" sous Mac OS
X , il faut utiliser l'API Mac OS X. Il a alors plusieurs possibilités,
comme utiliser :
- Java/Cocoa (ce n'est pas la solution retenue),
- Cocoa (trop d'incertitudes à cause des interactions mal controlées
entre les boucles d'événement OpenOffice.org et les boucles d'événements
Cocoa),
- Carbon/Cocoa, notre choix pour une première version native. C'est un
compromis.
Si Java/Cocoa est utilisé, il faut écrire moins de code, et tout semble
facile. Avec Java/Cocoa ... c'est Java qui fait le boulot, rajoutant une
couche entre OpenOffice .org et le système. En effet, pour faire le
travail, Java nécessite une machine virtuelle, donc demande des
ressources en fonctionnement. Cela se paie cash : voir le démarrage, ou
l'affichage de certains menus dans Neo.
Enfin, on ne sait rien sur l'avenir de Java/Cocoa avec Mac OS X.
Si Cocoa est utilisé, le langage utilisé est l'objective C, et cela
demande de modifier en profondeur le framework que constitue
OpenOffice.org : six mois de boulot à plein temps pour plusieurs codeurs
expérimentés, sans compter les bugs introduits dans les autres
architectures => on a vraiment essayé de voir si c'était possible, mais
il faudra plusieurs étapes avant d'y arriver.
Notre choix : Carbon/Cocoa, qui est un compromis entre Java/Cocoa et
Cocoa (obj-C). Ce choix est le résutat de deux mois de réflexions, tout
en étant le plus raisonnable à moyen terme : utiliser Carbon/Cocoa, qui
demande plus de code qu'avec Java, mais est très performant en runtime.
D'ailleurs, MS Office utilise Carbon/Cocoa sous Mac OS X.
IMPORTANT : *Le résultat visuel sera exactement le même* avec
Carbon/Cocoa, qu'avec Cocoa.
Que doit on faire exactement ?
C'est simple et compliqué à la fois : il faut modifier une partie très
importante du module vcl ( vcl c'est ~ 1780 fichiers), avec une
constante : vcl est en sandwich entre deux couches, qui doivent voir
exactement la même chose qu'avant (quand X11 est utilisé) : à la fois du
dessus (les couches graphiques qui demandent quelque chose à vcl), et du
dessous (les échanges entre vcl et le système, à bas niveau).
Un peu comme une paillette de savon, qui à un côté qui aime l'eau, et un
côté qui aime la saleté : on est au milieu.
Le principe de base : on ne souhaite modifier que vcl (et rien d'autre)
Nous avons donc à :
1) analyser complètement le fonctionnement du sal (System Abstraction
Layer ) du module vcl - aucune documentation n'existe - faire la liste
de toutes les classes, méthodes, et analyser leur rôles et interactions
de façon synthétique ..etc
=> Travail en cours (5 étudiants de l'UTBM sont sur le projet)
Quelques chiffres : nous avons passé une semaine à 5 pour analyser du
code, à plein temps, et nous n'avons fait que 40% environ du travail
nécessaire.
2) implémenter progressivement toutes les primitives et la couche
intermédiaire
=> Travail en cours, en parallèle
3) vérifier que les appels du dessous et ceux du dessus sont corrects,
et fonctionnent parfaitement, comme avec la Xlib (c'est à dire X11)
=> Programmé
Dans cette couche intermédiaire que nous avons à construire, si on
utilise Carbon/Cocoa**, c'est Mac OS X qui s'occupe de tout, et ça va
vite : c'est le but recherché.
**si Cocoa était utilisé, ce serait Mac OS X qui s'occuperait de tout,
comme avec Carbon/Cocoa, mais avec du code écrit en objective C, et
quelques avantages supplémentaires en runtime (certains services
dispos). Aucun indice pour dire si ce serait plus ou moins rapide que
Carbon/Cocoa.
Voila, très brièvement, les raisons de notre choix :-)
Pour finir, je souhaite de tout coeur que ce projet aboutisse, afin
d'avoir enfin une vraie appli Mac qui s'appelle OpenOffice.org.
Que ceux qui n'aiment pas voir l'aspect technique acceptent mes excuses,
et désolé pour ceux qui croyaient que c'était facile :-)
Pour les mac users qui lisent, je souhaitent qu'ils aient compris que
c'est d'abord OpenOffice.org qu'il faut soutenir. Les autres projets
dérivés en profiteront de toute façon, car le code source
d'OpenOffice.org est sous licence LGPL.
Mauvaise license, changer license.
Je fais partie du projet OpenOffice.org, et je respecte sa licence, que
j'ai acceptée.
Cordialement,
eric bachard
--
<ericb at openoffice |dot_ org>
Francophone OpenOffice.org Commmunity developer (Linux PPC / Mac OS X /
X11)
See : <http://fr.openoffice.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
