Bonjour,
Très intéressant.
Désolé si c'est un peu "Off Topic", mais j'ai souhaité répondre.
Boudreau Denis a écrit :
Pour les gens qui cherchent un correcteur pour OO.
Jusqu'ici, nous n'avons pas créé d'Antidote sous Linux pour trois raisons :
1. La demande ne justifiait pas le coût.
C'est bien d'utiliser le passé pour présenter ce point : la demande est *là*
Nous n'avions jusqu'à récemment
reçu qu'une quarantaine de demandes. Mais le vent semble tourner.
Le demande peut exploser : les administrations seront très probablement
intéressées.
Et le premier sur le créneau aura un gros avantage. Mais si vous
préférez attendre, c'est votre choix.
2. Ce que doit être un « Antidote pour Linux » n'est pas clair.
- Soit un logiciel qu'on achète, et qui peut être utilisé par des
logiciels libres, parce que le mode d'emploi est fourni, mais de qualité
- Soit une version libre, mais la communauté Linux doit se débrouiller
pour que ça fonctionne
Pourquoi pas :-)
Doit-il
opérer sous X11 ? Sous Gnome ? Sous KDE ? Sous Wine ?
Si je puis me permettre, la confusion est révélatrice d'une
méconnaissance de Linux et ds environnements graphiques utilisés avec :
Gnome et KDE utilisent X11 : tous deux dessinent des fenêtres, et
souvent font plus, mais ils le font obligatoirement en utilisant X11
(via la Xlib) qui s'occupe de gérer la demande d'affichage
(serveur/client graphique).
Une bonne recette pour une appication universelle : utiliser une libc
pas trop vieille ni récente, couplée à la Xlib sous, et tout le monde
pourra en profiter. Y compirs les *BSD ! Si en plus les sources de la
partie graphique sont dispos, alors aucun problème pour l'habiller avec
gtk/kde/ ou autre (motif, tcl/tk ... )
Il existe même des logiciels permettant de créer des applications
graphiques sous Linux, juste par glisser-déposer.
Enfin, il vaut mieux oublier Wine pour émuler un front end :-)
Devons-nous le
compiler
Si les sources sont disponibles, la réponse est non : ce qui ne va pas
dans le code sera très vite corrigé - et amélioré - , et chaque
distribution proposera son propre paquet, comme c'est déjà le cas pour,
bon an mal an ~ plus de 8000 logiciels sous Linux
et le tester pour toutes les distributions ?
Si vous mettez des binaires à disposition, les tests qualité seront très
vite faits.
Un exemple : une version d'OpenOffice.org qui comporte un bug important
demande juste quelques heures pour que le bug remonte. Maximum une
journée. Aucun fournisseur de logiciel, à ma connaissance, ne peut
obtenir ce résultat *à tous les coups*, et en testant un logiciel de
cette taille en interne.
Une des forces du libre est là.
Mais vous pouvez imposer un choix. En choisissant une API pour la partie
graphique, et vous imposerez la libgtk+ (gnome), ou qt (si KDE). Si ce
ne sont pas des versions exotiques, tout ira bien : la compatibilité est
souvent mieux assurée sous Linux que sous Windows. Dernier point : on
peut, depuis très longtemps, utiliser une application gnome sous KDE et
inversement.
Encore plus simple (mais plus lourd aussi) : linker statiquement l'API
de votre choix, et vous fournissez alors tout en même temps :-)
Quels sont les
logiciels avec lesquels nous devrions nous intégrer ?
IMHO, il suffit de définir correctement l'interface entre antidote et le
logiciel hôte ? Aux logiciels désirant utiliser Antidote de s'adapter.
L'important, c'est de fournir des informations de qualité.
Comment pouvons-nous
harnacher cette diversité en un seul binaire ?
C'est à discuter, mais si on calcule rapidement, il faut un binaire par
type de processeur. Et encore : avec x86 , x86_64 et PowerPC, énormément
d'utilisateurs seraient comblés (plus de 95% de façon certaine)
Si de plus la version x86_64 est compilée avec compatibilité 32bits,
alors il ne reste plus que deux binaires à produire.
N'oubliez pas que si vous vendez votre application, il faut bien
investir quelque part...
3. Nous ne sommes pas persuadés, étant donné un certain « esprit de
croisade » pour le logiciel libre qui anime les amateurs de Linux, qu'un
logiciel commercial serait bien reçu.
Cette vision du monde du libre est - désolé - un peu réductrice, et ce
cliché a pris un coup de vieux.
Pour information, et à titre d'exemple significatif, on trouve Linux
dans les grandes écoles (y compris les plus grandes).
Dans ces écoles, certains logiciels commerciaux qui n'ont pas
d'équivalent sous Linux sont achetés et utilisés sous Linux, parce
qu'ils sont la meilleure solution.
Dans la modeste école où je travaille, je pense à un logiciel de
Mathématiques (dont je tairai le nom ici), que nous utilisons sous
Linux, parce qu'il n'y a pas d'équivalent.
Linux est un choix. Linux + des logiciels propriétaires en est un aussi,
et il n'est pas rare (même si je ne souhaite pas qu'il devienne le cas
général).
Nous craignons même que notre
réputation puisse en souffrir.
Absolument pas, et c'est un gage de qualité que d'avoir une meilleure
portabilité.
C'est comme les voyages, plus on en fait plus on s'ouvre aux autres, et
les idées neuves viennent souvent d'ailleurs.
(En aucun cas, le prix d'une version Linux
ne pourrait être moindre que celui pour Mac et Windows; en fait, nous les
distribuerions toutes sur le même cédérom.)
Si vous avez déjà pensé à cela, alors vous avez déjà pas mal réfléchi au
problème :-)
D'aucuns pourraient croire que la version Mac OS X, très proche d'Unix,
devrait pouvoir se porter sur Linux sans trop de difficulté.
Sans avoir vu les sources, on ne peut rien dire. Quelle est la taille du
code source d'Antidote ?
Ce n'est
malheureusement pas le cas.
Il faut voir le code...
La difficulté réside dans l'interface
personne-machine, d'une part, qu'il faut réécrire au grand complet,
Oui, mais si je comprends bien, ce n'est qu'un front end ? C'est
relativement facile à faire sour Linux.
sauf
possiblement en partant de la version Windows et en utilisant Wine.
Pourquoi faire quelque chose de si compliqué ? Cela va nuire au produit
si c'est plantogène, ou lent ou que sais-je ?
Elle
réside aussi dans l'interaction entre applications; sur Windows, nous
utilisons OLE et DDE;
OpenOffice.org sait gérer ce type d'objets
sous Mac, nous utilisons AppleScript et Apple Events;
Si vous utilisez Applescript ou AppleEvents ( que je connais un peu),
alors c'est normalement portable sous Linux.
Mais à mon humble avis, un port utilisant python serait encore plus
pertinent: la portabilité est immense, c'est stable, fiable, et
forcément bien écrit.
aucune de ces technologies n'existe sous Linux, et il faudra donc tout récrire.
Encore un point qui mérite un discussion
Ainsi, nous sommes parfaitement ouverts au principe d'un port à Linux,
pourvu que les circonstances techniques et financières y soient favorables.
Elles le sont : ce produit n'existe pas encore, et votre produit est de
qualité.
Cela n'a pas été le cas jusqu'ici, mais des interventions comme la vôtre
pourraient faire basculer l'équation.
Merci d'ajouter ma contribution du bon côté :-)
Nous vous remercions de votre commentaire et de votre intérêt, tant pour
Antidote que pour Linux. Nous accueillerons avec plaisir tout autre élément
d'information que vous jugerez utile d'ajouter au dossier.
Juste pour finir, et parce que c'est uin point important ; vous avez
peut-être sous évalué le potentiel apporté par une version Linux de
votre produit.
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]
