Dans la lignée des précédents journaux.
Je viens encore de perdre une journée a repasser des hacks baveux, des tableaux partouts sur un site qui était à l'origine aux normes et pourtant testé sous le navigateur pourri de bugs versions 5.5 de cette société. Oui, car on m'a rapporté que la version 6 corrigée apportait sont nouveau lots de bugs dans l'affichage du site.
Soit encore 1 journée, alors qu'on utilise plus leurs produits.
Mais au fait, combien de temps perdons nous sans utiliser ses produits ?
- à filtrer les virus qui arrivent dans les mailbox à causes de leurs failles de sécurité multiples patchées à 6 mois ?
- à supprimer les mails grace aux open relays créés pour les mêmes raisons que précédemment ?
En précisant le volume de bande passante généré.
- A essayer d'acquérir du matériel sans leur logiciels pourris ?
- A contourner leurs technologies propriétaires ?
Quand on pense qu'ils parlent de cout de mise en oeuvre par rapport à linux alors que leurs utilisateurs doivent en plus passer leur temps a gerer les virus, les reboots, les scandisks, les defrag et autre...
Quand à nous, je suis certain que la liste à subir est encore longue.
Journal Cette corporation qui nous pourrit la vie
29
août
2005
# agir
Posté par ccomb (site web personnel) . Évalué à 4.
Un exemple : on peut toujours râler sur la vente liée, qui est plus que jamais d'actualité même si de temps en temps on constate quelques nouveautés (HP/Mandriva). Mais il faudrait vraiment prendre le temps de faire quelque chose de concret comme créer un annuaire interactif pour lister tous les revendeurs/constructeurs qui vendent des portables sans OS. Il y a déjà eu quelques initiatives là-dessus mais je n'ai pas encore vu quelque chose d'abouti et d'utilisable.
Il faut juste un peu de temps et un peu de LAMP.
Ici, j'avais commencé à mettre des idées sur la manière de faire fonctionner l'annuaire :
http://ccomb.free.fr/wiki/wakka.php?wiki=AnnuaireRevendeurs(...)
[^] # agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mouns (site web personnel) . Évalué à -5.
maintenant, serieusement, FireFox est buggé, Opéra est buggé, Safari est buggé, Konqueror pourtant ils sont soit disant respectueux des standards.
il y a plein de comportement bizarre aves les navigateurs pseudo standard ... genre pourquoi le :first-letter ne se comporte pas entre eux, de la meme manière quand il y a aussi un :hover et que l'on a des text-transform: & color: ( pour un exemple flagrant ) ?
il n'y a qu'à respecter le standard pourtant ... et les devs font leur boulot en lisant les standards.
tout le monde chie sur le padding qui ne se comporte pas "normalement" chez IE ... mais un padding n'est il pas un margin ou un border du block contenu et donc un span ou un div ne peut il pas aider ?
je n'ose meme pas dire que le bugzilla de FF deborde, et que C# est un standard ( un vrai ) de Microsoft et pourtant il n'est pas utilisé par les partisans des standards.
Mais le pire est que tres peu de libristes ( et de personnes en general ) ont lu du début à la fin et ce de maniere linéaire les specs HTML, XHTML, CSS, DOM, XML, XPath, ... pourtant, je suis sur qu'il va y en avoir qui vont me repondre ici meme "moi je les ai lu du debut à la fin" pour me prouver que eux non, mais les autres ?
Donc, je suis entierment d'accord avec Christophe, il faut agir.
et pour agir, il faut informer.
et pour informer correctement, il faut deja s'organiser entre ceux qui veulent informer.
encore faut il que ces personnes sachent de quoi ils parlent ... et actuellement, c'est là où le bas blesse pour beaucoup de monde ( ce qui me fait penser à l'interview de ce matin sur france culture à propos des rumeurs ayant circuler dans tous les camps à propos du TCE ).
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Adrien BUSTANY (site web personnel) . Évalué à 2.
Ben pourtant j'ai plein de progs en C# il me semble pour gnome (muine, beagle et cie). Ou alors j'ai pas compris ta remarque.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mouns (site web personnel) . Évalué à -4.
combien de paquet dependant de python ? de perl ? de ruby ? de php ? combien de mono ?
( la methode facile, tu lances aptitude : tu chope mono ou mono-jit et tu regardes le nombre de paquets dependant ).
pourtant ecrire en C# permet d'etre interopérable avec l'environnement MS ... et comme base pour du plugin ca peut etre interessant : un FF, OOo, Gimp, Gnumeric, Scribus ont interet à integrer mono en natif si ils veulent aussi avoir une base d'utilisateurs sous windows sans trop les dépayser.
sinon 2 programmes pour moi, ce n'est pas "plein". GNOME n'est pas en C#, il y a principalement du C, C++, python ( d'ailleurs GNOME sur Debian Stable est fourni sans mono ).
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Flink . Évalué à 2.
C# ne permet en _rien_ d'être intéropérable avec l'environnement de MS comme tu dis. C'est un bête langage tout comme le python, le C ou le php.
Ce qui permet d'être intéropérable avec .NET c'est la VM .NET justement à savoir Mono. Mais Mono n'intègre pas forcément toutes les classes de Microsoft (et ça peut se comprendre vu le nombre) de plus la plupart du temps quand tu fais du mono, tu utilises quoi pour faire ton IHM? GTK# ! Ah bien mais sous ouinouin ce sont les WinForms qui sont utilisées à 99% et mono sait les rendre à présent il me semble (pour ce qui est de .NET 2 je sais pas où ça en est).
Donc non C# ne permet pas d'être plus intéropérable, pas plus que java ou python ou autre chose. Si tu développes en GTK#, sous windows pour que ton appli fonctionne il faudra installer GTK# etc...
Tu donnes aussi des applications qui devraient intégrer mono et encore une fois tu n'as pas l'air de comprendre comment cela fonctionne... Scribus dis tu? Mais Scribus est écrit en Qt ! et du Qt# ça n'existe pas ! (y'a bien eu un projet mais il est un peu beaucoup mort depuis un moment)
Voilà, mes 2 cents
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mouns (site web personnel) . Évalué à -1.
Qt n'est pas un language.
Scribus utilise Qt au moins comme toolkit graphique et est codé en autre chose.
je parle de C# comme langage de script pour un plugin, un peu comme ce que l'on trouve dans gnumeric-extra qui permet de faire des plugins perl et/ou python dans gnumeric.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Flink . Évalué à 1.
Ben sinon après c'est comme tout c'est à voir pour des plugins en c#, faut voir comment ça s'interface aussi avec le reste
Et sinon j'ai jamais prétendu que Qt était un langage merci ;p
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par - - . Évalué à 8.
Opera, Safari et Firefox ont un comportement infiniment plus standard w3C que ie
et les bugs concernant moz , safari et opera sont connus et leurs équipes sont CONNUS pour chercher à les corriger et ont toujours su améliorer le support, de version en version
donc, non, on a bien raison de se plaindre de IE. et je travaille PAYE pour me prendre la tête sur ces conneries. merci
bon le cas de C# :
alors d'abord ne confondez PAS le langage et son runtime ET L'environnement système autour !
RIEN oblige à faire du c# (ou .net) pour faire un programme windows qui "dépayse pas". la preuve en est qu'office ou photoshop ont rien de C#.
faire passer Gimp ou Gnumeric en C# ? hahaha, il faudrait des années de réécriture tout en considérant que les briques fonctionnelles (gnomes-vfs, gtk et autres myriade de libs, combien même les versions windows de gimp et gnumeric n'active pas l'usage de toutes les briques de gnome, certaines le sont) soient portés autour du runtime microsoft ou de mono. révez pas. ca viendra jamais. patientez plutôt pour des nouveaux softs.
notez qu'il existe un projet de mapper l'api de gimp en C# (pour utiliser les fonctions gimp depuis un code en C#).
Gnumeric est de plus en plus "windowsien" uniquement avec un bon usage de gtk+ (du C)
des programmes commerciaux sont écrits en QT (c++) et sont des "natifs windows".
Limewire est java et foule d'utilisateurs l'utilisent sur windows.
---
un programme C# qui est "interoperable" doit être juste un programme console ou qui utilise winforms
les programmes mono pour gnome utilisent GTK# qui lui repose sur les fondations gnomes pour apporter le "look" et FEEL (le style d'interface, l'intégration) d'un vrai logiciel gnome
en clair : Tomboy ou Muine qui sont en mono/gtk# ne marchent PAS sur windows. (parce que windows a PAS les fondations gnomes nécessaires, c'est encore plus que ce que gimp demande)
il n'y a pas plus de raisons de programmer en GTK# qu'en python pour faire un vrai programme gnome, à part être HYPE
et encore, je connais bien de gens qui disent être hype en faisans du gnome-python ou du gnome-java (c'est super hype java dans certains milieux professionnels)
faire un logiciel C# "interopérable" est tout à fait possible avec mono, mais on se limite sérieusement au niveau des possibilités, et bien sur le programme sera un alien sous gnome, kde ou os x.
notons qu'on pourrait tout autant faire du interopérable avec java et pas eu besoin d'attendre microsoft pour cela. (et y en a qui l'ont fait comme limewire)
quoi d'autre ?
l'usage de MONO pour gnome ne se résume PAS à 2 applications :
muine
ifolder
beagle
f-spot
tomboy
blam!
mcatalog
et bien d'autres.
Forcesight linux est une distribution qui fournit mono, beagle etc de base, tout intégré à gnome.
GNOME n'est PAS en python ou java ou perl ou quoi que ce soit
GNOME est en C
GNOME CORE est écrit en C et cela le sera pour les années à venir et aucune décision de changer cela n'a été prise ou est débattue
GNOME DESKTOP continue à être en C. aucune décision de réécrire panel, nautilus ou autre en C# ou java ou python n'a été prise
une application "gnome" peut par contre être écrite en C, C#, C++, JAVA, PERL, PYTHON et être une totale application gnome (y a aussi d'autres langages plus exotiques qui ont un bindings complet ou quasi complet)
rien n'interdit à terme qu'une nouvelle application gnome desktop (qui complète le bureau gnome) ne soit en python ou perl voir C# si mono est accepté dans toutes les distribs.
il y aussi divers développements basé gstreamer en gtk#
voilà où ça en est actuellement
Il y a de _solides_ raisons pour laquelle encore peu de choses dépendent de mono :
- raisons légales (et non c pas des fuds que de chez redhat)
- maturité (arrêtez de fumer de la moquette, python et perl ont de solides fondations et des tonnes de librairies à tout faire dispo . on n'abandonne pas un tel existant pour se jeter sur mono ou gtk# même si c'est achement cool
- compétition avec java. sérieusement, le choix entre c# ou java EST PAS FACILE !! y a d'excellentes raisons professionnelles, technique et maturité qui me pousseraient à privilégier uniquement java plutôt que c#.
je vous conseille de lire gnome planet et les différents "planètes" associés (redhat, novell, etc ) , lire celui de sun
je vous conseille d'éplucher gnomefiles.org
pour mozilla, je vous conseille mozillazine.org
pour safari : http://webkit.opendarwin.org/blog/(...) ou vous pourrez compiler le code cvs de webkit pour vous faire un ptit safari encore plus standard (assez impressionnant les progrès d'apple)
pour opera, je n'ai pas d'url sous la main, y a différents blog consacrés à son développement. on attend une grosse nouveauté pour bientôt
bien sur, y a standblog.org qui vous fera un peu de tri dans tout ça.
maintenant, vous ne cherchez pas de polémique et vous laissez le temps au temps !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mathieu Pillard (site web personnel) . Évalué à 6.
Rajouter des elements HTML est amha pire qu'un hack CSS bien pensé, mais ce n'est pas le débat.
Le probleme en l'occurence, c'est pas ce malheureux petit probleme de padding effectivement simple a eviter, mais plutot Peekaboo, Guillotine, Double float margin, 3px Text Jog et autres petits noms fort sympathiques qui désignent des bugs tres chiants a isoler, meme quand on les connait, et quelquefois tres chiants a contourner... (Faire un petit hack pour un probleme, ca va, mais si les hacks necessaires s'annulent les uns les autres...)
Tu dis que il faut etre bien informé, je suis d'accord. En fait, il faut non seulement apprendre les standards si on veut les utiliser ou en faire la promotion (oui, ceci inclut lire et relire les recommandations), mais aussi apprendre les bugs et les manques des navigateurs, de tous les navigateurs, et comment les contourner. Je suis le premier a pester contre IE, ses bugs, ses limitations, mais au final, on s'habitue. Je plains juste ceux dont ce n'est pas le boulot et qui doivent lutter avec...
PS: Faudra quand meme que l'on m'explique pourquoi 75% des propriétés DOM que IE ne supporte pas ont un équivalent proprio avec juste le nom qui change ou presque. C'est vraiment du foutage de gueule.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mouns (site web personnel) . Évalué à 3.
certes là n'est pas le débat, et je suis d'accord avec toi. puisque tu es tombé dans mon vil piege, sais tu que ccszengarden utilise des div vide pour permettre des mises en page sympa ? est ce mieux qu'un tableau ? ou qu'un span/div ... personnellement, je m'en fout ;)
pour ce qui est de l'information des gens, oui, il faut le faire. mon coup de gueule était plus sur le fait qu'avant de parler des problemes de IE, il serait interessant de parler des problemes recurrents avec les moteurs disant respecter les standards.
un mec qui code un browser, a lu les specs, cela est evident. par contre, ceux qui codent des sites s'adaptent de maniere transparentes aux bugs Opera/Konqueror/FF/Safari en faisant exactement ceque un dev web IE avec IE ... en pensant que le bug est un standard et que c'est les autres ont tord !!!!
... et bien souvent les bugs les plus con sont les plus chiant à corriger.
j'oubliais de dire qu'un certains nombres de bugs IE sont referencé par google sur le site de microsoft.
parce que DOM 1 n'est pas si vieux par rapport à ce qui est devenu DOM 0, et que si IE supporte les deux syntaxe, alors cela oblige à maintenir 2 modeles pour deux bases d'utilisateurs.
d'un point de vu MS, changer le comportement de IE revient comme Apple à passer à Intel, ca risque de foutre le bordel et l'inquiétude partout ... conclusion, à contrario d'Apple, nous pouvons constater que MS ne fait toujours pas ce choix là.
par contre, rien ne t'empeche de redefinir les methodes en les aliassant en JS: si la methode n'existe pas, cela n'est pas genant de la définir ;) . et la notion d'héritage par prototypage, et de classe par prototypage, permet de le faire moyennant une bonne connaissance de JS.
maintenant, faut pas se leurrer, la base c'est uniquement IE 6 Win, IE 5.2 mac, FF, Safari, Opéra, Konqueror.
nous sommes bien loin des boxon qu'à l'époque des Mosaic multi plateforme buggé, NN1/NN2/NN3, IE2/IE3/IE4, tout ca en pseudo multiplateforme et reellement buggé.
Apres pour l'embarqué, il n'y a pas 36 moteurs, donc cela reste assez facile. mais faut prendre le temps ;)
mais chut ... faut que j'ai l'air de ne pas savoir ce que je raconte et que je trolle de maniere outranciere :D
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Guillaume Knispel . Évalué à 0.
[...]
par contre, rien ne t'empeche de redefinir les methodes en les aliassant en JS: si la methode n'existe pas, cela n'est pas genant de la définir ;) . et la notion d'héritage par prototypage, et de classe par prototypage, permet de le faire moyennant une bonne connaissance de JS.
Et après on a le droit d'emballer des marmottes ?
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mouns (site web personnel) . Évalué à 4.
var mon_ajax; var to_eval = ""; if ( window.XMLHttpRequest ) { to_eval = " function _XMLHttpRequest() { " + " this.wrapper = new XMLHttpRequest(); } "; } else if ( window.ActiveXObject ) { to_eval = "function _XMLHttpRequest() { " + " try { " + " this.wrapper = new ActiveXObject( 'Microsoft.XMLHTTP' ); " + " } catch ( E1 ) { " + " try { " + " this.wrapper = new ActiveXObject( 'Msxml2.XMLHTTP' ); " + " } catch ( E2 ) { " + " this.wrapper = 'inactif'; " + " } " + " } " + " } "; } else { to_eval = " function _XMLHttpRequest() { " + " this.wrapper = 'inactif'; " + " }"; } eval( to_eval ); function xmlhttprequest_est_actif() { if ( typeof( this.wrapper ) == "string" ) { return false; } return true; } _XMLHttpRequest.prototype.est_actif = xmlhttprequest_est_actif; mon_ajax = new _XMLHttpRequest(); if ( mon_ajax.est_actif() ) { alert( "XMLHttpRequest actif" ); } else { alert( "XMLHttpRequest inactif" ); }la marmotte, elle te dit qu'avec ca tu as sur les principaux navigateurs du marché ( testé à l'instant avec IE mac, IE PC , FF, Safari et Opéra ), le debut d'une classe pour wrapper proprement sur ces navigateurs les spécificités de XMLHttpRequest. la marmotte ne va pas faire ton boulot puisque tu sais que la marmotte raconte des conneries et ne sait pas coder. la marmotte se demande ce que tu fais dans la vie ... la marmotte te demande de mediter sa signature avec une sitation de Charles Darwin et une de Damian Conway.[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par pierthi . Évalué à 2.
var mon_ajax; if ( window.XMLHttpRequest ) { mon_ajax = new XMLHttpRequest(); } else if ( window.ActiveXObject ) { try { mon_ajax = new ActiveXObject( 'Microsoft.XMLHTTP' ); } catch ( E1 ) { try { mon_ajax = new ActiveXObject( 'Msxml2.XMLHTTP' ); } catch ( E2 ) { alert("IE est une grosse bouse. C'est con pour vous."); } } } else alert("Merci de ne pas utiliser lynx"); mon_ajax.onreadystatechange = process_updates; mon_ajax.open("GET", "truc.xml", true); mon_ajax.send(null); function process_updates() { if (mon_ajax.readyState == 4) alert(mon_ajax.responseText); }P...n impossible d'afficher du code et des paragraphes dans les commentaires ?[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Jean Canazzi . Évalué à 1.
[^] # Re: XmlHttpRequest
Posté par pierthi . Évalué à 2.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Matthieu . Évalué à 2.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mouns (site web personnel) . Évalué à 2.
d'apres plein de liens sur google, aussi.
maintenant, je suspecte un soucis avec l'appel d'un activeX dans un eval :/ faut dire que je teste sur tiger et non panther/jaguar ( sachant qu'il y a un gars qui remonte explicitement un soucis avec jaguar )
http://www.howtocreate.co.uk/tutorials/jsexamples/importingXML.html(...) <- a cet endroit, il y a une solution, donc si tu veux wrapper par dessus ...
de toute facon ce que je viens de faire necessite pour le moment de redéfinir les qq méthodes pour faire la transposition correctement.
donc ajouter un support par iframe ne doit pas etre une trop grosse horreur.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mouns (site web personnel) . Évalué à 2.
- il me semble, sauf erreur de ma part, qu'il me faut faire qu'un autre new _XMLHttpRequest pour avoir un deuxieme objet.
- le constructeur ne fait aucun case_matching pour savoir ou il est.
- je fourni une methode "universelle" pour savoir si le chargement a eu lieu.
comme tu dois t'en douter, vu que j'ai codé vite fait cela hier soir, tu ne peux pas faire grand chose avec ce que j'ai fournis.
par contre, en ajoutant les bonnes methodes, tu peux tout à fait disposer d'une classe JS wrappant et te fournissant qq extensions interessante ( comme un équivalent avec iframe ).
par rapport à IE Mac, il y a bien des references à un support XML dans IE Mac ( MS XML Library ). maintenant, je ne sais pas ce que l'on peut faire avec.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Guillaume Knispel . Évalué à 1.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mouns (site web personnel) . Évalué à 2.
je précise un détail, lire des specs n'empeche pas de faire des applications avec des bugs. par contre, connaitre les specs permet de les reperer plus facilement ( un peu comme connaitre l'arithmetique aide à debugger quand on veut coder une calculatrice voire un tableur, et non une calculette ).
Par contre, je te rappelle que tes deux citations proviennent de ma prose, donc ma personne a le droit de se sentir offusqué quand on lui balance des marmottes milka. avoir une n-ieme impression de ne pas etre compris, a un coté rageant.
maintenant, j'aimerai savoir ce qu'il y avait à comprendre dans ton commentaire ...
... pour eviter de continuer à mal le prendre ;)
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Guillaume Knispel . Évalué à 2.
Mais clairement en relisant bien tes commentaires, tu as parfaitement raison, alors méa culpa pour la marmotte déplacée :) (quoique c'est mignon une marmotte, nan ?)
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mathieu Pillard (site web personnel) . Évalué à 4.
Tu n'as pas toujours cette facilité qui consiste a trifouiller le code HTML (Exemple: site avec du statique généré, tu as deja généré le HTML, tu veux changer un peu le design...). Donc, en l'occurence, non seulement je trouve ca mal, mais en plus je constate regulierement l'importance de la chose.
Je ne leur demande pas de supprimer leur syntaxe, ni meme de promouvoir la version DOM W3C. Simplement de prendre le peu de temps necessaire a une implementation minime. Maintenir 2 modeles ? Je doute que ca leur cause tellement de soucis.
En fait, mon probleme principal sur le sujet c'est que ils disent vouloir améliorer le support CSS, que tout le monde voit, mais pour le reste, on l'a dans l'os.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mouns (site web personnel) . Évalué à 2.
regarde par là ( http://linuxfr.org/comments/617919.html#617919(...) ) , tu y trouveras une idée sur comment faire pour avoir une émulation DOM potable sur IE en attendant qu'un jour MS intègre au moins un support DOM 1 complet pour ne pas dire un DOM 2.
[^] # Re: agir oui mais prendre le temps d'en gagner en lisant les docs avant
Posté par Mathieu Pillard (site web personnel) . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.