On code l'application exactement comme on le ferait en JavaScript, sauf qu'on utilise C++
Donc tu passes 10 fois plus de temps à implémenter un truc (des listeners et autres trucs d'interface), pour un résultat qui n'apporte au final rien en terme de perf (au niveau de l'UI).
disclamer : je fais du xpcom c++ depuis des années...
Lorsque l'on code une application en JavaScript, on accède en fait à des composants écrits en C++ à travers leur interface JavaScript. L'idée c'est d’accéder à ces composants directement en C++, sans passer par JavaScript. On a donc, au contraire, une couche logicielle en moins...
moui ok, je comprend mieux le principe de ton truc. Mais quand même, comme je dis, ça n'apporte rien en terme de perf, au niveau de l'interface utilisateur, sauf si tu manipules à tour de bras des centaines d’éléments XUL. En tout cas le rapport (productivité, facilité de dev, de maintenance etc)/performance est très très faible.
Mais elle ne détaille pas comment manipuler un élément XUL en C++. Par exemple, je n'ai trouvé aucune documentation qui indique qu'un élément 'tree' en XUL correspond, en C++, à l'objet 'nsIDOMXULTreeElement'
Pourtant, tout est indiqué sur la doc de la balise tree, https://developer.mozilla.org/en/XUL/tree , en particulier les interfaces qu'elle utilise, et donc ses propriétés dont la view etc. Etant donné que les objets DOM accessibles en JS sont simplement un accés XPCom aux objets C++ correspondant... Et par le passé, XulPlanet.org était encore mieux documenté au niveau des interfaces etc..
Ça fait plus de 11 ans que j'utilise le CVS de savannah.gnu.org. Pourquoi changer quelque chose qui fonctionne ?
Pour être plus productif ? Pour faciliter les contributions ? Pour avoir un outil plus performant ? pour avoir une interface web agréable à utiliser ? (le browser CVS est juste horrible).
Cela rend le développement d'une application XULRunner entièrement en C++ très compliqué,
Le but de XulRunner n'est pas un framework/une plateforme pour écrire une appli entièrement en C++.
Pourquoi ne pas utiliser QT ou autre toolkit graphique ?? Parce que si dans ton projet, l'utilisation du JS est à proscrire, tu t'es, à mon avis, trompé de framework.
oui, je me pose exactement la même question. D'après ce que j'ai compris, on n'a plus à utiliser de gestionnaire d'évènement ou autres trucs "webesque" de XulRunner. Et en gros, tout le code de l'appli est dans des libs externes en C/C++.
Et au final aussi, un truc à la XPCom à été recodé en passant par XPCom. Au final on a donc une couche qui transmet des appels vers les libs externe, donc comme XPCom. -> double couche logicielle pour accéder à la lib externe. à moins d'avoir rien compris au bidule :-)
Bon, sinon, de la doc sur XPCOM C++, elle existe quand même https://developer.mozilla.org/en/XPCOM. Et il y a aussi une alternative, pour accéder directement aux fonctions d'une lib : js-ctypes.
(hors sujet: CVS, c'est vraiment pénible, je recommande d'utiliser un gestionnaire de source récent :-p)
et pour continuer dans le #fail, quietty.com n'est pas accessible depuis un navigateur web, alors que www.quietty.com, si. Une petite mise à jour DNS et config apache/nginx/autre s'impose ;-)
Bon sinon, l'idée du produit est intéressante. Par contre, il ne faudrait pas que le blog connaisse un succès fou, vu le peu de bande passante en upload qu'on a en ADSL en général.
Un jour peut être, les fournisseurs d’accès nous fournirons des débits symétriques...
Oui il y a cette différence d'ouverture de source et de spec.
Mais il n'y a aucune différence quant à la situation et aux conséquences. Le problème se situe dans l'utilisation de propriété non standards ou experimentales. Tout comme avec IE6, les développeurs utilisent des fonctionnalités qui ne sont implémentées que dans un seul moteur de navigateur (ou qui ne sont interprétables que par un seul moteur de navigateur). Cela conduit donc à un web "optimisé pour", tout comme avec IE6. Le fait que lesdites fonctionnalités soient implémentées sous licence libre ou proprio ne change rien au problème, et encore moins à une éventuel solution. On assiste à nouveau à une balkanisation du web.
oui, c'est une bonne idée. Mais j'ai bien peur qu'il soit trop tard, vu apparemment les centaines de milliers de sites pour mobile qui ciblent webkit..
Si j'utilise disons une fonction non-POSIX, mon but n'est pas de faire chier un organisme de normalisation mais de satisfaire un besoin. Le jour où POSIX inclut une fonctionnalité équivalente, eh ben tant mieux : je peux migrer mon code vers une API plus portable.
Oui. Tout comme les développeurs peuvent migrer leur code. Mais dans 99% des cas, ils ne le font pas. Parce qu'une fois le site développé, les "vieux" trucs restent. Et parfois très longtemps. Surtout quand ceux qui sont chargés de faire évoluer le site ne sont pas les développeurs initiaux. Il arrive trèèèèès souvent qu'ils ne touchent qu'à ce qu'il y a besoin d'être touché, par manque de temps, par peur de casser des choses, par j'm'enfoutisme etc..
Au W3C de les fournir à la nouvelle itération
Tu es à coté de la plaque. Les éditeurs implementent les trucs BIEN AVANT de proposer des specs au W3C. C'est pas le W3C qui "fournit".
Je ne vois pas pourquoi leurs problèmes d'organisation interne les autorisent à incriminer les développeurs Web qui, eux, n'y sont pour rien.
Non, ce sont les développeurs web qui sont responsables. les propriétés prefixées sont pour la plupart des trucs experimentaux. LES DEVELOPPEURS NE SONT PAS CENSES LES UTILISER. Ou si ils les utilisent, qu'ils aient au moins le courage de mettre les propriétés préfixés pour les autres navigateurs ET de mettre celles sans prefixe, ceci afin de garantir un minimum que leur site fonctionnera PARTOUT et dans la durée.
Un développeur web est censé suivre les standards. C'est son job de faire en sorte que son site (public) soit lisible partout, parce que c'est la nature même du web d'être "agent agnostic". Ne pas le faire est une faute professionnelle selon moi. Ne pas le faire, c'est ne pas suivre les "rêgles" du WEB. Si on ne veut pas suivre ces rêgles, il faut changer de branche.
Imaginons qu'un navigateur X non basé sur webkit gagne énormément de part de marché pour X raisons, sur le mobile. Que va-t-il arrivé ? Plein de sites cassés. Parce que des développeurs incompétents n'auront pas fait leur job comme il faut, en utilisant des trucs prefixés ciblant un seul navigateur. Bref, des développeurs comme il y en avait au temps de IE6. Avec les conséquences que l'on connait.
Donc, le « problème » c'est que les développeurs Web essaient de résoudre les besoins qui se posent à eux ?
non le problème c'est que tu ne sais pas lire.
Actuellement, de plus en plus de sites utilisent les propriétés en -webkit-, apportant des facilités. soit. Mais malheureusement, ils n'utilisent pas aussi les propriétés équivalentes en -moz -o etc.. ET donc on en arrive à avoir des sites "optimisés pour webkit". Bref, c'est le nouveau IE6, avec toutes les conséquences que l'on connait.
À cela, il semblerait que des fabricants de navigateurs seraient prêts à nommer leurs propriétés expérimentales en -webkit- plutôt qu'utiliser leur propre prefixe. Comme ce sont en général des propriétés expérimentales, donc sous-spécifiées, ça va être un bordel monstre pour les développeurs (puisqu'on aura forcément des différences de comportements ou de syntaxe d'un navigateur à l'autre).
S'ils se sortaient les doigts du cul pour répondre aux besoins des développeurs, peut-être que ceux-ci n'auraient pas besoin d'extensions.
aheum... Faudrait que tu ailles jeter un coup d'oeil aux specifications en cours de redaction sur le site w3.org, tu verrais que le W3C ne chôme pas.
D'autre part, avec cette réflexion, tu sembles ne pas connaitre le fonctionnement du W3C, alors je vais te l'apprendre : les membres d'un groupe de travail, comme le CSSWG, sont composés... d'employés des sociétés qui fabriquent les navigateurs. Ce sont donc ces sociétés qui écrivent les specs aux W3C. Si le CSSWG n'avance pas assez vite, il ne faut pas s'en prendre au W3C, mais à Apple, MS, Google, Mozilla, Opera etc...
De plus, des gens comme google ou apple, implémentent des propriétés en -webkit-, sans soumettre les spécifications au W3C. Tu veux que le W3C fasse quoi fasse à ça ? Le CSSWG ne va pas deviner tout seul la spécification de telle ou telle nouvelle propriété expérimentale implémentée dans tel navigateur. D'autant plus qu'il y a de fortes chances qu'il y ait des brevets logiciels là dessus. le W3C ne peut qu'attendre après ces sociétés, qu'elles proposent ces specs (les specs proposées deviennent alors royalty free et les brevets qui y seraient éventuellement attachés deviennent "inoffensifs").
Enfin bref, le problème n'est pas totalement du coté du W3C, mais aussi des fabricants de navigateurs, et principalement, au final, des développeurs qui utilisent des trucs pas terminés ou pas standards. et le problème c'est que ce comportement est en train de pourrir leur metier, puisqu'on va arriver à un nouveau problème de type IE6only, mais pire encore...
je viens de comprendre. Il y a deux types de boutons :
si on clique sur les liens "proposer une depeche", à la sauvegarde, ça va directe à la modération
si on trouve puis on clique sur le lien "commencer une nouvelle depeche", ça sauvegarde "en cours de redaction".
à mon avis, quand on va sur "proposer une depeche", il devrait y avoir deux boutons pour la sauvegarde : un pour que ça aille direct à la modération, un autre pour que ça aille "en cours de redaction".
Quand l'utilisateur se trompe de lien, il clique sur le bouton precedent. Le bouton précédent EST TOUJOURS Là, toujours visible ! Et quand ils cliquent sur precedent, le bouton suivant apparait, pour revenir à la page "suivante"
Les mises à jour de Firefox et celles de Thunderbird vont être silencieuses. Donc les utilisateurs s'en foutent.
Chrome est un gros succés, avec pourtant aussi peu de changement d'interfaces entre chaque version. Et pourtant, ses utilisateurs s'en foutent. L'utilisateur lambda veut juste un truc qui marche, pas avoir une liste démesurée de changements régulièrement.
donc parce que 3 abrutis ne se servent pas du bouton précédent,
relis le message. Ils n'ont pas viré le bouton précédent à cause de 3 types, mais à cause de la majorité des utilisateurs (non, Firefox n'a pas seulement 5 utilisateurs).
Ca n'apporte aucun benefice ni en matiere de stabilite (au sens plantages) ni en matiere de securite
Si, au contraire, les mises à jour de l'ESR ne concernent que des bouchages de trous de sécurité, et également des fix pour les crash (en tout cas les plus flagrants je présume).
Génial, les mails en html/flash vont s’afficher plus vite
pas seulement (encore que, vu que le JS est désactivé dans les mails...). C'est surtout l'interface qui va être plus réactive (je te laisse te renseigner sur le XUL...)
mais on à quoi comme améliorations concernant le domaine de la messagerie ?
est-ce qu'il est prévu que Thunderbird évolue un jour,
Tu ne t'en rend même pas compte, mais Thunderbird évolue à chaque version. Il n'y a peut-être pas beaucoup de choses qui se voient, mais il y en a pas mal. En effet, Thunderbird profitent de toutes les évolutions de la plateforme Mozilla, utilisée par Firefox.
Par exemple, ces dernières versions, Thunderbird profite de tous les progrés réalisés dans la consommation de la mémoire, les performances de gecko, mais aussi des progrés réalisés dans le support des styles CSS, du DOM et des performances JS, puisque tout comme Firefox, L'interface de Thunderbird est en XUL, donc utilise CSS, DOM, JS &co à fond les manettes.
Thunderbird a donc grand interet à rester synchro avec Firefox.
Si je comprends bien, un hotfix, c'est une petite correction de comportement qui ne nécessite pas une mise à jour complète, et qui va être téléchargé et installé automatiquement par Firefox, donc sans intervention de l'utilisateur ?
Oui, c'est à peu près ça. En fait c'est l'extension même qui est la correction. Et le fait de la mettre à jour, apporte la modification. Et comme les extensions sont vérifiées toutes les 24h (par défaut), cela leur permet d'apporter une modification en 24h maxi.
Alors que pour les mises à jour traditionnelles, il faut faire un nouveau build, donc passer par toutes les étapes de QA avant de délivrer le build.
Quelle est la différence entre un hotfix et une mise à jour silencieuse, du coup, hormis le +1 sur le numéro de version ? La quantité de code ?
Une mise à jour silencieuse, c'est un nouveau build qui est poussé. Donc effectivement, il y a plus de code. Mais aussi plus de nouveautés. Par exemple, les améliorations dans le moteur de rendu (nouveautés CSS, HTML etc), ne pourront pas être apportés par l'extension hot fix. Ce n'est pas son rôle, et techniquement pas faisable à priori. Hot fix ne concerne que les modifications non binaires (donc modifications des prefs et autres fichiers de conf, les modifications dans l'interface etc..)
une nouvelle fonctionnalité est fourni dans une nouvelle version de Firefox, mais déplait à énormément de monde au final. Hot Fix permettra de la désactiver ou de la corriger (si techniquement c'est faisable via Hot Fix)
necessité de désactiver/supprimer des certificats racines SSL qui sont devenus pourris (comme ça été le cas ces derniers mois). avec Hotfix, ça peut être fait dans les 24h.
gros problèmes causés par des extensions spécifiques ou des plugins : possibilité par HotFix de les désactiver.
possibilité de corriger des bugs qui affectent une langue spécifique. Hot Fix évite d'avoir à sortir une nouvelle version pour tout le monde
necessité de passer un message important aux utilisateurs : affichage d'un bandeau.
les hotfix/mises à jours seront valable pour l'utilisateur en cours, ou necessiteront-ils les droits root ?
Hot fix est une extension, et je ne pense pas qu'elle touchera aux fichiers originaux de firefox (à vérifier). Elle n'agira donc que sur les fichiers du profil utilisateur, si j'ai bien compris.
Comment sera-ce géré par le gestionnaire de paquet d'une distrib ?
C'est lui qui voit. Si il ne veux pas que ses utilisateurs profitent des hotfix, il désactivera l'extension Hot Fix dans le paquet. Sinon il n'a rien à faire.
En tout cas, en entreprise, le maintient de Joomla va être très prise de tête,
En même temps, ceux qui choisissent Joomla en entreprise, n'ont que ce qu'ils méritent. Choisir un truc aussi moisi, tant en terme de sécurité (le nombre de trous de sécurité découvert est impressionnant), qu'en terme de code moisi (aie aie aie, j'ai regardé une fois, ça fait vraiment, vraiment peur), et je ne parle pas de l'ergonomie plus que douteuse, bref, choisir un truc aussi moisi, faut vraiment être inconscient/incompétent pour un truc pro.
Joomla, c'est tout juste bon pour le site perso de madame Michu.
Il est vraiment grand temps que les clients de messagerie instantané libre soient améliorés pour faire du réseau social, en implémentant certaines extensions xmpp.
Parce qu'après tout, qu'est ce twitter ? un client de messagerie instantanée en ligne, avec des fonctions de réseau social. D'ailleurs, bon nombre de clients de messagerie instantanée implémente son protocole.
Et si on veut diffuser ses messages à tout le monde, une petite appli web qui les diffusent, implémentant XMPP pour recevoir les messages (et serait donc un "ami" dans le client de messagerie). On installe son appli web sur son site perso et voilà.
Décentralisation. Protocole standard et distribué. Indépendance du "réseau". Choix du client. Plus de censure.
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.
Donc tu passes 10 fois plus de temps à implémenter un truc (des listeners et autres trucs d'interface), pour un résultat qui n'apporte au final rien en terme de perf (au niveau de l'UI).
disclamer : je fais du xpcom c++ depuis des années...
moui ok, je comprend mieux le principe de ton truc. Mais quand même, comme je dis, ça n'apporte rien en terme de perf, au niveau de l'interface utilisateur, sauf si tu manipules à tour de bras des centaines d’éléments XUL. En tout cas le rapport (productivité, facilité de dev, de maintenance etc)/performance est très très faible.
Pourtant, tout est indiqué sur la doc de la balise tree, https://developer.mozilla.org/en/XUL/tree , en particulier les interfaces qu'elle utilise, et donc ses propriétés dont la view etc. Etant donné que les objets DOM accessibles en JS sont simplement un accés XPCom aux objets C++ correspondant... Et par le passé, XulPlanet.org était encore mieux documenté au niveau des interfaces etc..
Pour être plus productif ? Pour faciliter les contributions ? Pour avoir un outil plus performant ? pour avoir une interface web agréable à utiliser ? (le browser CVS est juste horrible).
M'enfin chacun utilise ce qu'il veut :-)
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à -5.
Je ne parles pas de QuickTime, mais de QT : http://en.wikipedia.org/wiki/Qt_%28framework%29
# Pourquoi pas un autre toolkit ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.
Le but de XulRunner n'est pas un framework/une plateforme pour écrire une appli entièrement en C++.
Pourquoi ne pas utiliser QT ou autre toolkit graphique ?? Parce que si dans ton projet, l'utilisation du JS est à proscrire, tu t'es, à mon avis, trompé de framework.
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.
oui, je me pose exactement la même question. D'après ce que j'ai compris, on n'a plus à utiliser de gestionnaire d'évènement ou autres trucs "webesque" de XulRunner. Et en gros, tout le code de l'appli est dans des libs externes en C/C++.
Et au final aussi, un truc à la XPCom à été recodé en passant par XPCom. Au final on a donc une couche qui transmet des appels vers les libs externe, donc comme XPCom. -> double couche logicielle pour accéder à la lib externe. à moins d'avoir rien compris au bidule :-)
Bon, sinon, de la doc sur XPCOM C++, elle existe quand même https://developer.mozilla.org/en/XPCOM. Et il y a aussi une alternative, pour accéder directement aux fonctions d'une lib : js-ctypes.
(hors sujet: CVS, c'est vraiment pénible, je recommande d'utiliser un gestionnaire de source récent :-p)
[^] # Re: français
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal qy.blog: l'auto hébergement de blog / site Internet à la maison. Évalué à 2.
et pour continuer dans le #fail, quietty.com n'est pas accessible depuis un navigateur web, alors que www.quietty.com, si. Une petite mise à jour DNS et config apache/nginx/autre s'impose ;-)
Bon sinon, l'idée du produit est intéressante. Par contre, il ne faudrait pas que le blog connaisse un succès fou, vu le peu de bande passante en upload qu'on a en ADSL en général.
Un jour peut être, les fournisseurs d’accès nous fournirons des débits symétriques...
[^] # Re: hum...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 6.
Oui il y a cette différence d'ouverture de source et de spec.
Mais il n'y a aucune différence quant à la situation et aux conséquences. Le problème se situe dans l'utilisation de propriété non standards ou experimentales. Tout comme avec IE6, les développeurs utilisent des fonctionnalités qui ne sont implémentées que dans un seul moteur de navigateur (ou qui ne sont interprétables que par un seul moteur de navigateur). Cela conduit donc à un web "optimisé pour", tout comme avec IE6. Le fait que lesdites fonctionnalités soient implémentées sous licence libre ou proprio ne change rien au problème, et encore moins à une éventuel solution. On assiste à nouveau à une balkanisation du web.
[^] # Re: Level : Asian
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Apple = Microsoft + Google. Évalué à 2.
indice. à 00:09, on était vendredi. Et vendredi, c'est le jour des ...
[^] # Re: Please fill out this field
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 3.
oui, c'est une bonne idée. Mais j'ai bien peur qu'il soit trop tard, vu apparemment les centaines de milliers de sites pour mobile qui ciblent webkit..
[^] # Re: Please fill out this field
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 10.
Oui. Tout comme les développeurs peuvent migrer leur code. Mais dans 99% des cas, ils ne le font pas. Parce qu'une fois le site développé, les "vieux" trucs restent. Et parfois très longtemps. Surtout quand ceux qui sont chargés de faire évoluer le site ne sont pas les développeurs initiaux. Il arrive trèèèèès souvent qu'ils ne touchent qu'à ce qu'il y a besoin d'être touché, par manque de temps, par peur de casser des choses, par j'm'enfoutisme etc..
Tu es à coté de la plaque. Les éditeurs implementent les trucs BIEN AVANT de proposer des specs au W3C. C'est pas le W3C qui "fournit".
Non, ce sont les développeurs web qui sont responsables. les propriétés prefixées sont pour la plupart des trucs experimentaux. LES DEVELOPPEURS NE SONT PAS CENSES LES UTILISER. Ou si ils les utilisent, qu'ils aient au moins le courage de mettre les propriétés préfixés pour les autres navigateurs ET de mettre celles sans prefixe, ceci afin de garantir un minimum que leur site fonctionnera PARTOUT et dans la durée.
Un développeur web est censé suivre les standards. C'est son job de faire en sorte que son site (public) soit lisible partout, parce que c'est la nature même du web d'être "agent agnostic". Ne pas le faire est une faute professionnelle selon moi. Ne pas le faire, c'est ne pas suivre les "rêgles" du WEB. Si on ne veut pas suivre ces rêgles, il faut changer de branche.
Imaginons qu'un navigateur X non basé sur webkit gagne énormément de part de marché pour X raisons, sur le mobile. Que va-t-il arrivé ? Plein de sites cassés. Parce que des développeurs incompétents n'auront pas fait leur job comme il faut, en utilisant des trucs prefixés ciblant un seul navigateur. Bref, des développeurs comme il y en avait au temps de IE6. Avec les conséquences que l'on connait.
[^] # Re: Please fill out this field
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 7. Dernière modification le 09 juillet 2020 à 19:35.
Un bel article pour mieux comprendre le problème
http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/NdM: lien cassé remplacé par https://www.wired.com/2012/02/webkit-isnt-breaking-the-web-you-are/[^] # Re: Please fill out this field
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 10.
non le problème c'est que tu ne sais pas lire.
Actuellement, de plus en plus de sites utilisent les propriétés en -webkit-, apportant des facilités. soit. Mais malheureusement, ils n'utilisent pas aussi les propriétés équivalentes en -moz -o etc.. ET donc on en arrive à avoir des sites "optimisés pour webkit". Bref, c'est le nouveau IE6, avec toutes les conséquences que l'on connait.
À cela, il semblerait que des fabricants de navigateurs seraient prêts à nommer leurs propriétés expérimentales en -webkit- plutôt qu'utiliser leur propre prefixe. Comme ce sont en général des propriétés expérimentales, donc sous-spécifiées, ça va être un bordel monstre pour les développeurs (puisqu'on aura forcément des différences de comportements ou de syntaxe d'un navigateur à l'autre).
aheum... Faudrait que tu ailles jeter un coup d'oeil aux specifications en cours de redaction sur le site w3.org, tu verrais que le W3C ne chôme pas.
D'autre part, avec cette réflexion, tu sembles ne pas connaitre le fonctionnement du W3C, alors je vais te l'apprendre : les membres d'un groupe de travail, comme le CSSWG, sont composés... d'employés des sociétés qui fabriquent les navigateurs. Ce sont donc ces sociétés qui écrivent les specs aux W3C. Si le CSSWG n'avance pas assez vite, il ne faut pas s'en prendre au W3C, mais à Apple, MS, Google, Mozilla, Opera etc...
De plus, des gens comme google ou apple, implémentent des propriétés en -webkit-, sans soumettre les spécifications au W3C. Tu veux que le W3C fasse quoi fasse à ça ? Le CSSWG ne va pas deviner tout seul la spécification de telle ou telle nouvelle propriété expérimentale implémentée dans tel navigateur. D'autant plus qu'il y a de fortes chances qu'il y ait des brevets logiciels là dessus. le W3C ne peut qu'attendre après ces sociétés, qu'elles proposent ces specs (les specs proposées deviennent alors royalty free et les brevets qui y seraient éventuellement attachés deviennent "inoffensifs").
Enfin bref, le problème n'est pas totalement du coté du W3C, mais aussi des fabricants de navigateurs, et principalement, au final, des développeurs qui utilisent des trucs pas terminés ou pas standards. et le problème c'est que ce comportement est en train de pourrir leur metier, puisqu'on va arriver à un nouveau problème de type IE6only, mais pire encore...
# proposition
Posté par Laurent J (site web personnel, Mastodon) . En réponse à l’entrée du suivi pas possible de sauver une dépêche "en cours de redaction". Évalué à 3 (+0/-0).
je viens de comprendre. Il y a deux types de boutons :
à mon avis, quand on va sur "proposer une depeche", il devrait y avoir deux boutons pour la sauvegarde : un pour que ça aille direct à la modération, un autre pour que ça aille "en cours de redaction".
[^] # Re: Vous l'avez vécue la vie de développeur de logiciel?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mégaupload fermé, tant mieux ! Je suis comédien, mes films ne sont pas gratuits. Évalué à 7.
mmm... je crois que son post était très ironique ;-)
[^] # Re: Euh
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 10 est sorti, accompagné de Thunderbird 10, Lightning 1.2 et Firefox mobile 10. Évalué à -1.
Hey, vendredi, c'est après demain.
Quand l'utilisateur se trompe de lien, il clique sur le bouton precedent. Le bouton précédent EST TOUJOURS Là, toujours visible ! Et quand ils cliquent sur precedent, le bouton suivant apparait, pour revenir à la page "suivante"
[^] # Re: Ah les numéros de version...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 10 est sorti, accompagné de Thunderbird 10, Lightning 1.2 et Firefox mobile 10. Évalué à 4.
Les mises à jour de Firefox et celles de Thunderbird vont être silencieuses. Donc les utilisateurs s'en foutent.
Chrome est un gros succés, avec pourtant aussi peu de changement d'interfaces entre chaque version. Et pourtant, ses utilisateurs s'en foutent. L'utilisateur lambda veut juste un truc qui marche, pas avoir une liste démesurée de changements régulièrement.
[^] # Re: Euh
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 10 est sorti, accompagné de Thunderbird 10, Lightning 1.2 et Firefox mobile 10. Évalué à 3.
relis le message. Ils n'ont pas viré le bouton précédent à cause de 3 types, mais à cause de la majorité des utilisateurs (non, Firefox n'a pas seulement 5 utilisateurs).
[^] # Re: Et pour ESR ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 10 est sorti, accompagné de Thunderbird 10, Lightning 1.2 et Firefox mobile 10. Évalué à 4.
Si, au contraire, les mises à jour de l'ESR ne concernent que des bouchages de trous de sécurité, et également des fix pour les crash (en tout cas les plus flagrants je présume).
[^] # Re: Ah les numéros de version...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 10 est sorti, accompagné de Thunderbird 10, Lightning 1.2 et Firefox mobile 10. Évalué à 3.
pas seulement (encore que, vu que le JS est désactivé dans les mails...). C'est surtout l'interface qui va être plus réactive (je te laisse te renseigner sur le XUL...)
Des corrections de bugs et quelques améliorations apparement. https://bugzilla.mozilla.org/buglist.cgi?order=Importance&resolution=FIXED&classification=Client%20Software&query_format=advanced&product=Thunderbird&target_milestone=Thunderbird%2010.0
Je ne sais pas si TB10 est ESR, mais en tout cas, ce n'est pas oublié http://blog.mozilla.com/thunderbird/2012/01/12/the-plan-for-a-mozilla-thunderbird-extended-support-release/
[^] # Re: Septième sens
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Libération du sixième sens. Évalué à 3.
Je ne pense pas qu'il faille inclure l'équilibre dans la liste des sens que tu as indiqué. En tout cas wikipédia n'y fait pas référence http://fr.wikipedia.org/wiki/Sens_%28physiologie%29 .
[^] # Re: Ah les numéros de version...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 10 est sorti, accompagné de Thunderbird 10, Lightning 1.2 et Firefox mobile 10. Évalué à 1.
Tu ne t'en rend même pas compte, mais Thunderbird évolue à chaque version. Il n'y a peut-être pas beaucoup de choses qui se voient, mais il y en a pas mal. En effet, Thunderbird profitent de toutes les évolutions de la plateforme Mozilla, utilisée par Firefox.
Par exemple, ces dernières versions, Thunderbird profite de tous les progrés réalisés dans la consommation de la mémoire, les performances de gecko, mais aussi des progrés réalisés dans le support des styles CSS, du DOM et des performances JS, puisque tout comme Firefox, L'interface de Thunderbird est en XUL, donc utilise CSS, DOM, JS &co à fond les manettes.
Thunderbird a donc grand interet à rester synchro avec Firefox.
[^] # Re: lapin compris
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 10 est sorti, accompagné de Thunderbird 10, Lightning 1.2 et Firefox mobile 10. Évalué à 5.
Oui, c'est à peu près ça. En fait c'est l'extension même qui est la correction. Et le fait de la mettre à jour, apporte la modification. Et comme les extensions sont vérifiées toutes les 24h (par défaut), cela leur permet d'apporter une modification en 24h maxi.
Alors que pour les mises à jour traditionnelles, il faut faire un nouveau build, donc passer par toutes les étapes de QA avant de délivrer le build.
Une mise à jour silencieuse, c'est un nouveau build qui est poussé. Donc effectivement, il y a plus de code. Mais aussi plus de nouveautés. Par exemple, les améliorations dans le moteur de rendu (nouveautés CSS, HTML etc), ne pourront pas être apportés par l'extension hot fix. Ce n'est pas son rôle, et techniquement pas faisable à priori. Hot fix ne concerne que les modifications non binaires (donc modifications des prefs et autres fichiers de conf, les modifications dans l'interface etc..)
Par exemple, des exemples de cas gérés par Hotfix (que j'ai repris de https://wiki.mozilla.org/Features/Desktop/Add-on_hotfix ):
etc..
Pour plus de détails voir https://wiki.mozilla.org/Features/Desktop/Add-on_hotfix
Hot fix est une extension, et je ne pense pas qu'elle touchera aux fichiers originaux de firefox (à vérifier). Elle n'agira donc que sur les fichiers du profil utilisateur, si j'ai bien compris.
C'est lui qui voit. Si il ne veux pas que ses utilisateurs profitent des hotfix, il désactivera l'extension Hot Fix dans le paquet. Sinon il n'a rien à faire.
[^] # Re: Euh
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 10 est sorti, accompagné de Thunderbird 10, Lightning 1.2 et Firefox mobile 10. Évalué à 1.
Tu aurais dû parié plus, puisque tu as gagné ;-)
Par contre je ne sais pas qui doit t'envoyer la clef à molette :-)
[^] # Re: xmpp
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Twitter et les politiques de censure.. Évalué à 2.
pour que tu puisses publier tes messages en public, même à ceux qui n'ont pas xmpp, ou qui ne te savent pas si tu es sur xmpp ou pas...
[^] # Re: De 1.7 vers 2.5
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche CMS : Joomla 2.5.0 est sorti ce mardi 24 janvier. Évalué à 1.
En même temps, ceux qui choisissent Joomla en entreprise, n'ont que ce qu'ils méritent. Choisir un truc aussi moisi, tant en terme de sécurité (le nombre de trous de sécurité découvert est impressionnant), qu'en terme de code moisi (aie aie aie, j'ai regardé une fois, ça fait vraiment, vraiment peur), et je ne parle pas de l'ergonomie plus que douteuse, bref, choisir un truc aussi moisi, faut vraiment être inconscient/incompétent pour un truc pro.
Joomla, c'est tout juste bon pour le site perso de madame Michu.
# xmpp
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Twitter et les politiques de censure.. Évalué à 9.
Il est vraiment grand temps que les clients de messagerie instantané libre soient améliorés pour faire du réseau social, en implémentant certaines extensions xmpp.
Parce qu'après tout, qu'est ce twitter ? un client de messagerie instantanée en ligne, avec des fonctions de réseau social. D'ailleurs, bon nombre de clients de messagerie instantanée implémente son protocole.
Et si on veut diffuser ses messages à tout le monde, une petite appli web qui les diffusent, implémentant XMPP pour recevoir les messages (et serait donc un "ami" dans le client de messagerie). On installe son appli web sur son site perso et voilà.
Décentralisation. Protocole standard et distribué. Indépendance du "réseau". Choix du client. Plus de censure.