eric b a écrit :
Bonjour,
Le 18 mars 07 à 06:29, Jean-Christophe Helary a écrit :
Les messieurs de NO travaillent non pas sur l'amélioration de OOo
mais sur son intégration à Mac.
Le port Mac OS X d'OpenOffice.org travaille aussi sur son intégration
à Mac OS X.
C'est le premier de nos objectifs !!
Simplement, nous avons un choix différent, qui demande un travail
complexe, mais bien plus prometteur à moyen terme : nous utilisons
Carbon ( conseillé par les ingés d'Apple) et maintenant, HIView
qui est une des plus récentes technologies qu'Apple utilise.
il est un peu regrettable que cela cantonne OOo/Aqua aux versions
récentes de MacOS X. Mais bon, il reste la version X11 pour les anciens
systèmes...
P.S. : pour les curieux, HIView , c'est par exemple la "HIComboBox ->
http://eric.bachard.free.fr/mac/aquavcl/screenshots/mars2007/combobox_search_and_replace02_14mars07.jpg
Mais c'est que ça comence à être pas moche... Qustion: la combo box
vide, c'est la faute au bug 73689
<http://www.openoffice.org/issues/show_bug.cgi?id=73689> ?
Par ailleurs, les messieurs de NO sont ceux-là mêmes qui ont créé le
code d'origine pour Mac quand ils travaillaient chez SUN.
Juste les faits :
Il y avait bien plus que deux personnes qui travaillaient sur le
version Mac, mais pas seulement chez Sun, comme les prouve le projet
User Interface, dont je garde précieusement une archive.
Je n'arrive pas à trouver de traces de P. Luby ni d'Ed Peterlin dans
les compte rendus des meetings pour l'implementation NWF (par exemple).
Admettons, ils ont du participer à quelque chose.
Alors, de mémoire, au moins :
- Kevin Hendricks,
- Stephane Shaefer,
- Herbert Duerr (qui a pratiquement tout écrit du layout texte ! ) ,
- Christian Lippka,
- Dan Williams
...et encore deux ou trois autres dont j'ai oublié les noms
travaillaient sur le port Mac OS X à l'époque ont aussi contribué.
Il me semblent que les deux quidams avaient soumis à l'époque quelques
patches mais avaient été découragés par la lenteur de leur intégration
(avant la création des CWS, peut-être?). Ils n'avaient peut-être pas
directement travaillé sur la version Mac OS, d'ailleurs. Et non, je
crois qu'ils n'avaient pas travaillé chez Sun.
ça fait pas mal de monde, en fait, non ?
Dans ces conditions, peut-on croire que le port Mac est dû à deux
personnes *seulement* ?
En utilisant des raccourcis qui ne nécessitent pas le maintien de la
compatibilité multiplate-forme ni l'existence sans Java ni QA, peut-être
pas.
Donc OOo sur Mac aujourd'hui leur doit au moins ça.
Encore les faits :
- Pour la version 2.0, il a fallu 300 patches et à peu près 1 an et
demi pour la stabiliser.
Héhé - je me rappelle des premières versions développeur (vers m56).
Quel souk à l'époque...
- Le projet OpenOfice.org a fait le port Intel tout seul.
Précision: tu parles du port Mac/Intel, là, je pense? Par rapport à la
version PPC sachant que OOo tournait déjà sous x86 avec d'autres OSes,
quelles difficultés y avait-il eu? Simple curiosité.
- idem pour le port Aqua
Par ailleurs, pour le port Intel, NeoOffice a encore utilisé notre
code directement, sans rien contribuer en retour ( y compris les
corrections de bugs, et + encore).
dans l'état des choses, je crois qu'ils font juste passer une cure
d'amaigrissement au code; le développement se focalise essentiellement
sur leur passerelle Java/Cocoa, laquelle est donc inapplicable à OOo. En
tout cas c'était comme ça pour les alpha et beta de NO 2.
La version NeoOffice utilise essentiellement la version.2
d'OpenOffice.org. C'est donc du travail réalisé par le projet
OpenOffice.org qui est utilisé.
Ca, tout le monde et d'accord pour l'affirmer.
Pas moi tout seul, mais tous les contributeurs du port Mac OS X,
depuis maintenant 3 ans.
Et un chouette progrès!
J'insiste : même s'ils ont fait un gros travail, OpenOffice.org est
un process continu, et nous ne devons pas autant que tu le prétends à
P. Luby et Ed Peterlin.
Peut-être juste une idée du but à atteindre et même dépasser? Mine de
rien, avoir une idée d'où on va ça peut servir.
En plus de code qu'ils ont donné à la communauté OOo suite aux
développement de NO.
Quel code ?
D'avance merci pour le(s) lien(s) ... et le code :)
Pas bon, pas bon! Ce serait du code GPL, non réutilisable dans un projet
à license plus ouverte (type LGPL) comme OOo!
Important : Je parle de code utilisable dans la version 2.0, pour
laquelle nous sommes partis de zéro (par exemple pour le bridge Mac
Intel).
Le code donné auquel tu penses peut être venait de la version 1.x et
nous n'avons pas pu l'utiliser dans la version 2.x (nous avons essayé
avec Tino Rachui )
Je me demandais pourquoi ce code était passé à la trappe (il y avait une
version native MacOS pour la 1.x, mais je n'en sais pas plus...) C'était
une version pour OS 9, non?
En plus du menu et tout ça, la différence essentielle entre OOo/Mac
et NO c'est que avec NO on a accès à tous les menus de saisie de
caractères mis à disposition par OSX.
Pour information : Etsushi Kato vient de commiter ( aujourd'hui !! )
le code qui permet de gérer les evénements de type TSM , et la version
Aqua utilise maintenant la plupart des claviers.
Je sais que le français, le tchèque, le Japonais et le Finlandais
fonctionnent déjà, mais nous allons tester avec d'autres très
prochainement.
Ma femme n'a pas de Mac, dommage! Sinon elle aurait pu tester le
chinois... Je n'ai plus de Mac non plus, d'ailleurs...
Par contre, les communautés qui utilisent ces menus (communauté
japonaise entre autres) n'ont pas d'autre choix que de faire la
promotion de NO qui permet d'utiliser OOo sur Mac en japonais sans
avoir de manipulations outrancières à faire avant de pouvoir écrire
la première page.
Et nous le déplorons.
N'oublions pas que nous sommes partis de zéro : aucune documentation
du code, niveau presque zéro en programmation. Depuis, nous avons
parcouru beaucoup de chemin, et l'expertise d'Etsushi Kato va beaucoup
nous servir ici.
En bref, pour revenir à l'objet de cette liste, NO n'est pas utile
aux francophones monolingues qui travaillent sur Mac. NO s'adresse
aujourd'hui essentiellement aux utilisateurs multilingues/monolingues
des communautés laissées pour compte par X11.
Je ne discuterai pas ce point, car l'essentiel est de progresser.
Disons aux utilisateurs de langage écrit non complexe; cyrillique et
romain, ça passe (donc toute l'Amérique, l'Europe, une partie de
l'Afrique et Asie occidentale). Le progrès passe par l'implémentation de
scripts idéogrammatiques (chinois), multi-alphabet (japonais) ou
phonétique (arabe) lesquels requièrent la saisie de plusieurs touches
avant d'insérer un caractère.
Le jour où sera disponible une version stable de OOo/Mac qui
intégrera ces fonctions, l'intérêt immédiat pour NO s'amenuisera,
Nous y travaillons tous les jours. Et désolé si nous ne fournissons
pas encore la version Aqua, car il reste des bugs rédhibitoires pour
un utilisateur de base. Encore merci pour votre patience.
Une bonne nouvelle toutefois :
http://porting.openoffice.org/mac/news/2007/20070203toptenbeforealpha.html
Ce qui signifie : nous avons fait une liste de 10 bugs critiques, et
dès que ceux ci seront corrigés, alors nous ferons une version alpha
prouvant que nous avons bien une version native, sans X11, et qui,
lorsqu'elle sera complète, sera tout simplement une application Mac
comme les autres.
D'ailleurs, si me yeux ne me trompent pas un bug est réglé (calc plante)
et un est fortement amenuisé (rafraîchissement d'éléments de l'écran).
mais il restera toujours le fait que NO est distribué sous la licence
GPL ce qui lui donne un attrait que OOo n'aura jamais, en tout cas
pour certains utilisateurs.
Entre la licence et le JCA ( a jeter) , il y aurait des choses à dire.
En l'occurrence, le problème ici est que du code GPL ne peut pas être
ajouté comme cela à un projet LGPL (restriction au niveau de la
connection de bibliothèques levée dans LGPL) alors que l'inverse est
possible.
Bien sur c'est important de travailler avec les version OOo/Mac
actuelles pour voir ce qui ne va pas, mais on n'a pas tous vocation à
être des testeurs de version béta.
Le version 2.2 qui est en cours de QA a atteint un niveau de stabilité
jamais atteint auparavant.
j'attends celle-là de pied ferme pour linux x86-64 :) - la 2.1.0rc2 est
déjà fantastique.
Même les tests automatisés sont meilleurs.
Et comme elle sert de base pour la version Aqua, c'est plutôt bon
signe non ?
Si je ne m'abuse, cela provient d'un fort travail de modularisation et
nettoyage du code, non? Il me semble que les progrès sont allés en
parallèle pour:
- davantage utiliser des éléments du bureau courant sous Linux et autres OS
- mieux définir les types de données pour la version 64-bit
- davantage séparer les éléments de chaque application (toutes versions)
- rendre l'adjonction d'une nouvelle gestion I/O (ici, Aqua) plus simple
- diminuer la dépendance à Java
Le confort d'une version qui fonctionne c'est aussi important pour la
productivité.
Je suis enfin entièrement d'accord avec toi :-)
Cordialement,
Eric Bachard
Mitch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
