Pour Gnucap, je ne dirait pas "mort cérébrale" mais plutot un développement "lent" et plutot bizzare: Pas de CVS mais un gros tarball qui tombe de temps en temps (le dernier date de novembre), plusieur site qui ne sont pas à jours ( http://www.geda.seul.org/tools/gnucap/ ) est correct, mais ( http://www.gnu.org/software/gnucap/ ) ne sert à rien.
Mon rêve serai un simulateur sous forme d'une lib. Comme ca on pourrai avoir un front-end en ligne de commande, ou l'intégration dans un soft graphique, en ayant la même base pour tout le monde.
Moi, quand j'ai touché de de l'ergonomie (pour l'automobile), on regardait les problèmes suivants deux axes
- Facilité d'apepprentissage
- Facilité d'utilisation
C'est fou ce qu'on gagne en compréhension du problème quand on distingue les deux notions (emacs est peut-être facile à utiliser, mais l'apprentissage est coton)
Il y a une théorie qui explique l'extInction massive du permien par un rechauffement des eaux qui a déclanché un dégazage massif de methane (encore pire que le CO² pour l'éffet de serre), qui a fait une retroaction possitive mortel pour 90% des espèces vivantes.
Pour éclairé ton propos, j'ai signé un NDA (dans un domaine non informatique) avec deux types de dates.
Une durée pendant laquel on s'échange des informations (2 ans)
Quand le NDA s'arrête, on n'a plus accés aux nouvelles informations/mise a jour.
Parcontre, les informations échangées précédamment reste confidentielles pendant une durée de 10ans.
Pour moi, OpenDocument est une promesse de pouvoir utiliser de façon transparante l'application de mon choix tout en travaillant en collaboration.
Or, je vois deux failles dans cette approche.
1: Il me semble bien que OpenDocument permet d'utiliser des champs « propriétaires » spécifiques à une application (foreing elements chaptitre 1.5).
Supposons que ce format devienne obligatoire ou imposé pour des réponses à appel d'offre.
Or supposons qu'un éditeur ce veux pas de cette compatibilité (il cherche à verrouiller l'utilisation de son logiciel que ses super marketeux sont arrivé a vendre comme des petits pains).
Mais cette éditeur souhaite quand même obtenir le label « OpenDocument » pour pouvoir le vendre à des société qui l'exige.
Il peut utiliser un format 100% Valide en OpenDocument en utilisant de façon intensive des champs « propriétaires » quitte à utiliser ses champs même pour des propriété triviaux qu'il aurait pu décrire en utilisant des champs de la norme (genre mettre le texte dans un « foreing element » mais codé en rot13). Les autres softs ne pourront pas le lire car ils ne pourront pas interpréter correctement des propriétés indispensables.
De plus, il peut même décrédibiliser openOffice et consort en se permettant de lire leurs fichiers alors qu'eux ne peuvent pas (</mauvaise fois on>quelle bouse ce oo, il ne peut même pas lire ce fichier openDocument valide alors que mon magicOffice y arrive sans problème <mauvaise fois off>)
2: Je ne vois comment traiter correctement l'écart de fonctionnalité entre les soft (même entre des soft qui « jouent le jeux »)
OpenDocument est un format intégrant le maximum de fonctionnalité. Chaque suite bureautique n'utilise qu'une partie de celle-ci. Mais si la suite A utilise une propriété qui à un impact sur le fichier, rien n'assure que la suite B saura l'interpréter correctement. Et si cette propriété m'est indispensable pour la bonne compréhension du document, j'ai un problème. Prenons par exemple une transition dans une diapositive qui me permet de faire apparaître un élément graphique de manière particulièrement éclairante pour ma présentation. Je créé mon document sous Oo. Je l'envoie à mon client. Il le lit sous KOffice et n'y comprend rien.
Je ne peut donc pas envoyer un document (même si c'est OpenDocument) à une personne en étant sur qu'il puisse tout lire, le modifier et me le renvoyer sans problème.
En conclusion :
Si mes peurs sont justifiées, je vais être déçus. Bien que cela soit une grande avancée dans l'interopérabilité, pour moi, cela ne permet pas d'avoir un document d'échange éditable sans soucis. Et je pense que cela à été sur-vendu et que la déception qui pourrai en suivre serai très dommageable.
[^] # Re: Spice
Posté par sharko . En réponse à la dépêche KTechlab 0.3 et Qucs 0.0.8. Évalué à 2.
Mon rêve serai un simulateur sous forme d'une lib. Comme ca on pourrai avoir un front-end en ligne de commande, ou l'intégration dans un soft graphique, en ayant la même base pour tout le monde.
[^] # Re: Anglicisme
Posté par sharko . En réponse à la dépêche Publication de KDE 3.5. Évalué à 2.
- Facilité d'apepprentissage
- Facilité d'utilisation
C'est fou ce qu'on gagne en compréhension du problème quand on distingue les deux notions (emacs est peut-être facile à utiliser, mais l'apprentissage est coton)
[^] # Re: et les hydrates de gaz...
Posté par sharko . En réponse au journal Quelles alternatives au pétrole ?. Évalué à 2.
[^] # Re: Pas que les voitures...
Posté par sharko . En réponse au journal Quelles alternatives au pétrole ?. Évalué à 2.
France = 500 000 km²
2% = 10 000 km²
50 000 000 habitant (je sais, c'est plus mais c'est plus simple)
Soit 200m² par personne.
sachant que dans mon petit immeuble on est 16 et qu'il a environ 200m² de toit, qui me prête les 3000m² de toit pour completer.
[^] # Re: Zeppelin-nt : pas une solution...
Posté par sharko . En réponse au journal Quelles alternatives au pétrole ?. Évalué à 1.
[^] # Re: Mesdames et messieurs, il *peut* le faire !
Posté par sharko . En réponse à la dépêche Un émetteur TNT avec un simple PC : c'est possible !. Évalué à 1.
[^] # Re: le développeur originel...
Posté par sharko . En réponse à la dépêche Nouveau rebondissement dans l'affaire du pilote PWC. Évalué à 8.
Une durée pendant laquel on s'échange des informations (2 ans)
Quand le NDA s'arrête, on n'a plus accés aux nouvelles informations/mise a jour.
Parcontre, les informations échangées précédamment reste confidentielles pendant une durée de 10ans.
# Est-ce suffisant pour une bonne interopérabilité
Posté par sharko . En réponse à la dépêche Enfin une norme pour la bureautique : OpenDocument 1.0. Évalué à 10.
Or, je vois deux failles dans cette approche.
1: Il me semble bien que OpenDocument permet d'utiliser des champs « propriétaires » spécifiques à une application (foreing elements chaptitre 1.5).
Supposons que ce format devienne obligatoire ou imposé pour des réponses à appel d'offre.
Or supposons qu'un éditeur ce veux pas de cette compatibilité (il cherche à verrouiller l'utilisation de son logiciel que ses super marketeux sont arrivé a vendre comme des petits pains).
Mais cette éditeur souhaite quand même obtenir le label « OpenDocument » pour pouvoir le vendre à des société qui l'exige.
Il peut utiliser un format 100% Valide en OpenDocument en utilisant de façon intensive des champs « propriétaires » quitte à utiliser ses champs même pour des propriété triviaux qu'il aurait pu décrire en utilisant des champs de la norme (genre mettre le texte dans un « foreing element » mais codé en rot13). Les autres softs ne pourront pas le lire car ils ne pourront pas interpréter correctement des propriétés indispensables.
De plus, il peut même décrédibiliser openOffice et consort en se permettant de lire leurs fichiers alors qu'eux ne peuvent pas (</mauvaise fois on>quelle bouse ce oo, il ne peut même pas lire ce fichier openDocument valide alors que mon magicOffice y arrive sans problème <mauvaise fois off>)
2: Je ne vois comment traiter correctement l'écart de fonctionnalité entre les soft (même entre des soft qui « jouent le jeux »)
OpenDocument est un format intégrant le maximum de fonctionnalité. Chaque suite bureautique n'utilise qu'une partie de celle-ci. Mais si la suite A utilise une propriété qui à un impact sur le fichier, rien n'assure que la suite B saura l'interpréter correctement. Et si cette propriété m'est indispensable pour la bonne compréhension du document, j'ai un problème. Prenons par exemple une transition dans une diapositive qui me permet de faire apparaître un élément graphique de manière particulièrement éclairante pour ma présentation. Je créé mon document sous Oo. Je l'envoie à mon client. Il le lit sous KOffice et n'y comprend rien.
Je ne peut donc pas envoyer un document (même si c'est OpenDocument) à une personne en étant sur qu'il puisse tout lire, le modifier et me le renvoyer sans problème.
En conclusion :
Si mes peurs sont justifiées, je vais être déçus. Bien que cela soit une grande avancée dans l'interopérabilité, pour moi, cela ne permet pas d'avoir un document d'échange éditable sans soucis. Et je pense que cela à été sur-vendu et que la déception qui pourrai en suivre serai très dommageable.
__
Je me suis laché pour mon premier post