Laurent J a écrit 2933 commentaires

Toujours pour des questions de perfs.

Et j'ai oublié : aussi pour des questions de zooming. C'est rapide et simple. Sur les petits écrans, avoir un bon zooming est critique, et un système à tuile est très bien pour ça.

Oui, il ne faut pas tabler là-dessus, mais, connaissant particulièrement bien le projet, j'ai conscience de la quantité phénoménale de travail qu'il faut pour se débarrasser de XUL dans Firefox. En premier lieu : réécrire toute l'interface utilisateur (en html ?). Et si en html, créer de toutes pièces ce qu'il manque à HTML pour combler le gap avec XUL (et il y en a des choses à créer !!).

Alors à moins qu'un miracle arrive et que Mozilla puisse mettre 200 développeurs à temps complet rien que sur cette problématique (impossible à priori), pour arriver à proposer un firefox sans XUL dans un an minimum, j'estime que ça n'arrivera pas avant 3-4 ans. Sans compter le possible recul de la date d'interdiction d'installations des addons XUL.

Pour le reste de tes arguments : je n'ai pas dit le contraire. Je n'ai pas dit que les développeurs d'applis XUL ne devaient rien faire. Je pense même que les principaux intéressés (dont certains de mes clients), sont parfaitement conscient du problème (il y a longtemps que j'ai expliqué ceci à mes clients) et même que certains sont en train de préparer l'avenir .

J'ai simplement voulu dire qu'il n'y a pas d'affolement à avoir, et qu'il est encore grand temps de penser le futur de ces applis XUL.

Le rendu par tuile est en fait plus courant que tu ne le crois.

Par exemple Firefox pour Android utilisait à ces débuts un système de tuilage pour afficher les pages web, à cause du manque de perf (pendant le scrolling entre autre). La page web était donc rendue dans une fenêtre non affichée (genre dans un element iframe), et un element html canvas était utilisé pour le rendu à l'utilisateur, en utilisant un système de tuiles générée à partir du rendu de la fenêtre cachée. Et donc tout ça fait en JS :-). (On pouvait parfois se rendre compte de ce système de tuiles, quand Gecko mettait trop de temps à afficher les tuiles : on voyait alors brièvement un damier à la place des tuiles retardataires)

Maintenant, Gecko a un système de rendu par tuile en natif. Et malgré que le moteur de rendu de Gecko soit plus performant qu'à l'époque, le tuilage est toujours utilisé dans Firefox pour Android, et dans FirefoxOS pour afficher les pages web. (dans le about:config, preférence layers.enable-tiles). Toujours pour des questions de perfs.

Il y a eu en effet une forte mise en avant de XUL quand Mozilla a sorti XULRunner. Mais cette mise en avant a plutôt été faite par la communauté. À l'époque, c’était un truc plutôt expérimental chez Mozilla, mais il y a eu un engouement fort de la part de beaucoup de développeurs pour ce XULRunner (dont moi-même, et je suis probablement responsable de cet engouement en France avec xulfr.org) : on pouvait créer très facilement des applis en XUL et les livrer indépendamment de Firefox (donc pas comme une extension). Et il y a eu de ce fait beaucoup d'application utilisant XULRunner (ou basé sur un XULRunner modifié/recompilé).

Même si chez Mozilla il y avait au début une roadmap pour livrer des versions stables de XulRunner (laissant présager un suivi sur le long terme), je pense, avec le recul, que Mozilla a été surpris du succès, et qu'ils se sont rendu compte que ce succès ne convenait pas pour l'évolution de Gecko (obligé d'avoir des API gelées pour pas casser les autres softs par exemple). C'est pourquoi ils n'ont jamais fait de XulRunner un produit (comme pouvait l'être à l'époque un concurrent comme Adobe Air), et ils ont arrêté de dépenser de l'énergie sur XulRunner. Tout juste a-t-il été maintenu, avec des releases pour chaque nouvelle version de Gecko (grossièrement, XULRunner n'est qu'un main() autour de Gecko), mais ça suffisait pour les développeurs d'applis existantes.

Je crois que tu a raté quelque chose d'important : XUL c'est fini.

Je n'ai rien raté du tout. C'est moi-même qui a écrit le billet que tu pointes ;-)

XUL c'est fini, certes. Il serait, d'un point de vue industriel, illogique de vouloir faire une appli ou extension en XUL de nos jours. Mais la prise en charge de XUL dans Gecko et la prise en charge des extensions XUL sont deux choses différentes. Alors que la deuxième va disparaitre dans quelques mois (à priori), la première va mettre à mon avis quelques années à disparaitre de Firefox (le chantier est titanesque, pour remplacer tout ce qui est en XUL) et encore plus de Gecko à cause de Thunderbird et autre (un flag de compilation fera je pense la différence, comme il a existé par le passé). Donc on va pouvoir faire fonctionner les applis xul existantes pendant quelques temps encore. Ça laisse le temps de migrer vers d'autres technologies alternatives.

Oui cette extension ne fonctionnera plus, car je vois mal comment l'API de webextension va apporter les nombreuses possibilités que nécessite SQliteManager (entre autre, accéder à toute l'API pour attaquer une base SQLite….).

Il n'y a qu'une solution pour cette extension : être lancée comme toute application XUL. Et ça tombe bien, il y a un application.ini dans les sources. Ce qui veut dire que Sqlite Manager continuera à fonctionner avec Firefox, non pas en l'installant comme extension, mais en le lançant directement avec firefox --app sqlite-manager/application.ini. Il est possible aussi de le lancer avec XulRunner, mais c'est un programme qui est désormais mort : il n'y aura pas de XulRunner 41 et supérieur.

À noter aussi que Sqlite Manager est dispo comme extension pour l'éditeur Komodo et Thunderbird.

Alors je dis pas, une assoce/fondation peut aussi mal tourner, elle peut aussi fermer, etc. Mais les chances sont moindres car c'est normalement fait de telle sorte que les raisons que cela se produisent sont plus faibles.

Oh que non. De mon expérience, quand une association fonctionne bien, c'est souvent qu'il y a un noyau dur de personnes qui soutiennent le truc à fond, et souvent donc, tout repose sur ces personnes, même si il y a de nombreux membres. Et souvent le noyau dur ne se résume qu'à 2-3 personnes, qui ont le don d'être motivant, entrainant etc.. Qu'une de ces personnes du noyau dur parte (pour n'importe quel raison), et c'est la vie de l'association qui peut changer du tout au tout. Voir "mourir". Remplacer la personne "charismatique" qui part, c'est beaucoup plus difficile pour une association que pour une boite : la carotte est beaucoup moins grosse (pas de contrepartie financière souvent, donc il faut que le remplaçant soit vraiment motivé et ait suffisamment de temps pour s'en occuper).

j'ai un bon exemple en tête : l'apinc. Je ne sais pas où ça en ait aujourd'hui, mais quand j'étais membre il y a quelques années, l'association a connu des bas (moins de gens pour aider par exemple, le noyau dur moins motivé, moins de temps libre pour faire avancer le truc), et ces périodes n'ont pas été roses : des serveurs en panne, des services à la ramasse, par manque de temps, de budget etc (sans compter les délais pour aller au data-center pour aller changer un disque ou autre).

Bref, au final, une association c'est de mon point de vue, tout aussi fragile qu'une entreprise, voir même plus car au moins dans une boite qui fait de l’hébergement, tu as toujours des employés à plein temps pour gérer les machines, ce qui n'est pas le cas pour une association.

PS. d'ailleurs je ne raconte pas de conneries : L'apinc arrete l'hebergement web. Pas assez de moyens, pas assez de bras, pour offrir un service qui soit l'équivalent des offres commerciales en terme de qualité de service.

Pardonnez-moi cette question, mais quelle est la meilleur façon de rendre persistent tout ça, c'est à dire que ça se reconfigure automatiquement à chaque démarrage ? (sur ubuntu par ex)

Ça fait des années que Firefox inclus des services de google (anti-pisching, moteur de recherche) etc. Ça change quoi d'intégrer un service de plus ? Qui plus est désactivable ?

oui et non. Il y a 3 types d'extensions :

• les extensions XUL classique : accés aux api internes, au DOM XUL de l'interface, et on peut utiliser le système d'overlay pour ajouter des éléments XUL (on écrit donc du XML XUL pour injecter des boutons ou autre dans l'interface).
• les extensions XUL sans redemarrage : idem que extensions XUL classique, sauf qu'on ne peut pas utiliser le système d'overlay (de manière automatique). Mais on peut encore accéder au DOM XUL directement.
• les extensions faites avec le SDK : pure JS, exécutées dans une sandbox, avec accès à une API cachant les API internes, et permettant de modifier l'interface sans toucher directement au DOM. Exemple : une API pour "ajouter un bouton dans la toolbar". Avantage : que l'interface soit faite en XUL, HTML ou Java (pour Android), l'extension peut fonctionner. Inconvénient : beaucoup moins de liberté dans la modification de l'interface. Mais pour 90% des extensions, ce n'est pas embêtant.

Est-ce qu'il y a des cas qu'on ne peut que traiter avec un générateur?

je n'en ai pas en tête.

Mais, dans ton cas où tu implémentes ta fonction forEach, syntaxiquement, ce n'est pas reconnu par JS comme étant un générateur, quand bien même ton forEach serait "lazy". Ton forEach n'est pas une manière standard de faire un Iterateur.

D'ailleurs avec ton implementation de forEach pour les nombres premiers, je ne suis pas vraiment fan. Par exemple, je veux récupérer les 10 premiers nombres premiers. Je suis obligé de faire

var primes = createPrimes();
var i = 10;
var sum = 0;
try {
   primes.forEach(function (np){
       // do something with np
       sum += np;
       // finished ?
       if (--i == 0) {
           throw new Error("stop")
       }
   });
}
catch(e){
   // ne pas oublier le catch, sinon...
}

Alors que si createPrimes() retournait un iterateur ou génerateur

var primes = createPrimes();
var i=0;
var sum = 0;
var np = primes.next();
while ( --i>0 && !np.done){
    // do something with np
    sum += np.value;
    // next...
    np = primes.next();
}

Pour moi la solution avec iterateur/générateur me semble plus compacte et lisible…

Le problème de l'implémentation de ton objet séquence, c'est que ta séquence ne fonctionnera pas avec Map, WeakMap, Set etc.

Implémenter une méthode forEach sur un objet représentant une séquence, ne le fait pas reconnaitre pour autant comme une séquence JS, et donc ne le rend pas utilisable avec les fonctions/structures syntaxiques manipulant des itérables. Concrètement, l'objet "itérable" peut se faire ainsi passer pour un Array. Par contre un objet simple implémentant foreach, non.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols

En d'autres termes, Iterable et Iterator spécifie une manière standard de faire des objets iterables. Tu peux voir ça comme une interface. Un peu comme en PHP (et d'autres langages…), où un objet qui implémente l'interface Iterator, peut être passé à toutes les fonctions qui manipulent des array.

En plus l'intérêt de la deuxième forme est qu'on peut implémenter facilement le forEach pour éviter d'avoir un état mutable dans sequence ce qui permet de partager la valeur entre plusieurs threads sans se casser la tête. La forme avec yield n'a pas cet avantage.

yield n'est pas obligatoire pour faire un Iterable en JS. Ton objet peut être imutable. Tout ceci dépend de ton implementation.

Je ne vois aussi pas trop l'intérêt des itérables, puisque JavaScript est un langage fonctionnel et que la bibliothèque standard propose des tableaux qui savent faire reduce ou forEach la fonctionnalité des itérables me semble un peu superflue, et demande de comprendre des nouveaux concepts (comment marche le 'yield') alors qu'utiliser reduce ou forEach rentre dans le cadre normal du langage.

L’intérêt c'est de rendre un objet qui puisse être parcouru comme un tableau, et donc qu'on puisse en donner une instance à du code qui sait itèrer sur un tableau classique. Cela encapsule donc la manière dont sont structurées les données de l'objet, et le code utilisateur n'a ainsi pas besoin de connaître cette structure pour itérer sur les "éléments" de l'objet.

Quant à connaitre l'utilisation de yield (et par conséquent les générateurs), il est important d'en comprendre le concept : cela permet de générer une liste d’élément à la demande : si on itère sur une liste d'éléments, on génère juste les éléments demandées, et pas toute une liste dont on n'est pas sûr qu'elle soit entièrement utilisée. Cela peut faire donc économiser énormément de mémoire et de traitements.

D'autres préféreront être hyper configurables, ce qui nécessite de proposer une foultitude d'options, et a pour conséquence d'être plus difficiles à prendre en main (KDE).

Sérieusement, tu as regardé les dernières montures de KDE avec plasma ? Franchement le temps où les panneaux de config de KDE étaient des tableaux de bords de Boeing 747, c'est fini.

Faut arrêter avec les "KDE plus difficile à prendre en main". C'est juste totalement faux aujourd'hui. Bien au contraire.

Je ne place pas FireFoxOs dans la même catégorie car il se place clairement sur le bas de gamme et tente de s'imposer dans les non occidentalisé

La stratégie de Mozilla à ce sujet a changé il y a peu. Ils ont annoncés qu'ils vont se tourner vers des téléphones plus performant, et donc se tourner vers des marchés "plus riches".

tous vos correspondants pourront lire vos messages sans effort

bah non justement, ça devient au contraire bien plus casse gueule.

Transformer un texte en image, c'est une très mauvaise idée pour l'accessibilité (et l'accessibilité n'est pas réservé qu'aux aveugles).

Ton texte en image devient vite illisible si on veut zoomer dessus (parce qu'il faudra alors jouer avec les barres de défilement), ou si on veut le faire lire par lecteur d'écran (obligé de faire de l'OCR dessus…).

Et il y a les problèmes de l'impression (image trop étroite ou trop large -> retaillage ou découpage sur plusieurs pages), de la citation du contenu en dehors du client mail (obligé de tout recopier, c'est d'un pratique…) etc..

Tiens d'ailleurs, pour répondre "en ligne" (donc en découpant le texte) : impossible.

Et puis ça ne doit pas être drôle de recevoir un nième mail d'une discussion, avec tout l'historique : l'image va être "un peu" lourde… Super l'image de 800 x 15000 \o/.

Bref, cela a bien plus d’inconvénients que tu ne le crois, tout en ne résolvant pas le problème de la confidentialité (OCR..)

Par contre qu'est-ce qu'il y a à reprocher aux autres que tu cites ?

Ils font des "bundles". Ils empaquettent donc les softs dans leur propre installateur qui va installer le logiciel et des merdes d'adware et cie.

Ni toi.

Perso moi si. (et mon passe-temps n'est pas la mécanique).

Et personne ne prétend que ce soit nécessaire pour utiliser une automobile.

Un peu quand même, si on ne veut pas être en infraction (la nuit) : http://vosdroits.service-public.fr/particuliers/F19459.xhtml

il n'est pas obligatoire d'avoir une boîte d'ampoules dans le véhicule, mais il faut pouvoir changer immédiatement une ampoule défectueuse sous peine d'être sanctionné en cas de contrôle.

Les deux parties de la phrase sont en contradiction selon moi, car si il faut pouvoir changer immédiatement une ampoule, il faut pouvoir en avoir des neuves sous la main. Et il faut donc aussi savoir changer l'ampoule.

C'est con ces petites choses mine de rien. Mais ça peut tuer…

C'est vraiment n'importe quoi ce gouvernement.

Je rappelle qu'une majorité de députés, de gauche comme de droite ont voté pour cette loi. (et ça va être pareil au sénat).

s/ce gouvernement/cette classe politique.

Avant de mettre du Rust dans Firefox OS, il devraient débugguer la pile réseau, mon geeksphone révolution m'affiche parfois 4 barres et la 3G alors qu'il n'a pas de réseau,

C'est probablement à Geeksphone qu'il faut aller te plaindre. Ils ne maintiennent pas beaucoup leurs OS, et leurs drivers sont pas tip top. Plus je met à jour mes 2 geeksphone, plus ça plante (ce qui n'est pas le cas avec mon flame par exemple).

Et puis c'est peut être aussi juste un bug graphique. Par exemple, sur mon flame (en FxOS 2.1), la barre du haut (où est affichée l'état du réseau) n'est pas toujours à jour. Il semble en effet qu'il y ait 2 barres: une pour le desktop, et une autre pour toutes les applications. Celle du desktop est toujours ok, alors que celle affichée quand tu es dans une appli ne l'est pas toujours.

Je confirme, les avancées sur Servo sont très rapides. Et maintenant que Rust 1.0 est sortie, ça va être un peu plus rapide puisqu'ils auront moins de changement de syntaxe ou autre à faire :-)

Le blog de Servo est une mine d'information.

L'intégration dans Firefox a commencé. Les développeurs de Servo font le maximum pour découper le moteur en lib indépendantes. Ainsi le parseur d'URL est en cours d'intégration dans Firefox. C'est une petite lib, peu importante, mais ça va permettre de poser les bases dans le build system de Firefox (builder du code Rust) et d'expérimenter l'intégration d'une lib Rust dans ce grosse base de code C++ qu'est Gecko.

Et puis maintenant ils peuvent builder Servo pour Gonk, le linux de FirefoxOS. Ça promet !!

PS: par contre je suis étonné que ce ne soit pas plus haut pour les 5 employés les mieux payés. J'aurai parié plus à ce niveau (quoique, il y a la part "other compensation").

Peut-être parce qu'ils sont aussi employés par Mozilla Corp ? (je ne sais pas, à vérifier). Ici ce sont les salaires des membres de la fondation. Pas de la MoCo. Or c'est la MoCo qui emploie la plupart des personnes qui bossent sur Mozilla. La MoFo n'est qu'une coquille autour de la MoCo (100% du capital de la MoCo est détenu par la MoFo).

mais par contre la représentante d'une organisation à but non lucratif, bon, ça la fout mal.

Pourquoi faudrait-il que, parce que c'est une organisation à buts non lucratifs, les salariés soient payés au lance pierre ?

Si elle est payée autant, c'est parce que Mozilla en a les moyens.

Et sinon, parmi les mieux payés, c'est aussi la plus ancienne de Mozilla. C'est la co-fondatrice du projet Mozilla, co-fondatrice de l'organisation Mozilla en 1999. Mitchell Baker est l'incarnation de Mozilla.

Bref, ancienneté, tout ça…

Faudrait comparer à d'autres organisation non lucratives, ayant autant de revenu, dans le meme pays.

Ou filer un cadeau de noël de 160$ à chacun des 5.000 bénévoles qui bossent pour Mozilla,

1) Un bénévole, ça ne "bosse" pas. ça contribue. Franchement, quand je contribue à un logiciel libre, à Mozilla, je n'ai pas l'impression de bosser. Je fais ça parce que ça m'amuse et que j'apprends plein de trucs. Et que finalement, sans le vouloir, ça me rapporte aussi de l'argent, parce que ça m'apporte des clients.

2) les contributeurs sont régulièrement invités, tout frais payés à des summits qui peuvent se passer à l'autre bout du monde. L'occasion pour beaucoup de voyager la première fois.

surtout quand on compte sur plein de contributeurs à $0/an

Je ne comprends pas ton raisonnement là.

Si on contribue à un projet libre, ce n'est pas pour l'argent, mais pour plein d'autres raisons.

Sur le noyau linux, sur les distro et que sais-je aussi, il y a aussi plein de contributeurs qui sont bénévoles. Et ils le font pour d'autres motifs que l'argent. Linus Torvalds gagne probablement autant voir plus que Mitchell Baker. Et payé lui aussi par une fondation. Et pourtant je n'ai lu ici personne ici se plaindre.

POURQUOI TOUJOURS TOUT RAMENER À L'ARGENT ??

Et puis je t'ai déjà répondu à ce genre de remarques : les contributeurs de Mozilla sont particulièrement choyés par rapport à d'autres projets. Invités (et tous !) à des Summit à l'autre bout du monde (tout frais payés) par exemple.

Qt qui fleurte avec le proprio

Faut bien vivre ma bonne dame.

Ils ont des fonctionnalités payantes, et ? Cela t’empêche t-il d'utiliser Qt dans son ensemble ? Est ce que lesdites fonctionnalités étaient en open source avant ?

KDE qui a cassé presque toutes ses bonnes applications,

J'utiliser KDE depuis des années, je n'ai vu que des améliorations. En meme temps, je n'utilise pas tout dans KDE (Kontact et cie). Et j’apprécie énormément le dernier KDE (kubuntu, et j'ai pas de pub ;-)).