Laurent J a écrit 2933 commentaires

pas pour konqueror, mais pour khtml !



Et pour ton information, les patchs, tu les trouveras sur le premier lien de la news.

Si il fourni des patchs, c'est qu'ils sont un minimum utilisable je pense. Rien n'empeche aux devs de khtml de jeter un coup d'oeil dans les patchs pour avoir une idée de comment david hyatt à résolu les problèmes.

Peut etre même bien que certains patchs concernent des fichiers qui n'ont pas été modifiés dans tous les sens par rapport au tronc de khtml.

Mais ça surement que les dev de khtml, de par leur mécontentement, ne vont même pas chercher à savoir si ils peuvent les appliquer ou pas. je me demande bien si ils ont vraiment jeté un oeil sur ces patchs, et si ils sont pas de mauvaise fois.

non. IE, par le fait d'inclure la chaine "mozilla" dans son user agent, indique qu'il se fait passer pour Mozilla, où plutot pour netscape à l'origine. (en fait, c'est pour emmerder le monde, et tirer la langue à netscape)

Mozilla = un nom inventé par les fondateurs de Netscape, et signifie Mosaic Killer (killer = gozilla), Mosaic étant l'un des touts premiers (le premier meme il me semble) navigateur web graphique. (souvenir souvenir...)

Le moteur de IE, quant à lui, est dérivé de celui de Mosaic (voir les infos de copyright dans la boite "à propos" de IE).

horreur ! j'utilise inconciement malgré moi ces horreurs de balises bbcode !!! Dire que j'ai deteste ce truc de bbcode http://ljouanneau.com/blog/2005/02/16/401-pourquoi-je-deteste-le-bb(...)

Arrrggggg !

Vite, une cure de desintox !

je ne me rappelle pas d'instruction de fallback

La norme CSS dit explicitement que toute instruction ou selecteur non conforme à la norme doit être ignorée par les navigateurs.

Cela va donc dire, si il y a une erreur dans le fichier CSS : l'ignorer. Ce que teste Acid2...

Il est même dit dans la norme CSS, que tout navigateur peut supporter *en plus* des styles qui ne sont pas dans la norme. Mais pour cela, il faut prefixer leur nom par "-foo-" où foo désigne le navigateur. Ex dans Mozilla : -moz-border-radius.

les erreurs pointés par le validateur, sont des erreurs que les développeurs du test ont [b]volontairement[/b] introduits ! (voir les commentaires dans les sources)

Ceci pour tester que le navigateur n'interprete pas des choses qui ne devrait pas l'être.

Exemple, pour la première erreur, qui est située sur cette ligne

[class=second two] { background: red; } /* this should be ignored (invalid selector -- grammar says it only accepts IDENTs or STRINGs) */


Ces erreurs sont aussi signalées dans le descriptif du test : http://webstandards.org/act/acid2/guide.html(...)

j'allais oublier, pour en savoir plus sur l'utilisation de XUL dans le cadre d'une appli web: http://xulfr.org/wiki/ApplisWeb(...)

ce que XUL a de révolutionnaire, c'est que, en premier lieu, ça offre une interface utilisateur beaucoup plus riche que du HTML, et que l'on peut créer trés facilement.

Donc une première utilisation basique de XUL serait : je continue de réaliser mes applis web comme d'habitude, je remplace juste HTML par XUL. (ton histoire d'utilisation d'HTTP, ou plutôt de xmlHTTPRequest tu voulais dire je pense, parce que bon, HTTP, tu peux pas t'en passer :-p, enfin bon, ton histoire de xmlHTTPRequest n'a pas lieu d'être dans ce cas )

Une utilisation plus intelligente, c'est je remplace HTML par XUL, mais j'utilise aussi des services web (via xmlHttpRequest). Ça permet plein de choses

- pas de rechargement de l'interface -> economie bande passante, et charge moins importante du serveur (il n'a pas à tout regenerer l'interface, donc éventuellement à faire des dizaines de requetes pour cela)
- séparation en couche : d'un coté l'UI, et de l'autre des services webs. Lesdit services pouvant non seulement être appelés par l'UI, mais également par toutes autres applications (web, desktop..) bref, -> capitalisation des développements.
- ps de rechargement -> interface plus reactive, plus dynamique, tout ce qui est lié à l'interface est fait coté client -> ergonomie améliorée

En tout cas, je ne vois pas en quoi cette tendance à utiliser xmlHTTPRequest a de mauvais. Elle permet de faire des choses vraiment plus simple et plus efficace dans les applications web (pour les *sites* web, c'est autre chose), autant pour le développeur que pour l'utilisateur.

y en a, ils n'ont pas beaucoup d'humour par ici...

les programmes non-libres sont dangereux pour vous et votre communauté

"Et si vous continuez à les utiliser, vous et votre famille surporteront la colère du guru RMS sur 5 générations, vous serez gangréné par le cancer incurable GPL, vous irez tous en enfer au milieu de pinguoins mangeur d'homme dréssés par Linus, par -50 °C (oui l'enfer ça peut être trés froid il parait), et un déluge d'instructions assembleurs s'abattra sur vous pendant 10 ans si dans 1 mois vous n'avez pas voté OUI aux logiciels libres."

->[] (faut vite que j'aille effacer cette partition windows qui ne me sert plus à grand chose...)

non

car il y a des repertoires où tu ne veux pas voir tout les fichiers cachés, et d'autres si (par exemple toujours voir le .htaccess des sites web que l'on developpe)

Et puis moi, j'aime bien voir ce qu'il y a réèllement dans mes répertoires. Sauf mon home car c'est vrai, plus çca va, plus ça devient vraiment le bordel.

Vive le $XDG_CONFIG_HOME .

oui et non.
C'est pas le XUL qui permet de faire ça (XUL, c'est le langage d'interface graphique). Mais par contre tu as une API disponible pour tout ce qui est web service (SOAP, XML-RPC, ou encore le fameux xmlhttprequest):

http://xulfr.org/wiki/WebServices(...)

ou plus généralement, faire des ApplisWeb avec les technos de Mozilla :

http://xulfr.org/wiki/ApplisWeb(...)

On constate ici au moins 3 technologies

Et encore, tu n'as pas regardé du coté de Gecko. Pour développer une appli Mozilla, il faut connaitre : XML en général, XUL, XBL, CSS, XPCOM, Ecmascript, DOM, RDF, le format de package XPI... Et d'autres si on veut aller plus loin (C++, SVG, XSL, SOAP, XML-RPC, XForms, MathML etc..)

Heureusement, y a déjà un site pour ne pas s'y perdre dans tout ça ;-)

oui, surtout que la spirale qu'il montre sur sa roue, tourne dans le sens contraire à celle de debian.
:-/

Ca ressemble fortement à du XUL nan ?

Non, ça c'est du XBL :-p (il y a 1 seule balise xul là-dedans)

Mais effectivement, j'ai pas pensé à regarder dans la feuille de style si il y avait des bindings

Autant je trouve que le XUL est vraiment prométeur

Prometteur ? tu es sur ? pour moi, prometteur, cela veut dire que la techno n'est pas encore disponible. Or ça fait déjà quelques années qu'on peut faire du XUL...

je me demande s'il compte en améliorer la vitesse ???

Oui bien sûr. Mais ce n'est pas XUL qui est en cause. C'est gecko, le moteur d'affichage de Mozilla/Firefox/Xulrunner, qui sait afficher tout type de fichier XML (XUL, xml qcq, XHTML, MathML, SVG ...) avec des CSS.
Et dans sa version 1.8, qui devait être utilisé par Mozilla 1.8, gecko est encore plus performant. Il faudra attendre Firefox 1.1 pour s'en rendre compte.

XulRunner ne permet pas d'aller plus vite que Firefox : ils utilisent le même moteur Gecko. Par contre, si plusieurs applis utilisent XulRunner en même temps, on va avoir des améliorations interressantes coté consommation mémoire puisque les libs de Gecko ne seront instanciée qu'une seule fois en mémoire.

quand j'essaye quelques trucs XUL en ligne avec firefox, ça rame sévèrement (mon PC n'est pourtant pas si vieux). Exemple tout bete : http://sharewebnom.sourceforge.net/notes/test.html(...)

Quand je regarde les sources de ce truc, je ne vois le bout d'une balise xul nulle part...

pour ton histoire de lenteur toute fois, je pense que ton pc est un peu vieux car l'exemple que tu donne est parfaitement fluide chez moi (1.8ghz)

Je souhaite un aussi franc succés à ce last jeudi que le précédent !

Vive les logiciels libres à Tahiti !

Pour cela XULRunner propose de nombreux services tels que le support réseau, l'affichage HTML/CSS avec Gecko, la cryptographie ou encore la manipulation de XML.

En fait, XulRunner contient tout ce que contient Firefox et Thunderbird (tout les composants XPCOM et Gecko), sans l'interface de ces produits ;-)

Pour un aperçu de myBrowser : http://ljouanneau.com/blog/2005/04/19/419-xulrunner-en-action(...)

Pour d'autres news sur le sujet : http://xulfr.org/news/(...) et http://xulfr.org/wiki/XulRunner(...)

j'apprends juste que Firefox sera encore plus lent

Qu'en sait -tu ? tu as une boule de crystal ? C'est pas un troll que tu as lancé, ce sont des suppositions non vérifiées.

Si les dev de Gecko ont choisi d'utiliser Cairo pour tout le reste de l'affichage, c'est certainement qu'ils ont étudié un minimum la lib et qu'ils savent donc qu'il y a moyen d'optimiser, que le cas de Cairo est loin d'être catastrophique.

Maintenant, si tu connais une alternative au moins aussi puissante, plus rapide et sous licence MPL/LGPL, contacte les. (mais te fatigue pas, ils ont surement déjà chercher longtemps)

Bref, ça sert à rien de tenter de troller là où il n'y a pas de troll.

si, c'est impossible vu le flux de demande. À moins de passer 10 ans à valider une demande de brevet, ce qui serait n'importe quoi.

Dans la mesure où un système n'est pas capable d'absorber ses flux en entrée, il faut changer le système, le modifier.

Le seul moyen actuel pour les organismes de brevet d'absorber le flux, c'est de diminuer les verifications. Ce n'est pas la bonne solution. Si maintenant la legislation dit, ne pas s'occuper de tel ou tel type de demande de brevet, ils ne seront donc pas obliger de traiter ces types de demandes, et pourront faire les verifications qui s'imposent sur les autres.
Si elles acceptent toutefois de traiter les types de brevets non permis, c'est aussi un problème car finalement actuellement rien ne les empeche (et traitent donc mal les bonnes demandes de brevets). Là encore, si une legislation les mettaient à l'amende à chaque dérive, tout se passerait certainement mieux.

Mais cela necessite là encore de changer la legislation. C'est donc bien la législation qu'il faut changer. pas changer les organismes de brevets (les nouveaux feraient exactement les mêmes betises si la legislation leur permet).

C'est pas la peine de créer de la nouvelle législation, il suffit de respecter celle qui est déjà en place.

Oui mais ça, c'est la théorie. En pratique, c'est impossible à faire car Il y a trop de vérifications à faire, trop de demande de brevets, trop de brevets déposés.

Comme c'est impossible, cela signifie que la legislation actuelle n'est pas adapté à la réalité. Mauvaise legislation, changer legislation. Comment ? ça c'est une autre histoire. Mais il est évident qu'il faut la faire évoluer. C'est ce que dit IBM.

Une solution serait donc de restreindre le type de brevet que l'on peut déposer.
Interdire par exemple les brevets logiciels non liés à un phenomène physique, ce serait déjà un grand pas.

Il y aurait déjà beaucoup moins de vérifications à faire dans l'ensemble. La vérification des autres demandes de brevets "legitimes" serait donc plus approfondies, mieux faîte ;-)

en fait, je viens de me rendre compte : faut faire comme ce qu'on fait sur les projets opensource hebergé sur sourceforge, gna, devlibre &co :-)

D'ailleurs, installer un gforge en interne dans ta boite, ça peut être sympa pour bien suivre les projets (système de suivi des bugs, organisation des taches, etc..)

Je ferais comme ceci :

- chacun a son petit serveur web en local, avec son propre repertoire local de l'appli. Il test en local sans risquer de tout casser pour les autres developpeurs.
- Il y aurai un serveur qui fait serveur web de test global et repositorie svn
- une fois bien testé en local, on commit sur le serveur svn.
- là, je suppose que ça doit être comme dans cvs, il doit être possible d'éxecuter un script sur le serveur à chaque commit. Ce script serait chargé de copier le fichier commité sur le site de test global. (au pire, si cette mise à jour n'est pas possible comme cela, un cron fera bien l'affaire, mais c'est pas top)

Et voilà.
Donc on fait un update, on modifie, on test en local, on commit, on test sur le serveur global.

c'est pas parfait mais je pense que c'est déjà pas mal.

Plus serieusement, j'ai ecrit ce journal dans un but tres idiot, c'est de garder une partie des commentaires sur cet "evenement" centralisés au meme endroit.

A mon avis, si tel était vraiment le but (ce dont je doute tout de même), il y avait moyen de le dire autrement et moins connement.

si maintenant pour toi être pour le respect d'autrui, c'est être un vieux reac pete sec, il ne faut pas s'etonner alors de toutes les merdes dans lequel le monde s'englue de plus en plus chaque jour (brevets logiciels, guerres, domination du fric, massacre de l'environnement etc...).

voir un journal de cet acabit, pueril et de surcroit insultant, ça fait vraiment pitié.
Mais que font les modéros ?

Désolé de te le dire jylam, mais, contrairement à ce que tu dis, oui, tu es un con.

C'est pas que je sois forcément pour toutes ces sagas papal, mais il y a tout de même des limites à la connerie.

On dirait les propos d'un gamin de 6 ans dans une cour de récré, du même acabit que "nananère, c'est celui qui dit qu'y est, et d'abord, tout ceux qui utilisent debian sont des cons".

[X] du temps, du temps, et encore du temps

Comment voulez vous sinon coder sur 5 projets en même temps, ces projets qui doivent sortir le plus vite possible pour coder les 10 suivants ? hein ?