rien n'empêchera de faire un Firefox Desktop avec browser.html ou équivalent.
J'ai bon ?
tout à fait.
Qui plus est, si ces API sont standardisées (ce qui est le but ultime de mozilla), que le format "webapp" est lui aussi standardisé, et tout ça implémenté dans d'autres moteurs, on pourrait imaginer à terme lancer notre browser.html avec blink ou webkit par exemple.
Mais il y a encore beaucoup de chemin à parcourir, malgré que l'on puisse dés aujourd'hui lancer une webapp indifféremment avec Firefox desktop, Firefox pour Android ou encore FirefoxOS (sauf si ladite appli utilise les api de téléphonie par exemple : ça va moins bien fonctionner sur le desktop :-)).
Grâce à cette discussion je viens de découvrir SlimerJS. Je ne savais même pas que ce genre d'outil existait, faudra que je test à l'occasion pour les units test dans au moins 1 projet. Donc encore une fois merci
ça me semblerai être un sacré échec de ne pas pouvoir utiliser HTML5 pour implémenter les quelques controls/boite de dialogues de Firefox en HTML/JS/CSS.
Ce n'est pas implémenter des boites de dialogues qui posent problème, c'est tout ce qu'il y a dans un navigateur.
browser.html, ce n'est pas un fichier html que l'on va mettre dans firefox en remplacement de XUL, et qui va tourner en mode privilégié comme le XUL. browser.html est une webapp. qui tourne donc dans une sandbox.
Du coup, comment dans l'interface on affiche par exemple l'historique de navigation (pour le gestionnaire de l'historique) ? comment accéder à la liste des mots de passe (pour le dialog de gestion des mots de passe) ? Comment modifier les préférences (pour une bonne partie des paramètres de la boite de préférences) ? Il y a aussi la gestion des "commandes" de l'interface, la gestion du copier coller, la gestion de la fenetre etc…
Bref, un navigateur, ce n'est pas juste afficher une page web, c'est aussi est surtout pouvoir gérer plein de truc autour. Et pour cela, il faut utiliser des API interne. Chose facile quand on est en XUL, parce que le code JS/XUL de Firefox (et celui des extensions XUL) tourne en mode privilégié (le mode chrome), et donc on peut appeler n'importe quel composant interne XPCOM.
Et le souci ici est que l'interface de browser.html, comme toutes les webapps, comme toutes les applis de FirefoxOS, tournent dans une sandbox. Pas d’accès direct à ces composants internes.
Il faut donc exposer, dans le contexte HTML, des API qui permettent de pouvoir faire ce qu'on pouvait faire en mode chrome.
Ces API étant souvent "sensibles", il y a un système de permissions.
Un exemple d'API, c'est l'api de navigation. Ça l'air con de gérer des onglets et la navigation : suffit de gérer des iframes, et dans chaque iframe, tu charges un site. Oui mais pas seulement. Comment surveiller l'état du chargement d'une iframe, afin de pouvoir afficher un throbber dans la barre d'url ? Comment stopper le chargement d'une iframe ? comment detecter justement que l'iframe démarre le chargement d'une nouvelle page, pour mettre à jour l'url dans la barre d'url ? Comment récupérer les informations sur le certificat SSL du site chargé afin de pouvoir les afficher quand on clique sur le cadenas ? etc etc etc… En mode chrome, aucun souci. Mais quand tu es dans une page HTML qui n'a pas les privilèges chrome, t'es à poil. En html standard, tu n'as pas d'API pour tout ça.
Il faut donc développer ces API (qui, techniquement, à leur tour, appellerons les apis interne de gecko). Tu as un début avec la browser API, mais ce n'est pas suffisant. Il faut une API pour accéder au contenu de l'historique complet, une API pour accéder aux certificats, et des centaines d'autres API. Et créer/gérer les permissions qui vont avec.
Bref, il y a encore beaucoup, beaucoup de boulot. C'est d'ailleurs la raison pour laquelle le "navigateur" dans FirefoxOS est encore si pauvre en fonctionnalité.
D'ailleurs, tu remarqueras que pour faire les trucs de bases (copy/paste/undo/redo) de browser.html, tout ça est géré dans un fichier XUL lancé en mode chrome.
Note: il y a eu le même problème pour les extensions de type jetpack (non xul donc), qui tournent dans une sandbox JS. Il a fallu exposer dans cette sandbox un certain nombre d'API pour accéder aux API internes de Gecko. Et implémenter tout ça ne s'est pas fait en un jour (raison pour laquelle on a encore accès à un module "chrome" pour accéder directement aux composants internes).
les anti-virus décents ont un impact négligeable sur un desktop
Autant les autres points je suis à peu près d'accord (et encore, ça dépend ce qu'on fait exactement), autant pour les antivirus, non.
Parce que quand il faut que tu compiles, sur une machine un peu juste au niveau puissance, et qu'en plus tu ne peux pas toucher à l'antivirus (le mettre en pause par exemple), c'est juste horrible, j'en ai fait maintes fois l’expérience. Le pire étant l'antivirus programmé par les admin pour faire un scan complet en plein milieu de la journée (vécu) : la machine (assez vieille) freezait quasiement.
j'ai du mal à comprendre pourquoi ces décideurs ne comprendraient pas ta demande.
Tu dois faire un boulot. Il te faut un outil ayant certaines caractéristiques, sinon tu ne peux pas réaliser le boulot demandé.
Personnellement, je ne sais pas ce que je pourrais ajouter de plus comme argument. Pas de matos ? pas de développement.
Ah tiens, si, j'ai une idée. Demande à ces décideurs, ce qu'ils penseraient si on leur filait un nokia 3310 plutôt que leur iphone6, ou un ordi portable sans marque premier prix vieux de 10 ans pour réaliser leur powerpoint ou tableaux excel…
Sinon, il y a un contrat. Puisque le matériel est fourni par le client, n'y a-t-il pas une clause d'obligation de moyen par le client ?
Je ne pense pas que ce soit une bonne idée pour Mozilla de les inclure de base… (même si je les utilise tous les deux)
Bon, on pourrait imaginer qu'ils développent ou choisissent une solution plus éthique, mais cela pose d'autres problèmes :
il faut maintenir des filtres : ça prend beaucoup de temps à gérer
j'imagine que cela est interdit dans les contrats commerciaux qu'ils ont avec les moteurs de recherche, en autre Google, qui sont aussi des régies publicitaires…
Pour Firefox, mon raisonnement est le même : on a un moteur html qui est lancé, pourquoi ne pas l'utiliser partout.
C'est exactement l'idée qu'ont eu les développeurs quand ils ont crée Gecko : utiliser le moteur de rendu pour l'interface utilisateur (1998). D'où le XUL (un langage XML + js pour le comportement + CSS pour l'apparence). Je pense qu'à l'époque, ils n'ont pas utilisé le HTML parce qu'il était très basique, cela aurait nécessité de trop gros changement dans le HTML et le CSS (trop de balises et styles propriétaires) : d'où un nouveau langage. De plus le XUL a des fonctionnalités très spécifiques comme les overlays, l'usage des DTD pour les traductions et bien d'autres choses.
Bref, on a un moteur qui sait prendre n'importe quel langage XML et HTML, et sait l'afficher en le stylant en CSS.
browser.html, c'est très bien, mais ils manquent encore des choses en HTML pour faire tout ce qu'on peut faire en XUL, pour qu'il remplace ce bon cher browser.xul.
Et puis abandonner XUL, cela voudrait dire abandonner une grosse majorité des extensions… XUL va disparaitre, mais c'est pas pour demain. Il y a énormément de boulot.
Ne serait-il pas plus pertinent de ne plus avoir de Xul/Gtk3/Gtk2 ni Xul/Cocoa ni Xul/(Windows je ne sais quoi), en utilisant une interface web dans gecko lui même, par exemple : browser.html
Euh… Non…
Gtk ne sert pas qu'au XUL. Je dirais même, pas trop à XUL. Conçernant XUL, GTK sert juste à savoir des infos comme les couleurs systèmes, accéder aux fontes système etc. XUL, ce n'est que du HTML++ : tout est stylé en CSS. Il est vrai aussi que XUL s'appuie sur le toolkit (gtk, cocoa ou Windows) pour dessiner les boutons et quelques autres trucs d'interfaces. Et tu sais quoi ? c'est dessiné en indiquant la propriété CSS appearance. Qui sert aussi en HTML puisque cette propriété était prévu dans la spec css3-ui et reportée dans css4, mais cela n’empêche pas qu'elle soit implémentée dans Firefox et Webkit.
La présence de GTK/Cairo/Windows est surtout là pour gérer les fenêtres, ouvrir les boites de dialogues de fichier, d'impression etc du système, accéder au presse papier et de beaucoup d'autres choses.
Bref, XUL ou HTML, un navigateur a besoin d'un toolkit comme gtk et autre, en plus d'une lib purement graphique.
Mais vu que je passe beaucoup de temps à coder et que je n'ai pas publié grand chose, j'aurais peut être pu passer ce temps à étudier Python plutôt que m'énerver contre la "mauvaise" modernisation de PHP :)
<Ironie> Ouuuuh là!! Attention, tu va être TRÈS décu. en effet, beaucoup de lib et d'applis s'installe avec PIP, qui est très similaire à Composer. Tu ne vas pas pouvoir faire totalement du dev à contre courant de ce que l'écosystème propose :-p </Ironie>
Oui, mais c'est encore plus simple et rapide d'extraire une archive.
en tant que développeur. Non. Pas du tout. Puisque j'ai même pas à connaitre l'url. Juste le nom du paquet. Une ligne dans le json (nom/version), composer install, et c'est terminé. Je veux mettre à jour ? je change la version dans le json, composer update. c'est terminé.
Alors qu'avec une archive : je dois aller la récupérer sur le site du projet, la dézipper dans mon projet, chercher à savoir comment inclure la lib, ou instancier son autoloader, et donc faire un include (voire plus) quelque part dans mon code. Ensuite, je veux mettre à jour (souvent plusieurs mois après) : faut que je retourne sur le site (dont j'ai oublié le lien, hop, détour par google), retélécharger à la mimine, dézipper les fichiers, ajouter les nouveaux fichiers dans le subversion/git, et supprimer les fichiers qui n'existent plus dans la nouvelle version (ce qui peut être fastidieux, et je parles en connaissance de cause), vérifier dans la doc que l'autoloading ou l'inclusion se fait toujours pareil…
Bah désolé, non, avec Composer, je n'ai pas toutes ces emmerdes, puisque Composer me télécharge tout ça automatiquement, qu'il m'évite à un inclure dans mon dépôt git ces libs externes, et parce que l'inclusion/autoloading, c'est Composer qui fait tout ça pour moi.
Je rajoute l'argument sécurité: si l'URL du dépôt de ton framework est comprise et que le dev qui utilise composer ne vérifie pas ce que composer télécharge…
Parce que le site où tu télécharge ton zip, il ne peut pas être compromis ? tu vérifie tout les zip des libs que tu télécharges ? cela voudrait dire que tu vérifie le contenu de chaque fichier ? et pourquoi alors tu ne pourrais pas le faire dans les sources posées dans le vendor/ par Composer ?
L'argument de sécurité est nul ici.
de plus en plus d'applications complètes utilisent composer comme méthode d'installation par défaut (Magento par exemple)
Perso je trouve ça bête pour un utilisateur final. Mais Magento n'est pas un bon exemple pour ton argumentaire. Le lien que tu montres, c'est la doc pour les développeurs (c'est marqué sur la page). Donc oui, là, utiliser Composer a un sens. Puisque si tu es développeur, cela veut dire que tu vas personnaliser Magento, lui rajouter du code pour des traitements metiers, des plugins ou que sais-je, et donc probablement installer d'autres lib (en utilisant Composer ou pas).
Pour les utilisateurs finaux, il faut aller voir sur le site pour les utilisateurs. Et qu'y trouve-t-on ? Oh, miracle, des tar.gz prêts à l'emploi ! ;-)
La majorité des paquets composer ne sont pas des applications complètes mais des librairies. A mon sens c'est une grosse différence.
Tu parlais de projets libre. Alors, à moins que pour toi une lib libre n'est pas un projet libre, je ne vois pas de différence.
Ce que je veux dire c'est que quand on développe une application à destination du "grand public", on cherche à lui donner une identité. Si on se contente d'un bootstrap à peine modifié, ….
Tu passes de PHP à Bootstrap, du coq à l'âne, donc des problématiques différentes. J'avoue que ton discours est très difficile à suivre.
Si les libs étaient proposées avec leur propre auto-loader (ce que fait, une fois encore, PHPUnit, PHPMailer, Smarty, etc.), il n'y aurait pas besoin de faire ça à la main.
Oui donc, au final, dans un projet, si tu utilises 25 libs, tu as alors 25 autoloaders, qui font quasiment la même chose. Bonjour les perfs. Avec Composer : on peut avoir un seul autoloader, en particulier si on utilise les namespaces (il est possible de lui indiquer des autoloaders spécifiques si nécessaire, par exemple ceux des libs ayant un autoloader spécifique).
C'est à la librairie de dire comme se charger, on n'a pas à le "deviner" ou le supposer.
Justement, avec Composer, on a encore moins à s'en charger, puisqu'il y a au final 0 include à faire après avoir installé une lib. Alors que, pour une lib "non composerifiée", il faut que tu saches quel fichier inclure (celui qui fait tout les includes de la lib ou qui déclare l'autoloader de la lib).
Moi, ce que je vois avec composer, c'est que quand tu code une appli libre, tu cherche à simplifier au maximum l'installation.
Moi quand je code, je veux faire les choses vite et bien, parce que ce qui m’intéresse, c'est avant tout de pouvoir répondre à un besoin. Alors si l'installation d'une lib est simplifiée, si les développeurs peuvent installer mon framework en déclarant une petite dépendance et en tapant une seule ligne de commande, ça me va.
Je suis désolé mais non, pour un débutant qui veut utiliser son application, ce n'est pas plus simple de faire (…)
que d'extraire une archive
Tu parles d'un utilisateur, ou d'un développeur ? Parce que si c'est pour fournir une application finale (un truc comme wordpress ou phpbb) destinée aux utilisateurs, oui faut être con pour proposer ce genre de chose (encore que, si Composer est installé d'office par les distros, ça peut avoir du sens). Et si je ne me trompe pas, ce genre de projet proposent en général un zip pour les utilisateurs, comportant toutes les dépendances, à déposer quelque part, prêt à être utilisé.
Pour les développeurs de l'application par contre, non, Composer facilite le développement, les mises à jours des dépendances, l'installation du projet etc… Et donc Composer convient très bien au développement.
Faut pas confondre développement et utilisation. Développeur et utilisateurs.
En ce qui concerne debian et cakephp, j'ai bien l'impression que ce que tu racontes n'a rien à voir avec Composer…
composer est bien pour gérer les dépendances d'un projet pro, statique, où personne ne va mettre son nez dedans, mais pour un projet Libre, je pense que ce n'est pas une bonne solution.
Désolé, mais tu me fais bien rire là :-) La majorité des packages installables par Composer sont des projets libres. Donc pour ces projets, ce n'est pas la solution ??? Pourquoi ils sont dans Composer alors ? Pourquoi c'est autant utilisés ?
Quand on code une appli libre, on n'industrialise pas.
Gniiii ??? c'est quoi cette histoire ? Pourquoi il ne faudrait pas "industrialiser" ?
Parce qu'on code une appli libre, il ne faudrait pas utiliser les outils que l'on a à notre disposition pour développer, déployer, tester et tout faire à la mimine ou rien faire ???
Bah désolé, une partie de mes projets libres, je les développe sur mon temps libre (qui se restreint de plus en plus). Tout outil qui pourrait me faire gagner du temps, qui me permettrait d'être plus productif, je les utilises.
Et c'est d'autant plus intéressant que j'en profite pour découvrir des nouveaux outils ou libs, qui me permettent ensuite au niveau professionnel de monter en compétence, d'être plus productif (et donc éventuellement d'avoir plus de temps pour dev les projets libres).
Si le gestionnaire de dépendance était partie intégrante de PHP, les choses seraient différentes, mais là c'est un projet lambda. Et forcer à son utilisation est contraire à la philosophie du Libre.
J'hallucine là. Tu trolles là en fait hein ? c'est ça ?
Je vais t'apprendre un truc : n'importe quel lib proposée par Composer, tu peux l'utiliser sans Composer. Suffit juste que tu ailles chercher toi même les dépendances, et te faire un autoloader (ce qui est une perte de temps à mon avis).
Les traits sont un paliatif au fait que PHP ne supporte pas l'héritage multiple. Je trouve leur syntaxe confuse:
Non les traits n'est pas un paliatif. Ça n'a d'ailleurs rien à voir avec l'héritage multiple, et ça ne cherche pas à remplacer l'héritage multiple (qui pose lui même bien des problèmes dans d'autres langages).
Je trouve dommage que le nom du site fasse référence à la piraterie.
Les gens vont assimiler linux = warez. C'est con.
PS: ouai, ok, à priori tu milites pour le parti pirate, mais franchement sur le site, c'est pas évident à comprendre pourquoi ce mot pirate. Bref, comme pour le parti Pirate, le nom va à l'encontre des idées au final, ce qui rend le truc pas crédible.
De façon assez étrange, ni Smarty, ni Redbean ne mentionnent composer dans leur documentation, et PHPMailer s'en passe parfaitement.
Parce que peut-être les développeurs de ces libs ne s'y sont pas vraiment intéressé ou ne veulent pas, ou sont réfractaires à certains changement ? D'ailleurs Redbean le dit bien : le gars est "conservateur".
Cela ne veut pas dire que Composer c'est de la merde.
Et tu noteras que tu cites quand même des projets vraiment vieux (voir à peine maintenu comme PHPMailer). Lourd passif donc.
M'enfin bon, même si des libs comme celle-là ne sont pas fournie en paquet Composer, c'est juste 3 lignes de code supplémentaires à rajouter dans ton composer.json pour les intégrer dans ton projet. Pas la mort quoi.
comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap
J'ai l'impression que tu ne maintiens pas de projet public pour dire ça, ou alors tu es super compétent en design web et c'est super facile pour toi de pondre un design html/css.
J'ai plusieurs projets open source en PHP que je développe et maintien depuis des années. J'ai beau être compétent techniquement en HTML et CSS, je peux te dire une chose : ça me fais chier grave de faire les sites web de mes projets. Parce que je suis incompétent en design web et du coup, quand il faut que je refasse l'un deux, j'y passe des jours pour que ça ressemble à quelque chose. Ce temps, je préfère le passer à développer la lib. Donc je comprend très bien ceux qui choisissent bootstrap ou autre trucs "pour se faciliter la vie".
ni Smarty n'utilisent bootstrap sur leur site.
Ça c'est normal : le site de Smarty n'a pas bougé depuis 10 ans. Idem pour PHPMailer. Ils sont probablement comme moi : ils préfèrent passer du temps sur leur lib que sur le design de leur site.
Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc…
je ne comprends pas comment il est possible que de telles librairies ou outils puissent avoir une telle cote de popularité.
parce que j'ai l'impression que tu n'as pas trop en tête les avantages qu'ils offrent…
Aujourd'hui, tout le monde boude PEAR,
Je te rassures, même avant tout le monde boudait Pear. Quelle a été la proportion de lib et de projets qui proposait un paquet Pear ? 0,5% ? 1%? Franchement on n'y trouvait pas grand chose.
Et maintenant avec Composer ? 70%, 80%, 90% ? Le nombre de projets dispo via Composer est sans commune mesure avec Pear.
Et si Composer a un tel succès, c'est bien parce qu'il offre quelque chose de mieux non ?
Perso je n'ai jamais aimé Pear.
Déjà, c'est un truc hyper fermé : il faut que ton projet respecte certaines règles, notamment le coding style (que je trouve horrible). Ensuite, il faut qu'il soit accepté par les gens qui gère Pear. Tu ne peux pas avoir de doublons en terme de fonctionnalité avec une autre lib. Au final, Pear ne propose pas grand chose. Ou alors des usines à gaz. Interroge toi par exemple pourquoi tu as choisi PHPMailer plutôt que leur lib de mail.
Ensuite, sur le serveur (en particulier avec Debian), ton depôt PEAR est forcément partagé par tous tes projets. Au final, tu te retrouve coincé : tu ne peux pas mettre à jour au risque de casser tes vieux projets, et donc tu ne peux pas profiter des dernières versions pour des nouveaux projets. Et même si tu veux mettre à jour, c'est la galère avec debian, on ne sait jamais ce qu'il faut faire vraiment (y a toujours eu des trucs qui cassaient chez moi). Ne serait-ce que pour mettre à jour PHPUnit avec Pear. ça a toujours été la galère (à cause principalement qu'il faille faire ça en sudo, qu'il faille modifier le include_path dans la conf PHP etc).
Alors qu'avec Composer, tu as un dépôt par projet, chaque projet évolue comme il veut, utilise les paquets qu'il veut. PHPUnit et les autres paquetes s'installent en deux coup de cuillère à pot. Pas besoin de droits spéciaux sur le système pour les installer. Peu importe au final le système : ton projet reste indépendant.
M'enfin comme tu l'as dit toi même Pear c'est plus un Framework qu'un gestionnaire de dépendance. Donc au final, peu de rapport avec Composer.
Les gros avantages de Composer, c'est qu'il fait un seul truc et le fait bien : installer des paquets et gérer les dépendances. Un apt pour PHP.
L'autre gros avantage de Composer : il génère un autoloader. Adieu tous les includes dans tout les sens pour charger une lib ! Et si en plus les lib utilisent les namespaces (en respectant PSR-0 ou PSR-4), l'autoloader est beaucoup plus efficace.
À l'usage on se rend compte que ça apporte plus de souplesse, moins de tracas, et plus de perf (pas de chargement de classes non utilisées).
Le pire, c'est que toutes ces libs modernes suivent les recommandations PSR, donc devraient être facilement utilisables partout quelle que soit la configuration du serveur sur lequel elles sont installées.
Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur. Je ne sais pas où tu as lu ça. Pour le moment, ils ont des recommandations pour le nommage des classes (PSR-0 et PSR-4), afin de faciliter le développement des autoloaders (que l'on n'a plus à développer si on utilise Composer), des recommandations sur le coding style (PSR-1 et PSR-2), et une recommandation sur l'interface d'un objet qui fait du log. Et ce qui est en discussion actuellement ce sont d'autres interfaces pour d'autres types d'objets courant (gestionnaire de cache, lib http…).
(donc non, ça ne servira pas qu'à Composer).
Bref, ce sont des choses pour améliorer l'interopérabilité entre les frameworks. Rien à voir avec la conf des serveurs.
Et puis ce ne sont que des recommandations. Pas obligé de les suivre.
composer qui a, par ailleurs, la fâcheuse tendance à installer tout un tas de truc que je n'ai jamais demandé et qui n'existe pas dans les archives
Composer installe ce que les paquets ont besoin, pas plus, pas moins. Si un paquet a une dépendance envers un autre paquet et qu'il n'utilise pas, la faute est au développeur, pas à Composer. Mauvais paquet, changer paquet. (ça tombe bien, contrairement à Pear, le choix est très vaste).
phpass - génération de hash sécurisés pour les mots de passe, en l'absence de blowfish
Avec la nouvelle api password de PHP, cette lib est devenu inutile et obsolète (voir dangereuse, vu qu'elle n'est plus maintenue ?).
leur usage abusif des namespaces
Les namespaces, c'est bon, mangez-en : ça évite les collisions de classes entre libs, ça facilite l'autoloading, ça permet une programmation moderne, ça force (un peu) à mieux organiser son code.
Je suis en train de "namespacer" mon framework, ça fait beaucoup de bien au final.
Pour finir, Composer, on peut s'en passer, mais c'est devenu la norme maintenant pour distribuer et installer des libs en PHP. L'ignorer ou le dénigrer n'aidera pas dans tes projets présent et futurs.
bah pour des utilisateurs qui veulent pas voir des noms pareils à chaque fois qu'ils ouvrent leur gestionnaire d'applis.
Oué, c'est un peu comme ces mecs qui font des caricatures
Non, ce n'est pas comme les caricatures. Si on prend l'exemple de celles de Charlie Hebdo : si tu n'aimes pas, tu n'achètes pas le journal. Contrairement à ici où c'est imposé. On peut toujours changer de système d'exploitation, mais c'est plus compliqué que d’arrêter d'acheter un journal.
Franchement, ils se prennent pour qui?
pour des gens qui donnent leur avis ? ils ont ce droit il me semble, non ?
sans même profiter de l'architecture de plug-ins intégrée depuis les débuts?
à priori, tu ne sembles pas comprendre comment fonctionne les plugins (aka les trucs qui se charges avec une balise object en html). Il ne t'ai pas venu à l'idée que si ils n'ont pas utilisé cela, c'est que c'était inadapté ? (les plugins sont des boites noires sur lesquels le navigateur n'a AUCUN contrôle, y compris graphique, donc intégration très limités dans les pages web).
qui mets en avant la puissance de son architecture de plug-ins
Là tu parles des extensions XUL, pas des plugins. Un truc totalement différent.
Si au lieu d'ajouter les fonctionnalités en dur, ils ajoutaient des plugins qui sont installés par défaut, ça me semblerait vachement plus logique, et ça permettrait de réduire la complexité de la compilation et du source
Bah oui tient bien sûr ! Pourquoi ils n'y ont pas pensé ?? Franchement, ces développeurs, c'est tous des incompétents !
C'est vrai quoi, n'importe quel libs peut "se pluginiser" !
Non, sérieusement, tu es développeur ?
Mon opinion, qui peut être mauvaise ok, c'est que quand on mets des options pour désactiver des fonctionnalités, il faudrait peut-être au moins essayer de compiler en les activant.
Tu as vu le nombre d'options ? Tu crois que Mozilla a les ressources nécessaires pour tester tous les cas de figure ?
Sans compter que certaines options sont des contributions externes pour des besoins spécifiques, donc non maintenue par Mozilla. D'autres sont des options qui sont là parce qu'elles étaient nécessaires lors du développement de telle ou telle fonctionnalité, puis oubliée par la suite. Enfin il peut aussi y avoir des bugs. Tu as indiqués ces bugs ? Tu es allé demander une solution ?
Pourquoi ne pas avoir fait une transition franche, pourquoi chercher à réinventer la roue (les alternatives aux autotools c'est pas ce qui manque)?
Peut-être parce que faire une transition franche de cette sorte, ça se fait pas en 2 secondes, que c'est très compliqué pour un projet de cet envergure. et que ça pourrait bloquer le développement d'autres choses plus prioritaires pendant un certain temps ? Et puis de toute façon, pourquoi tu demandes ça ici ? tu ne trouves pas que tu devrais plutôt demander ça directement à ceux qui le développent ?
même de récupérer les sources sur le site officiel, d'ailleurs
Non mais là, désolé de te le dire, tu pousses un peu loin. Une ligne de commande à taper pour récupérer les sources. c'est indiqué noir sur blanc dans la doc. Tu peux même télécharger direct sans cloner. Je ne sais pas ce qu'il faut de plus sérieusement. Ta remarque (et d'autres de tes commentaires), me fait penser de plus en plus que le problème en fait se situe entre la chaise et le clavier. C'est à dire une incompétence sur le fonctionnement d'un gros projet comme Firefox (non, désolé, désactiver des trucs pas désactivables dans un gros projet, ça se fait pas en indiquant 2 options et faire deux hack pourri), et probablement une inexpérience en développement.
En fait, je te trouve bien naïf. Par exemple quand tu dis que tu trouves Firefox trop lent et que tu veux compiler pour tenter de trouver toi-même là où ça coince. Sérieusement. Des millions de lignes de codes. Des millions. Provenant de libs diverses et variées. Un navigateur, c'est pas un "hello world". Y a des centaines de paramètres qui rentrent en jeux dans les perfs de Firefox (la manière dont il boot, le moteur JS, le moteur de rendu, la pile réseau, les lib graphique, Cairo, GTK, Sqlite, le code des sites web, le système de garbage collector, XPCOM etc..). Bref, tout un programme (à lire absolument si tu veux te plonger vraiment sur le sujet). Des personnes travaillent à plein temps dessus, et toi tu espères (sans rien connaître au projet et en gueulant ici) trouver magiquement le code responsable des mauvaises perfs avec un build en mode debug et ton gdb.
L'idée de vouloir améliorer les perfs, c'est sympa, et ton aide sera la bienvenue. Mais seulement si tu t'aides d'abord toi même, (en ne restant pas dans ton coin et en demandant de l'aide). Et commence d'abord par faire un truc simple plutôt que de vouloir révolutionner le monde. Bref, rester humble et laisser de coté son ego.
Commence par apprendre comment fonctionne le projet, apprend à utiliser les outils, documente toi, pose des questions sur les canaux de discussions de Mozilla. Je t'ai déjà donné les billes pour ça.
Bref, faire comme pour tous projets libre dans lesquels on veut s'investir.
Super. Devoir aller chercher dans l'océan about:config une valeur qui devrait être accessible via l'ihm…
Désolé, je n'ai pas dû comprendre ce que tu voulais faire exactement. Tu veux faire un fork de Firefox avec tes histoires de build pour n'avoir que des fenêtre seules. Je t'indique une piste qui t'évite cette pénible étape et tu n'es pas encore content ??
Pour le build, non, il ne suffit pas de les suivre à la lettre.
c'est pourtant ce que je viens de faire à l'instant…
Maintenant, si tu changes plein de trucs, oui, le build peut planter…
Chez moi, en désactivant toutes les "fonctionnalités" qui intègrent le support du son et/ou de la vidéo, j'ai encore des dépendances à webm qui traînent.
Peut-être as-tu oublié d'indiquer d'autres flags, ou alors qu'il y ait un bug de compil. Je doute que la désactivation de ce genre de fonctionnalité soit beaucoup utilisée et donc personne chez Mozilla ne se rend compte de ce genre de problème.
Parles-en sur les newsgroup ou sur irc.mozilla.org #developers. Et sinon http://bugzilla.mozilla.org. ça sera je pense plus constructif pour toi…
```
Je ne comprend pas. Firefox te permet d'ouvrir tes pages webs dans une fenêtre séparée. Je crois même qu'en modifiant la pref browser.link.open_newwindow ça peut se faire automatiquement quand on clique sur un lien… Il y a d'ailleurs une extension qui semble faire ce que tu veux.
Pour le build, y a de la doc, à priori, suffit de suivre les instructions à la lettre. À moins que tu ais un système exotique ?
Oui, il y a des bugs non corrigés existants depuis des lustres.
Et non, ce n'est pas volontaire de la part des développeurs ou de leur hiérarchie, de laisser ces bugs pourrir.
C'est juste qu'ils n'ont pas le temps de tout faire. C'est juste parce qu'un projet comme celui là, il y a des milliards de choses à faire. Et qu'il y a des priorités.
Et non, ne pas développer Hello ou autre trucs qui vous semblent futiles dans le navigateur, ne vas pas donner plus de temps pour corriger les bugs que tu pointes. Tout simplement parce que ce ne sont pas les mêmes personnes qui travaillent sur ces parties. Et ce ne sont pas les mêmes personnes, parce que cela n'exige pas les mêmes compétences.
Pour les problèmes CSS, cela exige une connaissance sur le moteur de rendu, donc des compétences en C++, en algo de reflow et cie, en architecture d'un moteur de rendu HTML, et surtout, une connaissance du code source existant (très complexe). Faire un Hello, ça exige des connaissances en JS/HTML pour l'interface, et C++ pour l'implem de WebRTC, des connaissances poussées sur WebRTC (qui est une spec bien complexe ). Faire un outil de debug, ça nécessite aussi du JS/HTML pour l'UI, mais aussi des connaissances poussées sur le moteur JS (en C/C++), bien complexe lui aussi, pour implémenter par exemple les API de debugs etc..
Bref, chacun a sa spécialité. Le nombre de personne qui ont une connaissance approfondie de l’entièreté du code de Gecko (je ne parle que de Gecko, pas de l'interface de Firefox et ses composants périphériques comme Hello etc), on doit les compter sur les doigts des deux mains. Si ce n'est qu'une seule.
Moi par exemple dans Gecko, ma spécialité était le serializer HTML/XML, l’implémentation des élements DOM XUL, et l'éditeur HTML (le truc qui sert à avoir des champs de saisie dans une page web, ou à pouvoir éditer une page en wysiwyg avec le mode contenteditable). Mais je suis totalement incapable de toucher à un truc dans le layout engine (css et cie quoi), ni au moteur JS. Au delà de savoir si j'aurais eu suffisamment les compétences pour toucher à cette partie (très complexe), je n'avais surtout pas le temps de me plonger dedans (en tant que bénévole). Ce à quoi je contribuais m'en prenais déjà énormément.
Et sur les parties sur lesquelles je contribuais, il y a là aussi des dizaines de bugs non résolu depuis des lustres : pas le temps de tout corriger. Il faut faire alors un choix. Ok ce bug A emmerde quelques utilisateurs, et il est là depuis des lustres, mais il y a ce bug B, plus récent certes, mais qui emmerdent beaucoup beaucoup plus de monde. Donc corrigeons ce Bug B. J'aimerais bien corriger aussi le bug C, mais là, il n'y a pas énormément de tests sur le code existants, et ce qu'il faut modifier risque de casser plein de trucs. Donc ça va prendre énormément pour développer tous les tests. Ah oui mais là le truc a un comportement bizarre : bug, oubli ou feature mal spécifiée ? Le bug C que je croyais pouvoir corriger en quelques heures va me prendre des journées entières, parce qu'il va falloir que j'étudie du code source et des specs à tire-larigo. Bon ben le bug C, ça sera pour quelqu'un d'autre. Ah, et puis y a le bug D. Trop important. C'est une feature totalement nouvelle dans HTML5, que les développeurs veulent tout de suite parce que trop kikoolol et que les autres nav ont déjà implémenté. Donc allons-y pour le bug D.
etc. etc. etc..
Voilà à quoi peut ressembler les contributions d'un bénévole. Pour un employé Mozilla, ils ont moins de latitudes à choisir. Faut qu'ils développent les nouvelles features. Parce que bon, y a des râleurs qui se plaignent du retard en HTML5 etc, alors faut qu'on avance. Hein ? quoi ? ah, faut aussi corriger les bugs vieux de 8 ans ? Ah bah oui mais faut savoir ce qu'ils veulent aussi…
Firefox est un gros projet. Et comme tout gros projets, il y a des choses qui ne sont pas corrigés, parce qu'il y a des choses plus prioritaires que d'autres, parce que le nombre de dev travaillant sur une partie n'est pas illimités, parce qu'un dev travaillant sur une partie n'est pas forcément compétent pour travailler sur une autre partie.
Donc voilà. Ok, y a 3 bugs qui t'agacent. Je te comprends. Moi-même j'en ai. Mais pas les même. Bref, y en a des centaines.
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 4.
tout à fait.
Qui plus est, si ces API sont standardisées (ce qui est le but ultime de mozilla), que le format "webapp" est lui aussi standardisé, et tout ça implémenté dans d'autres moteurs, on pourrait imaginer à terme lancer notre browser.html avec blink ou webkit par exemple.
Mais il y a encore beaucoup de chemin à parcourir, malgré que l'on puisse dés aujourd'hui lancer une webapp indifféremment avec Firefox desktop, Firefox pour Android ou encore FirefoxOS (sauf si ladite appli utilise les api de téléphonie par exemple : ça va moins bien fonctionner sur le desktop :-)).
De rien :-)
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 10.
Ce n'est pas implémenter des boites de dialogues qui posent problème, c'est tout ce qu'il y a dans un navigateur.
browser.html, ce n'est pas un fichier html que l'on va mettre dans firefox en remplacement de XUL, et qui va tourner en mode privilégié comme le XUL. browser.html est une webapp. qui tourne donc dans une sandbox.
Du coup, comment dans l'interface on affiche par exemple l'historique de navigation (pour le gestionnaire de l'historique) ? comment accéder à la liste des mots de passe (pour le dialog de gestion des mots de passe) ? Comment modifier les préférences (pour une bonne partie des paramètres de la boite de préférences) ? Il y a aussi la gestion des "commandes" de l'interface, la gestion du copier coller, la gestion de la fenetre etc…
Bref, un navigateur, ce n'est pas juste afficher une page web, c'est aussi est surtout pouvoir gérer plein de truc autour. Et pour cela, il faut utiliser des API interne. Chose facile quand on est en XUL, parce que le code JS/XUL de Firefox (et celui des extensions XUL) tourne en mode privilégié (le mode chrome), et donc on peut appeler n'importe quel composant interne XPCOM.
Et le souci ici est que l'interface de browser.html, comme toutes les webapps, comme toutes les applis de FirefoxOS, tournent dans une sandbox. Pas d’accès direct à ces composants internes.
Il faut donc exposer, dans le contexte HTML, des API qui permettent de pouvoir faire ce qu'on pouvait faire en mode chrome.
Ces API étant souvent "sensibles", il y a un système de permissions.
Un exemple d'API, c'est l'api de navigation. Ça l'air con de gérer des onglets et la navigation : suffit de gérer des iframes, et dans chaque iframe, tu charges un site. Oui mais pas seulement. Comment surveiller l'état du chargement d'une iframe, afin de pouvoir afficher un throbber dans la barre d'url ? Comment stopper le chargement d'une iframe ? comment detecter justement que l'iframe démarre le chargement d'une nouvelle page, pour mettre à jour l'url dans la barre d'url ? Comment récupérer les informations sur le certificat SSL du site chargé afin de pouvoir les afficher quand on clique sur le cadenas ? etc etc etc… En mode chrome, aucun souci. Mais quand tu es dans une page HTML qui n'a pas les privilèges chrome, t'es à poil. En html standard, tu n'as pas d'API pour tout ça.
Il faut donc développer ces API (qui, techniquement, à leur tour, appellerons les apis interne de gecko). Tu as un début avec la browser API, mais ce n'est pas suffisant. Il faut une API pour accéder au contenu de l'historique complet, une API pour accéder aux certificats, et des centaines d'autres API. Et créer/gérer les permissions qui vont avec.
Bref, il y a encore beaucoup, beaucoup de boulot. C'est d'ailleurs la raison pour laquelle le "navigateur" dans FirefoxOS est encore si pauvre en fonctionnalité.
D'ailleurs, tu remarqueras que pour faire les trucs de bases (copy/paste/undo/redo) de browser.html, tout ça est géré dans un fichier XUL lancé en mode chrome.
Note: il y a eu le même problème pour les extensions de type jetpack (non xul donc), qui tournent dans une sandbox JS. Il a fallu exposer dans cette sandbox un certain nombre d'API pour accéder aux API internes de Gecko. Et implémenter tout ça ne s'est pas fait en un jour (raison pour laquelle on a encore accès à un module "chrome" pour accéder directement aux composants internes).
[^] # Re: installer Linux nativement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 6.
Autant les autres points je suis à peu près d'accord (et encore, ça dépend ce qu'on fait exactement), autant pour les antivirus, non.
Parce que quand il faut que tu compiles, sur une machine un peu juste au niveau puissance, et qu'en plus tu ne peux pas toucher à l'antivirus (le mettre en pause par exemple), c'est juste horrible, j'en ai fait maintes fois l’expérience. Le pire étant l'antivirus programmé par les admin pour faire un scan complet en plein milieu de la journée (vécu) : la machine (assez vieille) freezait quasiement.
# comprend pas
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 10.
j'ai du mal à comprendre pourquoi ces décideurs ne comprendraient pas ta demande.
Tu dois faire un boulot. Il te faut un outil ayant certaines caractéristiques, sinon tu ne peux pas réaliser le boulot demandé.
Personnellement, je ne sais pas ce que je pourrais ajouter de plus comme argument. Pas de matos ? pas de développement.
Ah tiens, si, j'ai une idée. Demande à ces décideurs, ce qu'ils penseraient si on leur filait un nokia 3310 plutôt que leur iphone6, ou un ordi portable sans marque premier prix vieux de 10 ans pour réaliser leur powerpoint ou tableaux excel…
Sinon, il y a un contrat. Puisque le matériel est fourni par le client, n'y a-t-il pas une clause d'obligation de moyen par le client ?
[^] # Re: Privacy for you™
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 3.
Ghostery ? le truc qui, si tu fais pas gaffe, envoi tout ce qu'il bloque à la société qui le développe, pour ensuite… revendre ces données aux sociétés de pub/tracker &co ?
Adblock+, qui a lui aussi un drôle business model ?
Je ne pense pas que ce soit une bonne idée pour Mozilla de les inclure de base… (même si je les utilise tous les deux)
Bon, on pourrait imaginer qu'ils développent ou choisissent une solution plus éthique, mais cela pose d'autres problèmes :
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 5.
C'est exactement l'idée qu'ont eu les développeurs quand ils ont crée Gecko : utiliser le moteur de rendu pour l'interface utilisateur (1998). D'où le XUL (un langage XML + js pour le comportement + CSS pour l'apparence). Je pense qu'à l'époque, ils n'ont pas utilisé le HTML parce qu'il était très basique, cela aurait nécessité de trop gros changement dans le HTML et le CSS (trop de balises et styles propriétaires) : d'où un nouveau langage. De plus le XUL a des fonctionnalités très spécifiques comme les overlays, l'usage des DTD pour les traductions et bien d'autres choses.
Bref, on a un moteur qui sait prendre n'importe quel langage XML et HTML, et sait l'afficher en le stylant en CSS.
browser.html, c'est très bien, mais ils manquent encore des choses en HTML pour faire tout ce qu'on peut faire en XUL, pour qu'il remplace ce bon cher browser.xul.
Et puis abandonner XUL, cela voudrait dire abandonner une grosse majorité des extensions… XUL va disparaitre, mais c'est pas pour demain. Il y a énormément de boulot.
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 5.
Euh… Non…
Gtk ne sert pas qu'au XUL. Je dirais même, pas trop à XUL. Conçernant XUL, GTK sert juste à savoir des infos comme les couleurs systèmes, accéder aux fontes système etc. XUL, ce n'est que du HTML++ : tout est stylé en CSS. Il est vrai aussi que XUL s'appuie sur le toolkit (gtk, cocoa ou Windows) pour dessiner les boutons et quelques autres trucs d'interfaces. Et tu sais quoi ? c'est dessiné en indiquant la propriété CSS appearance. Qui sert aussi en HTML puisque cette propriété était prévu dans la spec css3-ui et reportée dans css4, mais cela n’empêche pas qu'elle soit implémentée dans Firefox et Webkit.
La présence de GTK/Cairo/Windows est surtout là pour gérer les fenêtres, ouvrir les boites de dialogues de fichier, d'impression etc du système, accéder au presse papier et de beaucoup d'autres choses.
Bref, XUL ou HTML, un navigateur a besoin d'un toolkit comme gtk et autre, en plus d'une lib purement graphique.
[^] # Re: Debian fait partie du passé
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Debian 7.8, huitième mise à jour de Wheezy. Évalué à 7.
mouahahah ptdr mdr lol
(désolé)
..
..
(ou pas, on est vendredi après tout :-) )
[^] # Re: Dommage
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal piratix.fr.nf : un tracker bittorent pour OS libres. Évalué à 0.
non, piraterie peut se dire : http://www.larousse.fr/dictionnaires/francais/piraterie/61129
[^] # Re: mocheté
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 6.
<Ironie>Ouuuuh là!! Attention, tu va être TRÈS décu. en effet, beaucoup de lib et d'applis s'installe avec PIP, qui est très similaire à Composer. Tu ne vas pas pouvoir faire totalement du dev à contre courant de ce que l'écosystème propose :-p</Ironie>[^] # Re: à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 8.
Faudrait déjà que tu définisses "industrialisé", et "usage professionnel".
[^] # Re: à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 8.
en tant que développeur. Non. Pas du tout. Puisque j'ai même pas à connaitre l'url. Juste le nom du paquet. Une ligne dans le json (nom/version), composer install, et c'est terminé. Je veux mettre à jour ? je change la version dans le json, composer update. c'est terminé.
Alors qu'avec une archive : je dois aller la récupérer sur le site du projet, la dézipper dans mon projet, chercher à savoir comment inclure la lib, ou instancier son autoloader, et donc faire un include (voire plus) quelque part dans mon code. Ensuite, je veux mettre à jour (souvent plusieurs mois après) : faut que je retourne sur le site (dont j'ai oublié le lien, hop, détour par google), retélécharger à la mimine, dézipper les fichiers, ajouter les nouveaux fichiers dans le subversion/git, et supprimer les fichiers qui n'existent plus dans la nouvelle version (ce qui peut être fastidieux, et je parles en connaissance de cause), vérifier dans la doc que l'autoloading ou l'inclusion se fait toujours pareil…
Bah désolé, non, avec Composer, je n'ai pas toutes ces emmerdes, puisque Composer me télécharge tout ça automatiquement, qu'il m'évite à un inclure dans mon dépôt git ces libs externes, et parce que l'inclusion/autoloading, c'est Composer qui fait tout ça pour moi.
Parce que le site où tu télécharge ton zip, il ne peut pas être compromis ? tu vérifie tout les zip des libs que tu télécharges ? cela voudrait dire que tu vérifie le contenu de chaque fichier ? et pourquoi alors tu ne pourrais pas le faire dans les sources posées dans le vendor/ par Composer ?
L'argument de sécurité est nul ici.
Perso je trouve ça bête pour un utilisateur final. Mais Magento n'est pas un bon exemple pour ton argumentaire. Le lien que tu montres, c'est la doc pour les développeurs (c'est marqué sur la page). Donc oui, là, utiliser Composer a un sens. Puisque si tu es développeur, cela veut dire que tu vas personnaliser Magento, lui rajouter du code pour des traitements metiers, des plugins ou que sais-je, et donc probablement installer d'autres lib (en utilisant Composer ou pas).
Pour les utilisateurs finaux, il faut aller voir sur le site pour les utilisateurs. Et qu'y trouve-t-on ? Oh, miracle, des tar.gz prêts à l'emploi ! ;-)
Tu parlais de projets libre. Alors, à moins que pour toi une lib libre n'est pas un projet libre, je ne vois pas de différence.
Tu passes de PHP à Bootstrap, du coq à l'âne, donc des problématiques différentes. J'avoue que ton discours est très difficile à suivre.
Oui donc, au final, dans un projet, si tu utilises 25 libs, tu as alors 25 autoloaders, qui font quasiment la même chose. Bonjour les perfs. Avec Composer : on peut avoir un seul autoloader, en particulier si on utilise les namespaces (il est possible de lui indiquer des autoloaders spécifiques si nécessaire, par exemple ceux des libs ayant un autoloader spécifique).
Justement, avec Composer, on a encore moins à s'en charger, puisqu'il y a au final 0 include à faire après avoir installé une lib. Alors que, pour une lib "non composerifiée", il faut que tu saches quel fichier inclure (celui qui fait tout les includes de la lib ou qui déclare l'autoloader de la lib).
[^] # Re: à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 5.
Moi quand je code, je veux faire les choses vite et bien, parce que ce qui m’intéresse, c'est avant tout de pouvoir répondre à un besoin. Alors si l'installation d'une lib est simplifiée, si les développeurs peuvent installer mon framework en déclarant une petite dépendance et en tapant une seule ligne de commande, ça me va.
Tu parles d'un utilisateur, ou d'un développeur ? Parce que si c'est pour fournir une application finale (un truc comme wordpress ou phpbb) destinée aux utilisateurs, oui faut être con pour proposer ce genre de chose (encore que, si Composer est installé d'office par les distros, ça peut avoir du sens). Et si je ne me trompe pas, ce genre de projet proposent en général un zip pour les utilisateurs, comportant toutes les dépendances, à déposer quelque part, prêt à être utilisé.
Pour les développeurs de l'application par contre, non, Composer facilite le développement, les mises à jours des dépendances, l'installation du projet etc… Et donc Composer convient très bien au développement.
Faut pas confondre développement et utilisation. Développeur et utilisateurs.
En ce qui concerne debian et cakephp, j'ai bien l'impression que ce que tu racontes n'a rien à voir avec Composer…
Désolé, mais tu me fais bien rire là :-) La majorité des packages installables par Composer sont des projets libres. Donc pour ces projets, ce n'est pas la solution ??? Pourquoi ils sont dans Composer alors ? Pourquoi c'est autant utilisés ?
Gniiii ??? c'est quoi cette histoire ? Pourquoi il ne faudrait pas "industrialiser" ?
Parce qu'on code une appli libre, il ne faudrait pas utiliser les outils que l'on a à notre disposition pour développer, déployer, tester et tout faire à la mimine ou rien faire ???
Bah désolé, une partie de mes projets libres, je les développe sur mon temps libre (qui se restreint de plus en plus). Tout outil qui pourrait me faire gagner du temps, qui me permettrait d'être plus productif, je les utilises.
Et c'est d'autant plus intéressant que j'en profite pour découvrir des nouveaux outils ou libs, qui me permettent ensuite au niveau professionnel de monter en compétence, d'être plus productif (et donc éventuellement d'avoir plus de temps pour dev les projets libres).
J'hallucine là. Tu trolles là en fait hein ? c'est ça ?
Je vais t'apprendre un truc : n'importe quel lib proposée par Composer, tu peux l'utiliser sans Composer. Suffit juste que tu ailles chercher toi même les dépendances, et te faire un autoloader (ce qui est une perte de temps à mon avis).
[^] # Re: mocheté
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 6.
Non les traits n'est pas un paliatif. Ça n'a d'ailleurs rien à voir avec l'héritage multiple, et ça ne cherche pas à remplacer l'héritage multiple (qui pose lui même bien des problèmes dans d'autres langages).
Et il n'y a pas que PHP qui supporte les traits, il y a d'autres langages comme le tout nouveau Rust.
# Dommage
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal piratix.fr.nf : un tracker bittorent pour OS libres. Évalué à 10. Dernière modification le 15 janvier 2015 à 10:09.
Je trouve dommage que le nom du site fasse référence à la piraterie.
Les gens vont assimiler linux = warez. C'est con.
PS: ouai, ok, à priori tu milites pour le parti pirate, mais franchement sur le site, c'est pas évident à comprendre pourquoi ce mot pirate. Bref, comme pour le parti Pirate, le nom va à l'encontre des idées au final, ce qui rend le truc pas crédible.
# à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 10.
Parce que peut-être les développeurs de ces libs ne s'y sont pas vraiment intéressé ou ne veulent pas, ou sont réfractaires à certains changement ? D'ailleurs Redbean le dit bien : le gars est "conservateur".
Cela ne veut pas dire que Composer c'est de la merde.
Et tu noteras que tu cites quand même des projets vraiment vieux (voir à peine maintenu comme PHPMailer). Lourd passif donc.
M'enfin bon, même si des libs comme celle-là ne sont pas fournie en paquet Composer, c'est juste 3 lignes de code supplémentaires à rajouter dans ton composer.json pour les intégrer dans ton projet. Pas la mort quoi.
J'ai l'impression que tu ne maintiens pas de projet public pour dire ça, ou alors tu es super compétent en design web et c'est super facile pour toi de pondre un design html/css.
J'ai plusieurs projets open source en PHP que je développe et maintien depuis des années. J'ai beau être compétent techniquement en HTML et CSS, je peux te dire une chose : ça me fais chier grave de faire les sites web de mes projets. Parce que je suis incompétent en design web et du coup, quand il faut que je refasse l'un deux, j'y passe des jours pour que ça ressemble à quelque chose. Ce temps, je préfère le passer à développer la lib. Donc je comprend très bien ceux qui choisissent bootstrap ou autre trucs "pour se faciliter la vie".
Ça c'est normal : le site de Smarty n'a pas bougé depuis 10 ans. Idem pour PHPMailer. Ils sont probablement comme moi : ils préfèrent passer du temps sur leur lib que sur le design de leur site.
Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc…
parce que j'ai l'impression que tu n'as pas trop en tête les avantages qu'ils offrent…
Je te rassures, même avant tout le monde boudait Pear. Quelle a été la proportion de lib et de projets qui proposait un paquet Pear ? 0,5% ? 1%? Franchement on n'y trouvait pas grand chose.
Et maintenant avec Composer ? 70%, 80%, 90% ? Le nombre de projets dispo via Composer est sans commune mesure avec Pear.
Et si Composer a un tel succès, c'est bien parce qu'il offre quelque chose de mieux non ?
Perso je n'ai jamais aimé Pear.
Déjà, c'est un truc hyper fermé : il faut que ton projet respecte certaines règles, notamment le coding style (que je trouve horrible). Ensuite, il faut qu'il soit accepté par les gens qui gère Pear. Tu ne peux pas avoir de doublons en terme de fonctionnalité avec une autre lib. Au final, Pear ne propose pas grand chose. Ou alors des usines à gaz. Interroge toi par exemple pourquoi tu as choisi PHPMailer plutôt que leur lib de mail.
Ensuite, sur le serveur (en particulier avec Debian), ton depôt PEAR est forcément partagé par tous tes projets. Au final, tu te retrouve coincé : tu ne peux pas mettre à jour au risque de casser tes vieux projets, et donc tu ne peux pas profiter des dernières versions pour des nouveaux projets. Et même si tu veux mettre à jour, c'est la galère avec debian, on ne sait jamais ce qu'il faut faire vraiment (y a toujours eu des trucs qui cassaient chez moi). Ne serait-ce que pour mettre à jour PHPUnit avec Pear. ça a toujours été la galère (à cause principalement qu'il faille faire ça en sudo, qu'il faille modifier le include_path dans la conf PHP etc).
Alors qu'avec Composer, tu as un dépôt par projet, chaque projet évolue comme il veut, utilise les paquets qu'il veut. PHPUnit et les autres paquetes s'installent en deux coup de cuillère à pot. Pas besoin de droits spéciaux sur le système pour les installer. Peu importe au final le système : ton projet reste indépendant.
M'enfin comme tu l'as dit toi même Pear c'est plus un Framework qu'un gestionnaire de dépendance. Donc au final, peu de rapport avec Composer.
Les gros avantages de Composer, c'est qu'il fait un seul truc et le fait bien : installer des paquets et gérer les dépendances. Un apt pour PHP.
L'autre gros avantage de Composer : il génère un autoloader. Adieu tous les includes dans tout les sens pour charger une lib ! Et si en plus les lib utilisent les namespaces (en respectant PSR-0 ou PSR-4), l'autoloader est beaucoup plus efficace.
À l'usage on se rend compte que ça apporte plus de souplesse, moins de tracas, et plus de perf (pas de chargement de classes non utilisées).
Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur. Je ne sais pas où tu as lu ça. Pour le moment, ils ont des recommandations pour le nommage des classes (PSR-0 et PSR-4), afin de faciliter le développement des autoloaders (que l'on n'a plus à développer si on utilise Composer), des recommandations sur le coding style (PSR-1 et PSR-2), et une recommandation sur l'interface d'un objet qui fait du log. Et ce qui est en discussion actuellement ce sont d'autres interfaces pour d'autres types d'objets courant (gestionnaire de cache, lib http…).
(donc non, ça ne servira pas qu'à Composer).
Bref, ce sont des choses pour améliorer l'interopérabilité entre les frameworks. Rien à voir avec la conf des serveurs.
Et puis ce ne sont que des recommandations. Pas obligé de les suivre.
Composer installe ce que les paquets ont besoin, pas plus, pas moins. Si un paquet a une dépendance envers un autre paquet et qu'il n'utilise pas, la faute est au développeur, pas à Composer. Mauvais paquet, changer paquet. (ça tombe bien, contrairement à Pear, le choix est très vaste).
Avec la nouvelle api password de PHP, cette lib est devenu inutile et obsolète (voir dangereuse, vu qu'elle n'est plus maintenue ?).
Les namespaces, c'est bon, mangez-en : ça évite les collisions de classes entre libs, ça facilite l'autoloading, ça permet une programmation moderne, ça force (un peu) à mieux organiser son code.
Je suis en train de "namespacer" mon framework, ça fait beaucoup de bien au final.
Pour finir, Composer, on peut s'en passer, mais c'est devenu la norme maintenant pour distribuer et installer des libs en PHP. L'ignorer ou le dénigrer n'aidera pas dans tes projets présent et futurs.
[^] # Re: Un bookmark légèrement plus fourni ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Weboob, la consécration. Évalué à 0.
bah pour des utilisateurs qui veulent pas voir des noms pareils à chaque fois qu'ils ouvrent leur gestionnaire d'applis.
Non, ce n'est pas comme les caricatures. Si on prend l'exemple de celles de Charlie Hebdo : si tu n'aimes pas, tu n'achètes pas le journal. Contrairement à ici où c'est imposé. On peut toujours changer de système d'exploitation, mais c'est plus compliqué que d’arrêter d'acheter un journal.
pour des gens qui donnent leur avis ? ils ont ce droit il me semble, non ?
[^] # Re: Et pourtant une autre révolution est en marche
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tesla Motors VS the rest of the world. Évalué à 5.
oui, mais si c'est un policier qui fait signe de passer ?
[^] # Re: Chiffres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des nouvelles d'Electrolysis II. Évalué à 3.
Vu le nombre de bug ouvert qui bloquent la mise en prod d'electrolysis, et qui concernent des crashs ou des trucs qui ne fonctionnent plus, je dirais que ce n'est pas encore super stable :-)
Mais il est bien tout de même de tenter l'aventure et de, si possible, rapporter les bugs, afin d'aider à stabiliser cela au plus vite.
[^] # Re: Hello et TokBox business model ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 2.
à priori, tu ne sembles pas comprendre comment fonctionne les plugins (aka les trucs qui se charges avec une balise object en html). Il ne t'ai pas venu à l'idée que si ils n'ont pas utilisé cela, c'est que c'était inadapté ? (les plugins sont des boites noires sur lesquels le navigateur n'a AUCUN contrôle, y compris graphique, donc intégration très limités dans les pages web).
Là tu parles des extensions XUL, pas des plugins. Un truc totalement différent.
Bah oui tient bien sûr ! Pourquoi ils n'y ont pas pensé ?? Franchement, ces développeurs, c'est tous des incompétents !
C'est vrai quoi, n'importe quel libs peut "se pluginiser" !
Non, sérieusement, tu es développeur ?
Tu as vu le nombre d'options ? Tu crois que Mozilla a les ressources nécessaires pour tester tous les cas de figure ?
Sans compter que certaines options sont des contributions externes pour des besoins spécifiques, donc non maintenue par Mozilla. D'autres sont des options qui sont là parce qu'elles étaient nécessaires lors du développement de telle ou telle fonctionnalité, puis oubliée par la suite. Enfin il peut aussi y avoir des bugs. Tu as indiqués ces bugs ? Tu es allé demander une solution ?
Peut-être parce que faire une transition franche de cette sorte, ça se fait pas en 2 secondes, que c'est très compliqué pour un projet de cet envergure. et que ça pourrait bloquer le développement d'autres choses plus prioritaires pendant un certain temps ? Et puis de toute façon, pourquoi tu demandes ça ici ? tu ne trouves pas que tu devrais plutôt demander ça directement à ceux qui le développent ?
[^] # Re: Hello et TokBox business model ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 4.
Non mais là, désolé de te le dire, tu pousses un peu loin. Une ligne de commande à taper pour récupérer les sources. c'est indiqué noir sur blanc dans la doc. Tu peux même télécharger direct sans cloner. Je ne sais pas ce qu'il faut de plus sérieusement. Ta remarque (et d'autres de tes commentaires), me fait penser de plus en plus que le problème en fait se situe entre la chaise et le clavier. C'est à dire une incompétence sur le fonctionnement d'un gros projet comme Firefox (non, désolé, désactiver des trucs pas désactivables dans un gros projet, ça se fait pas en indiquant 2 options et faire deux hack pourri), et probablement une inexpérience en développement.
En fait, je te trouve bien naïf. Par exemple quand tu dis que tu trouves Firefox trop lent et que tu veux compiler pour tenter de trouver toi-même là où ça coince. Sérieusement. Des millions de lignes de codes. Des millions. Provenant de libs diverses et variées. Un navigateur, c'est pas un "hello world". Y a des centaines de paramètres qui rentrent en jeux dans les perfs de Firefox (la manière dont il boot, le moteur JS, le moteur de rendu, la pile réseau, les lib graphique, Cairo, GTK, Sqlite, le code des sites web, le système de garbage collector, XPCOM etc..). Bref, tout un programme (à lire absolument si tu veux te plonger vraiment sur le sujet). Des personnes travaillent à plein temps dessus, et toi tu espères (sans rien connaître au projet et en gueulant ici) trouver magiquement le code responsable des mauvaises perfs avec un build en mode debug et ton gdb.
L'idée de vouloir améliorer les perfs, c'est sympa, et ton aide sera la bienvenue. Mais seulement si tu t'aides d'abord toi même, (en ne restant pas dans ton coin et en demandant de l'aide). Et commence d'abord par faire un truc simple plutôt que de vouloir révolutionner le monde. Bref, rester humble et laisser de coté son ego.
Commence par apprendre comment fonctionne le projet, apprend à utiliser les outils, documente toi, pose des questions sur les canaux de discussions de Mozilla. Je t'ai déjà donné les billes pour ça.
Bref, faire comme pour tous projets libre dans lesquels on veut s'investir.
[^] # Re: Hello et TokBox business model ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 2.
Désolé, je n'ai pas dû comprendre ce que tu voulais faire exactement. Tu veux faire un fork de Firefox avec tes histoires de build pour n'avoir que des fenêtre seules. Je t'indique une piste qui t'évite cette pénible étape et tu n'es pas encore content ??
c'est pourtant ce que je viens de faire à l'instant…
20 minutes plus tard, j'ai pu lancer firefox.
Maintenant, si tu changes plein de trucs, oui, le build peut planter…
Peut-être as-tu oublié d'indiquer d'autres flags, ou alors qu'il y ait un bug de compil. Je doute que la désactivation de ce genre de fonctionnalité soit beaucoup utilisée et donc personne chez Mozilla ne se rend compte de ce genre de problème.
Parles-en sur les newsgroup ou sur irc.mozilla.org #developers. Et sinon http://bugzilla.mozilla.org. ça sera je pense plus constructif pour toi…
```
[^] # Re: Hello et TokBox business model ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 2.
Je ne comprend pas. Firefox te permet d'ouvrir tes pages webs dans une fenêtre séparée. Je crois même qu'en modifiant la pref browser.link.open_newwindow ça peut se faire automatiquement quand on clique sur un lien… Il y a d'ailleurs une extension qui semble faire ce que tu veux.
Pour le build, y a de la doc, à priori, suffit de suivre les instructions à la lettre. À moins que tu ais un système exotique ?
[^] # Re: La question à 100 balles ... ils utilisent quel logiciel de mail chez Mozilla ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Du nouveau pour Thunderbird. Évalué à 4.
Ils ne sont plus le client majoritaire de Mozilla depuis quelques semaines
[^] # Re: Et le support standard du HTML 5 ??
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 9.
Oui, il y a des bugs non corrigés existants depuis des lustres.
Et non, ce n'est pas volontaire de la part des développeurs ou de leur hiérarchie, de laisser ces bugs pourrir.
C'est juste qu'ils n'ont pas le temps de tout faire. C'est juste parce qu'un projet comme celui là, il y a des milliards de choses à faire. Et qu'il y a des priorités.
Et non, ne pas développer Hello ou autre trucs qui vous semblent futiles dans le navigateur, ne vas pas donner plus de temps pour corriger les bugs que tu pointes. Tout simplement parce que ce ne sont pas les mêmes personnes qui travaillent sur ces parties. Et ce ne sont pas les mêmes personnes, parce que cela n'exige pas les mêmes compétences.
Pour les problèmes CSS, cela exige une connaissance sur le moteur de rendu, donc des compétences en C++, en algo de reflow et cie, en architecture d'un moteur de rendu HTML, et surtout, une connaissance du code source existant (très complexe). Faire un Hello, ça exige des connaissances en JS/HTML pour l'interface, et C++ pour l'implem de WebRTC, des connaissances poussées sur WebRTC (qui est une spec bien complexe ). Faire un outil de debug, ça nécessite aussi du JS/HTML pour l'UI, mais aussi des connaissances poussées sur le moteur JS (en C/C++), bien complexe lui aussi, pour implémenter par exemple les API de debugs etc..
Bref, chacun a sa spécialité. Le nombre de personne qui ont une connaissance approfondie de l’entièreté du code de Gecko (je ne parle que de Gecko, pas de l'interface de Firefox et ses composants périphériques comme Hello etc), on doit les compter sur les doigts des deux mains. Si ce n'est qu'une seule.
Moi par exemple dans Gecko, ma spécialité était le serializer HTML/XML, l’implémentation des élements DOM XUL, et l'éditeur HTML (le truc qui sert à avoir des champs de saisie dans une page web, ou à pouvoir éditer une page en wysiwyg avec le mode contenteditable). Mais je suis totalement incapable de toucher à un truc dans le layout engine (css et cie quoi), ni au moteur JS. Au delà de savoir si j'aurais eu suffisamment les compétences pour toucher à cette partie (très complexe), je n'avais surtout pas le temps de me plonger dedans (en tant que bénévole). Ce à quoi je contribuais m'en prenais déjà énormément.
Et sur les parties sur lesquelles je contribuais, il y a là aussi des dizaines de bugs non résolu depuis des lustres : pas le temps de tout corriger. Il faut faire alors un choix. Ok ce bug A emmerde quelques utilisateurs, et il est là depuis des lustres, mais il y a ce bug B, plus récent certes, mais qui emmerdent beaucoup beaucoup plus de monde. Donc corrigeons ce Bug B. J'aimerais bien corriger aussi le bug C, mais là, il n'y a pas énormément de tests sur le code existants, et ce qu'il faut modifier risque de casser plein de trucs. Donc ça va prendre énormément pour développer tous les tests. Ah oui mais là le truc a un comportement bizarre : bug, oubli ou feature mal spécifiée ? Le bug C que je croyais pouvoir corriger en quelques heures va me prendre des journées entières, parce qu'il va falloir que j'étudie du code source et des specs à tire-larigo. Bon ben le bug C, ça sera pour quelqu'un d'autre. Ah, et puis y a le bug D. Trop important. C'est une feature totalement nouvelle dans HTML5, que les développeurs veulent tout de suite parce que trop kikoolol et que les autres nav ont déjà implémenté. Donc allons-y pour le bug D.
etc. etc. etc..
Voilà à quoi peut ressembler les contributions d'un bénévole. Pour un employé Mozilla, ils ont moins de latitudes à choisir. Faut qu'ils développent les nouvelles features. Parce que bon, y a des râleurs qui se plaignent du retard en HTML5 etc, alors faut qu'on avance. Hein ? quoi ? ah, faut aussi corriger les bugs vieux de 8 ans ? Ah bah oui mais faut savoir ce qu'ils veulent aussi…
Firefox est un gros projet. Et comme tout gros projets, il y a des choses qui ne sont pas corrigés, parce qu'il y a des choses plus prioritaires que d'autres, parce que le nombre de dev travaillant sur une partie n'est pas illimités, parce qu'un dev travaillant sur une partie n'est pas forcément compétent pour travailler sur une autre partie.
Donc voilà. Ok, y a 3 bugs qui t'agacent. Je te comprends. Moi-même j'en ai. Mais pas les même. Bref, y en a des centaines.
Mais je te rassure, c'est pareil ailleurs : il y a aussi des milliers de vieux bugs non corrigés sur Webkit concernant CSS. Idem sur les autres.
Ce sont des projets trop complexes, impossible de tout corriger, de tout s'occuper. Surtout pour une organization comme Mozilla qui est touuuuute petite à coté de ses concurrents…