ah tiens j'ai oublie de dire qu'il y a un magnifique bug d'affichage entre compiz fusion et la barre linuxfr. Si je scroll vers le bas la page j'ai un "ghost" de la barre linuxfr qui apparait comme une trainee dessus. Cela disparait en faisant bouger (et donc redessiner) la fenetre...
il y a different plugin qui ne marcheront pas sous compiz comme sous beryl tant que l'on ne passera pas a xorg 7.3. C'est pour une raison de gestion des entrees/sorties "propre" si j'ai bien compris le forum.
Beryl n'etait pas forcement "mal code" mais il contournait de facon non esthetiquement et technologiquement crades pour des puristes des limitations de xorg.
De mon cote je ne peux pas trop dire que compiz marche mieux ou moins mal que beryl, je suis passe du driver ati au driver libre et j'ai plus l'impression que le probleme se situe la. En gros, le driver libre pour une X600 semble passe par mesa pour tout ce qui est 3D enfin je vois pas d'autre explication pour la montee en chaleur du CPU des que j'utilise des trucs OpenGL. Exemple avec un jeu couillon en 3D je peux facilement atteindre les 90 degres celsius niveau CPU si je fait pas gaffe et cela en moins de 10 minutes... Le probleme est bien au niveau des drivers car sous windows le meme jeu ne fait quasiement pas chauffer le CPU...
J'attend avec impatience le xorg 7.3 en priant qu'il y ait vraiment eu des ameliorations pour ma carte graphique, du coup je pourrais re-essayer les ureaux 3D...
Actuellement dans les formats sans pertes pour la photo tu as le raw souvent non documentes et absolument pas standard. Chaque constructeur faisant sa propre sauce. Certes il y a l'initiative openraw mais bon vu la bonne volonte de Nikon, Canon et consort...
Peut etre que un vrai standard, si il est bien fait, documente et surtout libre (ce que je ne sais pas avec le HD) serait franchement bien.
100% d'accord sur la partie que les bureaux devraient pouvoir se changer sans tout redefinir. L'exemple le plus flagrant sont les mails et les messageries instantanees.
Les mails il faut redefenir a chaque fois les caracteristiques si tu veux tester un nouveau mailer, pire tu dois transferer tes mails dans tel ou tel format et tel ou tel place. Thunderbird mets ses mails dans .mozilla/thunderbird/1323mweq1231/Mail/... tandis que kmail les mets dans .kde/share/apps/kmail/mail/....
c'est absolument pas pratique de passer de l'un a l'autre et pire il y a des risques de pertes dans ce genre de cas du coup meme si un de ces mailer (ou encore un autre) devient nettement mieux et a des killers features, l'utilisateur restera sur l'ancien a cause de ca.
que thunderbird disparaissent bientot. Je dois avouer que firefox c'est sympa mais quel dommage de se limiter a cela de la part de la Mozilla fundation. Enfin c'est un choix strategique.
De tout de facon les mailers tant qu'une methode commune de conservation/gestion des mails n'existera pas ce sera toujours le meme merdier et les utilisateurs resteront bloque sur celui qu'ils utilisent actuellement a moins d'etre force, comme dans le cas d'un arret du developpement, de changer. Cela devient lourd de copier tous ses anciens mails dans un nouvel endroit du disque dur (dans les cas ou il existe un moyen de migration) et si jamais on est pas satisfait du mailer que l'on essaye et que l'on a pris les reglages par defaut d'un compte pop, les mails ne sont plus sur le serveurs...
Autrement le livre est bien fait, clair et avec pas mal de photo ce qui aide les debutants de facon enormes.
Ben oui c'est bien connu, les votes refletent la majorite. Personne ne penserait que seule une minorite vocale, qui ne comprend d'ailleurs pas que ces votes sont pour pertinent/pas pertinent et pas pour "je suis d'accord avec lui" vote.
Euh comment dire... non rien franchement c'est trop gros.
Lorsque tu depasses les bornes de la mauvaise foi je ne te consideres plus vraiment comme un interlocuteur decent. T'es libre de rester decent et je le resterait alors aussi.
Et ne pas etre d'accord avec toi et les pratiques commerciales de ta boite c'est etre indecent! Je vois je vois si je disais ce a quoi cela me fait penser ce genre de chose je risquerai probablement d'etre pret d'un point godwin... Le jour ou dans un pays la liberte d'expression n'est plus permise et est considere comme indecente, on appelle ca une dictacture.
Tu reves peut etre aussi, en plus tenter de m'humilier en public, de me foutre en prison pour delit de mauvaise pense?
Quoiqu'il en soit la tu prouves chaque jour de plus en plus a quel point tu es malpoli, mal eduque, vulgaire, et pretentieux.
Ca me fait bien marrer tout ca, parce que j'ai clairement demontre qu'ODF, accepte ISO, avait le meme genre de problemes, et la il n'y a personne qui se plaint hein, et personne qui pense qu'ODF est un probleme.
Euh comment dire... Je me cite (seulement deux exemples j'ai la flemme de tous les sortir):
la seule defense que tu as trouve c'est dire que ODF fait la meme chose. Ce qui, si c'est vrai, est totalement aussi stupide.
Micorosft openxml ayant ete cree apres ODF ils auraient pu au moins eviter de faire les memes erreurs en plus que la norme ODF, ce qui aurait ete un bon point pour vous mais visiblement meme ca n'est pas le cas et vous avez repeter les memes betises.
Sur les 3-4000 personnes qui ont un compte, sur les dizaines qui ont poste sur cet article, il y a 3-4 personnes qui sont obstinees, et tu arrives a appeler ca "tous", tu me fais bien rire.
Je dirais que vu les notes que toi et donc LA personne qui est d'accord avec toi c'est plutot moi qui ris doucement... la majorite ne semble pas etre totalement en accord avec tes idees et surtout ta "demonstration" (a ce propos la on attend encore un argument technique recevable, tu te defiles encore sur le sujet).
ni meme de te convaincre, mon but est de montrer aux gens qui lisent tes posts qu'il y a un autre point de vue.
Et donc tu utilises les insultes et les insinuations comment dire desagreables pour faire avancer ton point de vue. C'est une facon de faire certes mais cela ne respecte en rien ni la netiquette que ce soit dans la forme ou l'esprit ni les formes de politesses minimales entre 2 individus.
Contrairement a ce que tu dis j'ai surement plus de respect pour ta boite que tu ne le crois mais comme des que quelqu'un dit un truc qui ne correspond pas a la l'image que se donne ta boite, tu commences a sauter dessus et a insulter, et depuis quelque temps c'est de facon systematique, tu as reussi a creer intolerants. Il n'y a aucune retenu et tout ce qui sors de chez micorosoft devrait etre encenser d'apres toi sans qu'aucune critique ne puissent s'y appliquer. Par contre tous ce que fais les autres il faut bien le descendre et pointer les faiblesses.
Pour en revenir au sujet, microsoft openxml, il y a des problemes dedans divers et varies (tu as pas trop ramene ton point de vue sur les erreurs dans les formules statistiques d'ailleurs). Des problemes sur une version 1.0 c'est normal et ca prouve juste que le fast track est une aberration totale d'un point de vue technique. D'un point de vue de domination sur les formats et d'un point de vu portefeuille de microsoft naturellement que c'est normal .
1) tu me montres qui te soutiens dans ta soit disant reponse. Il n'y a personne d'accord avec ton "explication"
2) je suis visiblement pas le seul cretin/idiot etc present sur ce site car nous te posons tous la meme question simple:
"Donne une justification technique autre que mon voisin fait la meme chose"
C'est pas une question complique et pourtant tu es strictement incapable d'y repondre. Un certain nombre de personne, dont moi, ont montre, explique avec des mots simples que le travail en question doit se faire uniquement dans le filtre. Un concept bien compris s'enonce simplement c'est tout.
Tu peux continuer a m'insulter et a tenter de m'ecraser. Tu ne m'impressionnes pas plus pour autant et je dois dire que je suis assez content de ce fil de discussion car, pour moi et pour un certains nombre d'autre personne, tu as bien demontre tes limites techniques (ce qui n'est pas du tout une honte en soit enfin pour de mon point de vue). Tu remarqueras aussi que contrairement a toi je ne fait aucune allusion (meme subtile) sur ton intelligence et ton QI et que dans tous ce fil, encore une fois contrairement a toi, je n'ai pas employe une seule insulte. J'ai juste donne donne mes arguments sans aucune attaque personnelle.
ouhais enfin moi j'aimerai bien que les mailers soient compatible entre eux pour la ou ils stockent les mails et la facon de les stocker. Pour le moment ils font tous un truc different
thunderbird dans un truc comme:
.mozilla/thunderbird/87dsfsf313.default/Mail
ou un truc du style
pendant ce temps kmail (et donc kontact) met tous ses petits dans:
.kde/share/apps/kmail/mail
je soupconne que c'est encore un truc different pour evolution.
Et la je ne parle que de la ou les mails sont stocke mais chaque soft utilise sont format.
Au moment ou l'on se bat pour avoir un format commun pour les suites offices, il serait temps de faire la meme chose pour les mailers. Que cela serait bien si l'on pouvait ouvrir ses mails avec kmail, evolution, thunderbird etc sans faire des copies, transformation etc.
En gros on est sous kde on ouvre avec kmail et si l'on veut se servir/tester un autre mailer tel que evolution ou thunderbird cela marcherai en sauvergardant les mails de la meme facon au meme endroit et kmail pourrait, a l'ouverture suivante les voirs sans problemes.
kontact il y a du boulot a faire derriere pour que ce soit reelement utilisable. C'est celui que j'utilise mais bon c'est pas la panacee.
La gestion des contacts en particulier les listes est, a mon avis, complexe et non ergonomique, kmail marche pas mal a partir du moment ou l'on ne met pas de filtres anti-spam car la ca rame a mort a chque reception de mail (probleme recurrent et soit disant regle a chaque nouvelle version...) etc
Il a aussi ses bons cotes tout de meme, sinon je ne l'utiliserai pas (meme si c'est vrai que la difficulte voir l'impossibilite d'utiliser differents mailers est une des raisons pour lesquels j'utilise kontact).
Le fait de pouvoir lancer chaque composant independemment est un atout certains surtout lors du travail sur batterie. Le fait que basket soit integre dedans est un atout formidable, les journaux, les notes etc au meme endroit c'est cool. Il manque a mon avis tout de meme l'integration de kplato pour la gestion des projets.
Enfin comme l'essentiel du boulot sur les applis kde se fait pour passer a kde4, je comprend parfaitement qu'il ya d'autre priorite actuellement et je pense que la situation s'ameliorera nettement l'annee prochaine.
on se demande pourquoi tu viens troller ici si nous sommes tous des idiots incompetents et dans ce fil tu as d'ailleurs bien montre ton ouverture d'esprit ainsi que ta bonne foi et ton honnete...
On attend toujours une reponse autre que "ODF fait pareil"...
Bon dernier post dans ce fil qui est devenu inutile.
En resume tu n'as pas reussi a convaincre une personne d'une obligation technique de mettre des balises de compatibilite. On peut meme dire que tu as reussi exactement l'inverse et la seule defense que tu as trouve c'est dire que ODF fait la meme chose. Ce qui, si c'est vrai, est totalement aussi stupide.
Je sais bien que par rapport a toi nous sommes des idiots et des incapables et que nous ne comprenons strictement rien a l'informatique, la programmation et la logique. Il est tout de meme excessivement dommage que tu n'es pas reussi a t'abaisser a notre niveau pour expliquer de facon clair et simple ce genre de chose.
La conclusion c'est que toutes les personnes ayant lu precisement ce fil de discussion sont arrive a la meme conclusion et que c'est sale la facon de faire de microsoft openxml ainsi que ODf si tu dis vrai. Au passage peux tu donner le nom de la balise en question. Il se trouve que j'ai des fichier de openffice.org <2 et que je voudrais verifier tes dires.
donc les commentaires de quelqu'un lie par contrat avec IBM rende son expertise nul et non avenue?
C'est bien ce que je pensais sur la boite qui preside le commite pour la normalisation en France de microsoft openxml. Merci de nous dire que la partialite dans ce cas influence le resultat.
meme pas vu les reponses de pbpg plus haut, ce sont les anciennes versions de MS office qui lors de l'ouverture d'un pure microsoft openxml vont rajouter les balises de compatibilite et le meme soft qui va le sauvegarder avec ces memes balises.
voir sa reponse qui dit bien que si MS office 2000 ne sauve pas dans le format microsoft openxml avec les balises en question, il est incapables de relire un pure document openxml. Pour le reste des softs (koffice, openoffice.org, lotus note etc) ces balises ne servent strictement a rien (enfin d'arpres ce que dit pbpg). La conclusion immediate c'est que le filtre de MS office 2000 est incomplet et incapable de lire un pur document microsoft openxml, ce qui mets a mal la soit disant retro-compatibilite...
va donc lire les commentaires du pdf dont le lien est fourni.
Ca me rassure je suis loin d'etre le seul a trouver les trucs de soit disant compatibilite totalement aberrant d'un point de vue interoperabilite et technique.
par rapport au balises inutiles je te suggere de lire l'echanges (pour une fois courtois) que j'ai avec pbpg sur le sujet. Tu pourras remarquer que je n'ai toujours aucune reponse a une question simple:
Quel est la raison technique de mettre des balises de compatibilite dans le format microsoft openxml?
La seul reponse "technique" de pbpg sur le sujet dit tout et son contraire et un peu analyse montre justement l'inutilite de ce genre de balise. Voir pire cela complexifie pour rien un format deja trop verbeux.
Les soit disant notions de retro compatibilite doivent venir par la publication des formats binaires doc qui permettra de faire de vrais filtres pour chaque version du format doc. Cela ne doit pas passer par l'ajout de balises sales et inutiles, et non documnetes, dans le format dit normalise.
Je suis probablement un peu idiot mais tant que je n'aurai pas une reponse clair sur le sujet je considererai ce format comme mal fait.
Que je sache la question pose concernait microsoft openxml, si ODF fait le meme genre de truc deguelasse j'ose esperer que cela va etre corriger dans la/les prochaines revisions du format.
Tu ne reponds pas a ma question: quel est la justification technique de la chose. Demontre moi que le raisonnement que j'ai dans le message juste au dessus est absude.
C'est pas parceque quelqu'un fait une betise que l'on est oblige de l'imiter. Perso c'est pas parceque je vois quelqu'un rouler a 200km/h en ville que je vais faire la meme chose. Micorosft openxml ayant ete cree apres ODF ils auraient pu au moins eviter de faire les memes erreurs en plus que la norme ODF, ce qui aurait ete un bon point pour vous mais visiblement meme ca n'est pas le cas et vous avez repeter les memes betises.
Donc arrete de me dire: "Mais le voisin il fait la meme chose" et explique moi ou demontre moi que mon raisonnement est debile.
Pour le moment la seul impression que j'ai de tes reponses c'est que tu essayes de noyer le poisson mais que tu n'arrives pas a trouver un vraie justification technique a ce genre de salete inutile.
Et la on parle que de balises de format, je peux rajouter la meme chose sur le bug des dates. Donne moi une seule vrai justification a garder cela dans le format.
Pour le moment j'ai plus le sentiment et j'ai l'impression de ne pas etre le seul que tu demontres plutot que soit le format est en lui-meme incomplet, soit les filtres d'ouverture/sauvegarde sont mal fait.
je dois franchement etre debile mais ta demonstration ne me convinct toujours pas. J'arrive pas a comprendre que le filtre d'ouverture de word 2000 ie qui transforme microsoft openxml dans le format doc de l'epoque word 2000 ait besoin d'avoir dans le fichier microsoft openxml des indications de comment faire l'affichage.
Le format doit, en theorie, donner assez d'information pour l'ouvrir et l'afficher dans MS office 12 et cela sans aucun rajout de balises historiques immondes euh historiques (enfin d'apres ce que tu dis). Ca veut donc dire que le format doit contenir les infos necessaires et suffisantes au formatage. Lorsque tu l'ouvres sous MS office 2000 le filtre d'ouverture doit, et lui seul doit faire cela, transformer les elements de formatage de microsoft openxml dans les elements de formatage MS office 2000. De la meme facon le filtre de sauvegarde doit, et la encore lui seul, transformer les elements de formatage de MS office 2000 en microsoft openXML. Si c'est pas le cas c'est que soit microsoft openxml n'est pas suffisant pour decrire la structure d'un document office soit les filtres sont mal fait et ne sont pas complet.
Je ne vois toujours aucun argument technique pour ce genre d'ajout et encore une fois les balises en question ne sont comprehensible QUE par les outils microsoft vu qu'ils n'ont pas ete defini et decrit nul part. Enfin tout ca c'est peut etre pour vous garder le monopole de la "traduction" du format doc au format microsoft openxml... Enfin vu la reussite flagrante des suites microsoft office dans ce domaine c'est pas gagne d'avoir un rendu equivalent sur vos differents softs. Tu vas me dire vos commerciaux etant super bon ils ariveront bien a le vendre comme ca!
Quand tu sauves un document avec Word 2000 de doc a openxml, lui il sait et il met la balise.
Donc nous sommes bien d'accord que le format microsoft openXML a ete fait par et uniquement pour microsoft vu que personne d'autre n'a les valeurs en question des differents bits. De plus si j'etait mechant je dirais que meme chez microsoft ils ont pas les valeurs en questions vu les differents de rendu entre versions de MS office et entre plateformes.
Quand tu re-ouvres ce meme document dans Word 2000, lui il sait comment interpreter ce parametre et il le fait.
Seul petit truc que tu ne mentionnes pas c'est que Word 2000 ne travaille pas en microsoft openXML et du coup pour le comprendre il fau un filtre et donc encore une fois pourquoi ne pas mettre le parametre dans le filtre?
Tout a fait, je t'invites a relire ce que j'ai ecris, tu finiras par comprendre le pourquoi.
Je te cite:
Et quand tu ouvres ce meme document dans l'ancien soft, ce soft sait quoi faire avec ce parametre et l'utilise.
puis deux lignes plus tard:
C'est pourquoi aucun nouveau soft ne va creer de fichier avec ces parametres, ils sont la histoire que les anciens softs puissent les utiliser quand ils convertissent de l'ancien format au nouveau
Tu dis un truc et son contraire. Soit c'est l'ancien soft qui lit les balises mises par le novueau soft soit c'est lui qui les ecrits mais si c'est pour que l'anciens softs les lisent et les ecrivent cela ne sert a strictement rien du tout.
Parce que quand tu les ouvres dans le nouveau logiciel, vu que ces elements ne sont pas clairement documentes ils pourraient etre elimines tout en permettant d'acceder au contenu sans probleme.
Si tu ne connais pas le format initial, ce qui est le cas des formats doc puisque que ce format n'est pas officiellement documente, tu ne peux pas creer la balise XML en question dite de compatibilite dans la sauvegarde dans le nouveau format.
Encore une fois on revient au probleme de l'ouverture de l'ancien format par le filtre. Ce qui n'a strictement rien avoir avec la sauvegarde dans un nouveau format. Nouveau format de tout de facon non lisible directement dans les anciennes versions du programme sans passer par un filtre!
Si tu ne sais pas que les trucs binaires XXX doivent faire un espacement de 2 pts, tu n'as aucun moyen de creer la balise XML le disant.
Le fait de pouvoir ouvrir le nouveau format dans un ancien soft (MS office < 12 ou > 2000) ne peut passer encore que part un filtre et encore une fois c'est au filtre de transformer la nouvelle description dans un mode lisible et affichable par ces suites offices la.
A moins que le nouveau format, sans les trucs de compatibilite, ne soit pas complet et ne permette pas de decrire un document office globalement et doivent absolument se servir de ce genre de balise mais la il n'est plus questions de compatibilite...
C'est pourquoi aucun nouveau soft ne va creer de fichier avec ces parametres, ils sont la histoire que les anciens softs puissent les utiliser quand ils convertissent de l'ancien format au nouveau.
Ca c'est le boulot du filtre encore une fois.
Enfin je vois aussi que ma reponse n'est pas claire mais en relisant ton message je m'apercoit aussi que c'est normal car une fois tu dis que ces trucs de compatibilite c'est fait pour que l'ouverture par les anciens softs se fassent correctement puis apres tu dis que ce sont les anciens softs qui vont sauvegarder avec ces balises particulieres... Donc je dirais que ton message precedent n'a pas ete bien relu et que il y a une profonde incoherence dedans. Donc en conclusion je ne vois toujours aucune raison technique a ces trucs de compatibilite.
il faudra vraiment m'expliquer avec des mots simple le pourquoi technique de la compatibilite de openXML avec des formats anciens.
Franchement j'arrive pas a comprendre mais c'est parceque je suis idiot je sais, pourquoi garder dans un format de sauvegarde des choses specifiques a des vieux format.
Les anciens formats, dont il n'y a aucune documentation officiel, sont ouvert par le logiciel en utilisant un certain filtre qui permet de les ouvrir et presenter correctement dans le logiciel. La sauvegarde dans un autre format tel que microsoft openxml devrait (et c'est ce que fait OOo avec les anciens formats MS d'ailleurs) les auvegarder en se debarassant des problemes et historicite des anciens format.
Lorsque un auteur traduit de l'anglais au francais il ne garde pas la moitie de la grammaire anglaise, ou l amoitie de la structure des phrases ou la moitie des mots de la version anglaise. Alors pourquoi le faire pour un nouveau format de document.
Si je rate un truc et qu'il existe de vrai raison technique explique les moi et sans te foutre de ma gueule s'il te plait.
100% d'accord avec ta derniere phrase. Tout le foin fait autour des angles et de la justification (ou pas) de definir une unite et juste la pour faire oublier les "legeres" erreurs de calculs (a cause d'une definition fausse) des fonctions statistque (entre autre).
En gros, ceux qui insistent sur le sujet pour dire que la definition est bonne, utilise une tactique bien connu des lobbysite:
En l'occurence, ils ont malgre tout totalement tord sur le sujet et un angle doit avoir une unite defini par defaut et une option pour la preciser au besoin dans un logiciel destine a etre utilise par monsieur tout le monde et donc surtout pas des mathematiciens.
tu cherches quoi? A demontrer que tu melanges beaucoup de chose?
Alors je vais t'expliquer:
Un exemple n'est pas une definition ni une norme par contre un exemple doit valider la definition et la norme.
L'exemple que tu cites ne prouves strictement rien. La norme aurait pu definir proprement les fonctions trigonometriques de la facon suivante:
sin(angle, unit=XXXX) avec XXXX = radian, degre ou gradient, le defaut etant les radians.
du coup l'exemple fourni fonctionne mais n'est pas la definition en soit.
Enfin visiblement les concepts d'unites physiques sont des concepts qui soit ne sont pas ton fort, soit tu ne veux pas en entendre parler soit tu joues a l'idiot pour defendre une lacune du format (je penche pour le dernier).
C'est assez incroyable comme les defenseurs de microsoft openxml sont ouvert a la critique. Plutot de dire: "En effet, il y a un manque a cet endroit" et le corriger. Ils preferent attaquer en racontant des enormites sur l'utilite de l'utilisation des unites physiques...
C'est assez rigolo. Pas tres constructif de votre part mais rigolo!
[^] # Re: Cette fusion : une réelle amélioration ?
Posté par abramov_MS . En réponse à la dépêche Compiz Core 0.5.2. Évalué à 2.
[^] # Re: Cette fusion : une réelle amélioration ?
Posté par abramov_MS . En réponse à la dépêche Compiz Core 0.5.2. Évalué à 3.
[^] # Re: Cette fusion : une réelle amélioration ?
Posté par abramov_MS . En réponse à la dépêche Compiz Core 0.5.2. Évalué à 6.
Beryl n'etait pas forcement "mal code" mais il contournait de facon non esthetiquement et technologiquement crades pour des puristes des limitations de xorg.
De mon cote je ne peux pas trop dire que compiz marche mieux ou moins mal que beryl, je suis passe du driver ati au driver libre et j'ai plus l'impression que le probleme se situe la. En gros, le driver libre pour une X600 semble passe par mesa pour tout ce qui est 3D enfin je vois pas d'autre explication pour la montee en chaleur du CPU des que j'utilise des trucs OpenGL. Exemple avec un jeu couillon en 3D je peux facilement atteindre les 90 degres celsius niveau CPU si je fait pas gaffe et cela en moins de 10 minutes... Le probleme est bien au niveau des drivers car sous windows le meme jeu ne fait quasiement pas chauffer le CPU...
J'attend avec impatience le xorg 7.3 en priant qu'il y ait vraiment eu des ameliorations pour ma carte graphique, du coup je pourrais re-essayer les ureaux 3D...
# ca peut etre une bonne idee
Posté par abramov_MS . En réponse au journal "Le format HD Photo de Microsoft étudié par JPEG". Évalué à 2.
Peut etre que un vrai standard, si il est bien fait, documente et surtout libre (ce que je ne sais pas avec le HD) serait franchement bien.
[^] # Re: intéropérabilité?
Posté par abramov_MS . En réponse à la dépêche Empathy : l'avenir de la messagerie instantanée dans GNOME. Évalué à 7.
Les mails il faut redefenir a chaque fois les caracteristiques si tu veux tester un nouveau mailer, pire tu dois transferer tes mails dans tel ou tel format et tel ou tel place. Thunderbird mets ses mails dans .mozilla/thunderbird/1323mweq1231/Mail/... tandis que kmail les mets dans .kde/share/apps/kmail/mail/....
c'est absolument pas pratique de passer de l'un a l'autre et pire il y a des risques de pertes dans ce genre de cas du coup meme si un de ces mailer (ou encore un autre) devient nettement mieux et a des killers features, l'utilisateur restera sur l'ancien a cause de ca.
# dommage...
Posté par abramov_MS . En réponse à la dépêche Framabook sort un livre sur Thunderbird 2. Évalué à 1.
De tout de facon les mailers tant qu'une methode commune de conservation/gestion des mails n'existera pas ce sera toujours le meme merdier et les utilisateurs resteront bloque sur celui qu'ils utilisent actuellement a moins d'etre force, comme dans le cas d'un arret du developpement, de changer. Cela devient lourd de copier tous ses anciens mails dans un nouvel endroit du disque dur (dans les cas ou il existe un moyen de migration) et si jamais on est pas satisfait du mailer que l'on essaye et que l'on a pris les reglages par defaut d'un compte pop, les mails ne sont plus sur le serveurs...
Autrement le livre est bien fait, clair et avec pas mal de photo ce qui aide les debutants de facon enormes.
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 2.
Euh comment dire... non rien franchement c'est trop gros.
Lorsque tu depasses les bornes de la mauvaise foi je ne te consideres plus vraiment comme un interlocuteur decent. T'es libre de rester decent et je le resterait alors aussi.
Et ne pas etre d'accord avec toi et les pratiques commerciales de ta boite c'est etre indecent! Je vois je vois si je disais ce a quoi cela me fait penser ce genre de chose je risquerai probablement d'etre pret d'un point godwin... Le jour ou dans un pays la liberte d'expression n'est plus permise et est considere comme indecente, on appelle ca une dictacture.
Tu reves peut etre aussi, en plus tenter de m'humilier en public, de me foutre en prison pour delit de mauvaise pense?
Quoiqu'il en soit la tu prouves chaque jour de plus en plus a quel point tu es malpoli, mal eduque, vulgaire, et pretentieux.
Ca me fait bien marrer tout ca, parce que j'ai clairement demontre qu'ODF, accepte ISO, avait le meme genre de problemes, et la il n'y a personne qui se plaint hein, et personne qui pense qu'ODF est un probleme.
Euh comment dire... Je me cite (seulement deux exemples j'ai la flemme de tous les sortir):
la seule defense que tu as trouve c'est dire que ODF fait la meme chose. Ce qui, si c'est vrai, est totalement aussi stupide.
Micorosft openxml ayant ete cree apres ODF ils auraient pu au moins eviter de faire les memes erreurs en plus que la norme ODF, ce qui aurait ete un bon point pour vous mais visiblement meme ca n'est pas le cas et vous avez repeter les memes betises.
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 3.
Je dirais que vu les notes que toi et donc LA personne qui est d'accord avec toi c'est plutot moi qui ris doucement... la majorite ne semble pas etre totalement en accord avec tes idees et surtout ta "demonstration" (a ce propos la on attend encore un argument technique recevable, tu te defiles encore sur le sujet).
ni meme de te convaincre, mon but est de montrer aux gens qui lisent tes posts qu'il y a un autre point de vue.
Et donc tu utilises les insultes et les insinuations comment dire desagreables pour faire avancer ton point de vue. C'est une facon de faire certes mais cela ne respecte en rien ni la netiquette que ce soit dans la forme ou l'esprit ni les formes de politesses minimales entre 2 individus.
Contrairement a ce que tu dis j'ai surement plus de respect pour ta boite que tu ne le crois mais comme des que quelqu'un dit un truc qui ne correspond pas a la l'image que se donne ta boite, tu commences a sauter dessus et a insulter, et depuis quelque temps c'est de facon systematique, tu as reussi a creer intolerants. Il n'y a aucune retenu et tout ce qui sors de chez micorosoft devrait etre encenser d'apres toi sans qu'aucune critique ne puissent s'y appliquer. Par contre tous ce que fais les autres il faut bien le descendre et pointer les faiblesses.
Pour en revenir au sujet, microsoft openxml, il y a des problemes dedans divers et varies (tu as pas trop ramene ton point de vue sur les erreurs dans les formules statistiques d'ailleurs). Des problemes sur une version 1.0 c'est normal et ca prouve juste que le fast track est une aberration totale d'un point de vue technique. D'un point de vue de domination sur les formats et d'un point de vu portefeuille de microsoft naturellement que c'est normal .
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 2.
2) je suis visiblement pas le seul cretin/idiot etc present sur ce site car nous te posons tous la meme question simple:
"Donne une justification technique autre que mon voisin fait la meme chose"
C'est pas une question complique et pourtant tu es strictement incapable d'y repondre. Un certain nombre de personne, dont moi, ont montre, explique avec des mots simples que le travail en question doit se faire uniquement dans le filtre. Un concept bien compris s'enonce simplement c'est tout.
Tu peux continuer a m'insulter et a tenter de m'ecraser. Tu ne m'impressionnes pas plus pour autant et je dois dire que je suis assez content de ce fil de discussion car, pour moi et pour un certains nombre d'autre personne, tu as bien demontre tes limites techniques (ce qui n'est pas du tout une honte en soit enfin pour de mon point de vue). Tu remarqueras aussi que contrairement a toi je ne fait aucune allusion (meme subtile) sur ton intelligence et ton QI et que dans tous ce fil, encore une fois contrairement a toi, je n'ai pas employe une seule insulte. J'ai juste donne donne mes arguments sans aucune attaque personnelle.
[^] # Re: Autre raison
Posté par abramov_MS . En réponse au journal La fin de Thunderbird ?. Évalué à 3.
thunderbird dans un truc comme:
.mozilla/thunderbird/87dsfsf313.default/Mail
ou un truc du style
pendant ce temps kmail (et donc kontact) met tous ses petits dans:
.kde/share/apps/kmail/mail
je soupconne que c'est encore un truc different pour evolution.
Et la je ne parle que de la ou les mails sont stocke mais chaque soft utilise sont format.
Au moment ou l'on se bat pour avoir un format commun pour les suites offices, il serait temps de faire la meme chose pour les mailers. Que cela serait bien si l'on pouvait ouvrir ses mails avec kmail, evolution, thunderbird etc sans faire des copies, transformation etc.
En gros on est sous kde on ouvre avec kmail et si l'on veut se servir/tester un autre mailer tel que evolution ou thunderbird cela marcherai en sauvergardant les mails de la meme facon au meme endroit et kmail pourrait, a l'ouverture suivante les voirs sans problemes.
[^] # Re: Autre raison
Posté par abramov_MS . En réponse au journal La fin de Thunderbird ?. Évalué à 3.
La gestion des contacts en particulier les listes est, a mon avis, complexe et non ergonomique, kmail marche pas mal a partir du moment ou l'on ne met pas de filtres anti-spam car la ca rame a mort a chque reception de mail (probleme recurrent et soit disant regle a chaque nouvelle version...) etc
Il a aussi ses bons cotes tout de meme, sinon je ne l'utiliserai pas (meme si c'est vrai que la difficulte voir l'impossibilite d'utiliser differents mailers est une des raisons pour lesquels j'utilise kontact).
Le fait de pouvoir lancer chaque composant independemment est un atout certains surtout lors du travail sur batterie. Le fait que basket soit integre dedans est un atout formidable, les journaux, les notes etc au meme endroit c'est cool. Il manque a mon avis tout de meme l'integration de kplato pour la gestion des projets.
Enfin comme l'essentiel du boulot sur les applis kde se fait pour passer a kde4, je comprend parfaitement qu'il ya d'autre priorite actuellement et je pense que la situation s'ameliorera nettement l'annee prochaine.
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 2.
On attend toujours une reponse autre que "ODF fait pareil"...
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 3.
En resume tu n'as pas reussi a convaincre une personne d'une obligation technique de mettre des balises de compatibilite. On peut meme dire que tu as reussi exactement l'inverse et la seule defense que tu as trouve c'est dire que ODF fait la meme chose. Ce qui, si c'est vrai, est totalement aussi stupide.
Je sais bien que par rapport a toi nous sommes des idiots et des incapables et que nous ne comprenons strictement rien a l'informatique, la programmation et la logique. Il est tout de meme excessivement dommage que tu n'es pas reussi a t'abaisser a notre niveau pour expliquer de facon clair et simple ce genre de chose.
La conclusion c'est que toutes les personnes ayant lu precisement ce fil de discussion sont arrive a la meme conclusion et que c'est sale la facon de faire de microsoft openxml ainsi que ODf si tu dis vrai. Au passage peux tu donner le nom de la balise en question. Il se trouve que j'ai des fichier de openffice.org <2 et que je voudrais verifier tes dires.
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 3.
C'est bien ce que je pensais sur la boite qui preside le commite pour la normalisation en France de microsoft openxml. Merci de nous dire que la partialite dans ce cas influence le resultat.
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 3.
http://linuxfr.org/comments/853082.html#853082
voir sa reponse qui dit bien que si MS office 2000 ne sauve pas dans le format microsoft openxml avec les balises en question, il est incapables de relire un pure document openxml. Pour le reste des softs (koffice, openoffice.org, lotus note etc) ces balises ne servent strictement a rien (enfin d'arpres ce que dit pbpg). La conclusion immediate c'est que le filtre de MS office 2000 est incomplet et incapable de lire un pur document microsoft openxml, ce qui mets a mal la soit disant retro-compatibilite...
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 3.
http://linuxfr.org/comments/853637.html#853637
va donc lire les commentaires du pdf dont le lien est fourni.
Ca me rassure je suis loin d'etre le seul a trouver les trucs de soit disant compatibilite totalement aberrant d'un point de vue interoperabilite et technique.
[^] # Re: Les Etats Unis voteront un probablement un 'OUI avec commentaires'
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 2.
Quel est la raison technique de mettre des balises de compatibilite dans le format microsoft openxml?
http://linuxfr.org/comments/852780.html#852780
La seul reponse "technique" de pbpg sur le sujet dit tout et son contraire et un peu analyse montre justement l'inutilite de ce genre de balise. Voir pire cela complexifie pour rien un format deja trop verbeux.
Les soit disant notions de retro compatibilite doivent venir par la publication des formats binaires doc qui permettra de faire de vrais filtres pour chaque version du format doc. Cela ne doit pas passer par l'ajout de balises sales et inutiles, et non documnetes, dans le format dit normalise.
Je suis probablement un peu idiot mais tant que je n'aurai pas une reponse clair sur le sujet je considererai ce format comme mal fait.
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 3.
Tu ne reponds pas a ma question: quel est la justification technique de la chose. Demontre moi que le raisonnement que j'ai dans le message juste au dessus est absude.
C'est pas parceque quelqu'un fait une betise que l'on est oblige de l'imiter. Perso c'est pas parceque je vois quelqu'un rouler a 200km/h en ville que je vais faire la meme chose. Micorosft openxml ayant ete cree apres ODF ils auraient pu au moins eviter de faire les memes erreurs en plus que la norme ODF, ce qui aurait ete un bon point pour vous mais visiblement meme ca n'est pas le cas et vous avez repeter les memes betises.
Donc arrete de me dire: "Mais le voisin il fait la meme chose" et explique moi ou demontre moi que mon raisonnement est debile.
Pour le moment la seul impression que j'ai de tes reponses c'est que tu essayes de noyer le poisson mais que tu n'arrives pas a trouver un vraie justification technique a ce genre de salete inutile.
Et la on parle que de balises de format, je peux rajouter la meme chose sur le bug des dates. Donne moi une seule vrai justification a garder cela dans le format.
Pour le moment j'ai plus le sentiment et j'ai l'impression de ne pas etre le seul que tu demontres plutot que soit le format est en lui-meme incomplet, soit les filtres d'ouverture/sauvegarde sont mal fait.
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 4.
Le format doit, en theorie, donner assez d'information pour l'ouvrir et l'afficher dans MS office 12 et cela sans aucun rajout de balises historiques immondes euh historiques (enfin d'apres ce que tu dis). Ca veut donc dire que le format doit contenir les infos necessaires et suffisantes au formatage. Lorsque tu l'ouvres sous MS office 2000 le filtre d'ouverture doit, et lui seul doit faire cela, transformer les elements de formatage de microsoft openxml dans les elements de formatage MS office 2000. De la meme facon le filtre de sauvegarde doit, et la encore lui seul, transformer les elements de formatage de MS office 2000 en microsoft openXML. Si c'est pas le cas c'est que soit microsoft openxml n'est pas suffisant pour decrire la structure d'un document office soit les filtres sont mal fait et ne sont pas complet.
Je ne vois toujours aucun argument technique pour ce genre d'ajout et encore une fois les balises en question ne sont comprehensible QUE par les outils microsoft vu qu'ils n'ont pas ete defini et decrit nul part. Enfin tout ca c'est peut etre pour vous garder le monopole de la "traduction" du format doc au format microsoft openxml... Enfin vu la reussite flagrante des suites microsoft office dans ce domaine c'est pas gagne d'avoir un rendu equivalent sur vos differents softs. Tu vas me dire vos commerciaux etant super bon ils ariveront bien a le vendre comme ca!
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 6.
Donc nous sommes bien d'accord que le format microsoft openXML a ete fait par et uniquement pour microsoft vu que personne d'autre n'a les valeurs en question des differents bits. De plus si j'etait mechant je dirais que meme chez microsoft ils ont pas les valeurs en questions vu les differents de rendu entre versions de MS office et entre plateformes.
Quand tu re-ouvres ce meme document dans Word 2000, lui il sait comment interpreter ce parametre et il le fait.
Seul petit truc que tu ne mentionnes pas c'est que Word 2000 ne travaille pas en microsoft openXML et du coup pour le comprendre il fau un filtre et donc encore une fois pourquoi ne pas mettre le parametre dans le filtre?
Tout a fait, je t'invites a relire ce que j'ai ecris, tu finiras par comprendre le pourquoi.
Je te cite:
Et quand tu ouvres ce meme document dans l'ancien soft, ce soft sait quoi faire avec ce parametre et l'utilise.
puis deux lignes plus tard:
C'est pourquoi aucun nouveau soft ne va creer de fichier avec ces parametres, ils sont la histoire que les anciens softs puissent les utiliser quand ils convertissent de l'ancien format au nouveau
Tu dis un truc et son contraire. Soit c'est l'ancien soft qui lit les balises mises par le novueau soft soit c'est lui qui les ecrits mais si c'est pour que l'anciens softs les lisent et les ecrivent cela ne sert a strictement rien du tout.
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 8.
Si tu ne connais pas le format initial, ce qui est le cas des formats doc puisque que ce format n'est pas officiellement documente, tu ne peux pas creer la balise XML en question dite de compatibilite dans la sauvegarde dans le nouveau format.
Encore une fois on revient au probleme de l'ouverture de l'ancien format par le filtre. Ce qui n'a strictement rien avoir avec la sauvegarde dans un nouveau format. Nouveau format de tout de facon non lisible directement dans les anciennes versions du programme sans passer par un filtre!
Si tu ne sais pas que les trucs binaires XXX doivent faire un espacement de 2 pts, tu n'as aucun moyen de creer la balise XML le disant.
Le fait de pouvoir ouvrir le nouveau format dans un ancien soft (MS office < 12 ou > 2000) ne peut passer encore que part un filtre et encore une fois c'est au filtre de transformer la nouvelle description dans un mode lisible et affichable par ces suites offices la.
A moins que le nouveau format, sans les trucs de compatibilite, ne soit pas complet et ne permette pas de decrire un document office globalement et doivent absolument se servir de ce genre de balise mais la il n'est plus questions de compatibilite...
C'est pourquoi aucun nouveau soft ne va creer de fichier avec ces parametres, ils sont la histoire que les anciens softs puissent les utiliser quand ils convertissent de l'ancien format au nouveau.
Ca c'est le boulot du filtre encore une fois.
Enfin je vois aussi que ma reponse n'est pas claire mais en relisant ton message je m'apercoit aussi que c'est normal car une fois tu dis que ces trucs de compatibilite c'est fait pour que l'ouverture par les anciens softs se fassent correctement puis apres tu dis que ce sont les anciens softs qui vont sauvegarder avec ces balises particulieres... Donc je dirais que ton message precedent n'a pas ete bien relu et que il y a une profonde incoherence dedans. Donc en conclusion je ne vois toujours aucune raison technique a ces trucs de compatibilite.
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 10.
Franchement j'arrive pas a comprendre mais c'est parceque je suis idiot je sais, pourquoi garder dans un format de sauvegarde des choses specifiques a des vieux format.
Les anciens formats, dont il n'y a aucune documentation officiel, sont ouvert par le logiciel en utilisant un certain filtre qui permet de les ouvrir et presenter correctement dans le logiciel. La sauvegarde dans un autre format tel que microsoft openxml devrait (et c'est ce que fait OOo avec les anciens formats MS d'ailleurs) les auvegarder en se debarassant des problemes et historicite des anciens format.
Lorsque un auteur traduit de l'anglais au francais il ne garde pas la moitie de la grammaire anglaise, ou l amoitie de la structure des phrases ou la moitie des mots de la version anglaise. Alors pourquoi le faire pour un nouveau format de document.
Si je rate un truc et qu'il existe de vrai raison technique explique les moi et sans te foutre de ma gueule s'il te plait.
[^] # Re: En effet
Posté par abramov_MS . En réponse au journal Un revers pour OOXML. Évalué à 3.
Et tu ne te poses jamais la question du pourquoi du generalement?
Ah non c'est vrai tu ne te poses jamais de question toi tu as la science infuse!
[^] # Re: En effet
Posté par abramov_MS . En réponse au journal Un revers pour OOXML. Évalué à 3.
En gros, ceux qui insistent sur le sujet pour dire que la definition est bonne, utilise une tactique bien connu des lobbysite:
http://fr.wikipedia.org/wiki/Homme_de_paille_%28rh%C3%A9tori(...)
En l'occurence, ils ont malgre tout totalement tord sur le sujet et un angle doit avoir une unite defini par defaut et une option pour la preciser au besoin dans un logiciel destine a etre utilise par monsieur tout le monde et donc surtout pas des mathematiciens.
[^] # Re: questions...
Posté par abramov_MS . En réponse à la dépêche Normalisation de l'OOXML par l'ISO freinée par les États-Unis. Évalué à 2.
Alors je vais t'expliquer:
Un exemple n'est pas une definition ni une norme par contre un exemple doit valider la definition et la norme.
L'exemple que tu cites ne prouves strictement rien. La norme aurait pu definir proprement les fonctions trigonometriques de la facon suivante:
sin(angle, unit=XXXX) avec XXXX = radian, degre ou gradient, le defaut etant les radians.
du coup l'exemple fourni fonctionne mais n'est pas la definition en soit.
Enfin visiblement les concepts d'unites physiques sont des concepts qui soit ne sont pas ton fort, soit tu ne veux pas en entendre parler soit tu joues a l'idiot pour defendre une lacune du format (je penche pour le dernier).
C'est assez incroyable comme les defenseurs de microsoft openxml sont ouvert a la critique. Plutot de dire: "En effet, il y a un manque a cet endroit" et le corriger. Ils preferent attaquer en racontant des enormites sur l'utilite de l'utilisation des unites physiques...
C'est assez rigolo. Pas tres constructif de votre part mais rigolo!