Laurent J a écrit 2938 commentaires

  • [^] # Re: Gros trou de sécu

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Deux extensions originales pour Firefox. Évalué à 5.

    ce trou existe avec l'extension.

    Elle devrait redemander le mot de passe principal pour afficher les mots de passe. Actuellement, elle peut récupérer les mots de passe parce que j'ai déjà tapé mon mot de passe principal. Mais elle devrait redemander ce mot de passe pour afficher. Comme le fait le gestionnaire de mot de passe. Que tu ais déjà tapé ou non le mot de passe principal en début de session, le gestionnaire te redemande le mot de passe principal, pour s'assurer que c'est bien toi qui veut voir TES mots de passe (et pas un gars qui squate ton PC pendant une absence de quelques minutes par exemple).

  • # Gros trou de sécu

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Deux extensions originales pour Firefox. Évalué à 5. Dernière modification le 16 février 2012 à 10:22.

    Aie aie aie.. Pour ceux qui ont un mot de passe principal, je vous recommande de désinstaller l'extension password reuse visualizer. Cette extension ne demande même pas le master password avant d'afficher les mots de passes, comme le fait le gestionnaire de mot de passe.

    Pour moi, ça craint...

  • [^] # Re: Pourquoi pas un autre toolkit ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.

    de peur de se prendre une soufflante du père Glazman

    pas du tout. Daniel n'a que peu d'influence sur les décisions de Mozilla depuis quelques années. Mozilla ne laisse pas mourrir XulRunner, pour la simple raison que Firefox est basé dessus. Mais Mozilla ne met plus en avant XulRunner, parce qu'ils ne veulent pas dépenser leur énergie sur ce projet en terme de dev, marketing et autre. S'occuper d'un produit de la nature de XulRunner, c'est s'occuper à essayer de résoudre toutes les problématiques des développeurs utilisant cette plateforme, problématiques qui ne rentreraient pas dans les objectifs actuels de Mozilla. Ils préfèrent se concentrer sur la plateforme purement web. Ils bossent ainsi sur la plateforme XUL, uniquement pour répondre à leurs besoins (à ceux de Firefox, TB et autres), et non aux besoins des autres.

    Maintenant il y a pas mal de "cinglés" comme moi qui utilisent XulRunner et gecko pour leurs projets, parce qu'ils trouvent cette plateforme géniale malgré ses défauts.

    De plus, vu que XulRunner n'est qu'un main() un poil différent de celui de firefox, et ne contient pas les fichiers XUL/JS/CSS de firefox (en gros), refaire un XulRunner ne serait pas compliqué. Le seul moyen pour Mozilla de tuer XulRunner, serait de tuer XUL et tout ce qui va avec (système d'overlay etc). Ce qui n'est pas près d'arriver...

  • [^] # Re: Pourquoi pas un autre toolkit ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 3.

    Je ne vois en quoi le fait que ce ne soit pas le but devrait m'empêcher de le faire...

    Certes. Mais tu t'embarques dans un truc pas adapté, donc qui te prend 10 fois plus de temps à réaliser que si tu utilisais des outils plus adaptés. C'est comme si tu utilisais un rateau pour faire un trou, alors que si tu utilisais une pelle, tu serais plus efficace.

    En prenant un toolkit 100% C++ (puisqu'il semble que ce soit ton langage de prédilection), comme Qt, tu pourrais te concentrer plus sur les éléments de ton framework plutôt que sur des contournements de la plateforme...

    d'autant plus si l'on n'a aucune affinité avec JavaScript...

    Oui donc tu t'es trompé de plateforme à mon sens...

    Si j'ai choisi XUL pour de nombreux développements (depuis des années), c'est bien pour le coté "web" de la plateforme (donc XML/XUL/CSS ET Javascript). Si je voulais faire une appli entièrement en C++, je ne choisirais certainement pas XULRunner...

  • [^] # Re: Intérêt

    Posté par  (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.

    Toute la partie description de l'interface reste en XUL...

    le fait que tu n'utilises plus JS enlève une grande partie de l'intérêt de la plateforme selon moi (dev rapide, maintenance et evolution plus aisées etc..)

  • [^] # Re: Intérêt

    Posté par  (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.

    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).

    M'enfin chacun utilise ce qu'il veut :-)

  • [^] # Re: Pourquoi pas un autre toolkit ?

    Posté par  (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  (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.

    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.

  • [^] # Re: Intérêt

    Posté par  (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  (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  (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  (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  (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  (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 10.

    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.

  • [^] # Re: Please fill out this field

    Posté par  (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  (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 10.

    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...

  • # proposition

    Posté par  (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 :

    • 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".

  • [^] # Re: Vous l'avez vécue la vie de développeur de logiciel?

    Posté par  (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  (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  (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  (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.

    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).

  • [^] # Re: Et pour ESR ?

    Posté par  (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.

    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).

  • [^] # Re: Ah les numéros de version...

    Posté par  (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.

    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 ?

    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

    La version 10 est ESR elle aussi ou on oublie pour déployer en entreprise ?

    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  (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  (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.

    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.