Je suis entièrement d'accord avec ton analyse. La communication au sujet de la version Mac OS X a été très mauvaise. Il y a beaucoup de choses à reprendre.
Rappel : NeoOffice est un fork GPL, ce n'est pas le projet OpenOffice.org. Tout le code d'OOo est dedans, avec des ajouts dont OOo ne peut même pas profiter (à cause de la licence). Les devs de Neo n'ont qu'à se concentrer sur le principal, puisque c'est à OOo (nous) de corriger les bugs d'OOo. Dans ces conditions, c'est plus facile de se concentrer sur Cocoa.
Si on revient aux priorités (pas toujours très bien comprises), elles étaient les suivantes :
1) faire une version 2 qui soit à la même hauteur que la version Linux ou Windows, ou encore Solaris. L'idée était une sorte de proof of concept : c'est possible.
2) une fois que cette version X11 est stabilisée, alors on peut commencer autre chose. Ça a pris un temps fou, même s'il ne reste actuellement que 3 ou 4 bugs importants à fixer, pas plus. Les grands travaux sont donc pour bientôt (mais n'en demandez pas trop trop vite ).
Au sujet du choix de l'API, il s'impose de lui-même :
- Carbon commence à dater (même s'il continue à rendre de fiers services)
- Java n'est pas la solution
- le futur changement d'architecture : un choix sage impose d'utiliser ce qui colle le plus à l 'OS, Apple se chargeant du reste.
Il restait donc Cocoa, le plus élégant, le plus récent, mais aussi le plus difficile à adapter.
Nos plus gros soucis :
- les parties les plus importantes à réimplémenter sont dans l'essentiel dans vcl. Malheureusement, très peu de doc existe, et il faut tout reprendre
- passer de C++ à Cocoa c'est pas drôle
- pas beaucoup de codeurs, mais ça vient
[^] # Re: on va essayer de ne pas en rester là
Posté par revponpuneq . En réponse au journal Winlibre porté sous mac. Évalué à 2.
Rappel : NeoOffice est un fork GPL, ce n'est pas le projet OpenOffice.org. Tout le code d'OOo est dedans, avec des ajouts dont OOo ne peut même pas profiter (à cause de la licence). Les devs de Neo n'ont qu'à se concentrer sur le principal, puisque c'est à OOo (nous) de corriger les bugs d'OOo. Dans ces conditions, c'est plus facile de se concentrer sur Cocoa.
Si on revient aux priorités (pas toujours très bien comprises), elles étaient les suivantes :
1) faire une version 2 qui soit à la même hauteur que la version Linux ou Windows, ou encore Solaris. L'idée était une sorte de proof of concept : c'est possible.
2) une fois que cette version X11 est stabilisée, alors on peut commencer autre chose. Ça a pris un temps fou, même s'il ne reste actuellement que 3 ou 4 bugs importants à fixer, pas plus. Les grands travaux sont donc pour bientôt (mais n'en demandez pas trop trop vite ).
Au sujet du choix de l'API, il s'impose de lui-même :
- Carbon commence à dater (même s'il continue à rendre de fiers services)
- Java n'est pas la solution
- le futur changement d'architecture : un choix sage impose d'utiliser ce qui colle le plus à l 'OS, Apple se chargeant du reste.
Il restait donc Cocoa, le plus élégant, le plus récent, mais aussi le plus difficile à adapter.
Nos plus gros soucis :
- les parties les plus importantes à réimplémenter sont dans l'essentiel dans vcl. Malheureusement, très peu de doc existe, et il faut tout reprendre
- passer de C++ à Cocoa c'est pas drôle
- pas beaucoup de codeurs, mais ça vient
C'est donc un gros challenge à venir.
--
eric bachard