L'auteur reproche aux « App » de n'être que des sites web spécifiques à Chrome, mais ces sites sont le système d'extension de Google
Oui et non. Il faut distinguer app et extension. Les apps ne sont pas des extensions, mais des sites webs. Et par définition, les sites webs devraient être accessibles à tout navigateurs, puisqu'ils sont censés respecter les standards du web.
Or le problème, c'est que ces applis sont "optimisées" pour Chrome. Et il n'y a pas que les apps de leur appstore, mais aussi des services google. Tu n'as pas chrome ? tu n'as le droit qu'à un site dégradé.
C'est franchement dommage, d'autant plus que pour pas mal de chose, comme par exemple en CSS, il suffit de dupliquer certaines propriétés en remplaçant le préfixe.
personne n'a jamais reproché à Firefox d'avoir des extensions spécifiques qui ne sont pas utilisables sur Opera par exemple
Non, mais tu compares des choux et des carottes.
Le système d'extension de Firefox a plus de dix ans (il y était déjà dans les premières releases alpha de la suite Mozilla, même si il n'y avait pas la boite de dialogue pour les gérer).
Et une extension Firefox n'est pas un simple bout de code HTML/JS, pour la simple et bonne raison que ce qu'on pouvait faire avec HTML (la version 4 en l'occurrence), était plus que limité à l'époque. Donc il fallait que Mozilla fournisse un autre moyen d'étendre son navigateur. Et même aujourd'hui, ce qu'on pourrait faire avec une extension HTML/JS, reste limité par rapport à ce qu'on peut faire avec du XUL (puisque dans une extension Firefox, on a accès à une tonne d'API interne, on peut faire des composants binaires; aucune limite quoi).
Bref, tu oublies qu'il y a un historique, et ce n'est qu'aujourd'hui que l'on peut commencer à envisager de faire des choses puissantes avec les technologies HTML5.
Donc si personne n'a râlé contre Mozilla pour son système d'extension, c'est qu'il n'existait pas d'autres choix technologiques. Des trucs en HTML/JS n'étaient pas envisageables.
Depuis quelques années, il y a une volonté de la part de beaucoup d'acteurs, de pousser HTML pour faire des applis, et donc de le faire évoluer, parce que cela a une caractéristique intéressante : il suffit d'un browser pour l'exécuter, et donc tout le monde peut y accéder.
Google semble cependant dériver, à faire (ou à encourager à faire) de plus en plus de services et d'appli qui soient "optimisés pour Chrome". Si ça continue, avec la part de marché croissante, on va se retrouver comme en 2001 : un navigateur dominant, et des sites "optimisées" pour Chrome. Comme IE6.
"don't be evil", mais bon, leur stratégie semble être celle du loup dans la bergerie, "on suit les standards mais presque". Et si les autres ne suivent pas, tant pis pour eux, "et tant mieux pour nous, on va pouvoir canaliser les utilisateurs vers nos services, et donc gagner encore plus de millions".
Google n'est pas une entreprise philanthrope, faut se le rappeler.
oui, quand quelque chose est cassé, y a plusieurs fragments. logique. Mais ça ne fonctionne plus.
Or l'API ici fonctionne à priori, même si elle est séparée (split) en plusieurs éléments.
Quand une API (ou du code..) est "broken", en général, cela veut dire qu'elle est cassé. Elle ne fonctionne plus. Fais une recherche sur google avec "api broken", tu verras que ça ne parle que d'API qui ne fonctionnent plus.
Je ne pense pas qu'il faille dire "broken". Car broken, ça veux plutôt dire "cassé" au sens, "ça ne fonctionne plus". Je pense qu'il faudrait plutôt dire "API is split into..."
Oui mais non. Mercurial permet d'identifier un commit par deux choses : un hash effectivement, et son ordre sur le dépôt local (qui peut bien sûr ne pas être le même sur un clone). Sur une machine de build/release, qui a donc forcément un clone, elle pourrait très bien se basée sur ce numéro d'ordre.
hg tip --template "{rev}"
C'est ce que je fais pour faire les releases de snapshot du trunk de mes projets..
Tu n'as pas dis sur quelle plateforme tu as fait ces tests. Si c'est sur windows avec Direct2D, ton résultat avec canvas n'est pas normal, puisqu'une nouvelle lib graphique, Azure, a été inclus dans Firefox 7 pour ça.
Pour tout le reste (canvas sous linux/mac, et SVG partout), Firefox utilise Cairo comme lib graphique. Et Cairo ça sux un peu niveau performance. Depuis plusieurs mois donc, ils sont sur le développement de cette nouvelle lib Azure, mais pour le moment donc, seul le backend windows Direct2D est dispo.
Tu aimes le projet Mozilla ? Tu aimerais que ça bouge autrement ? Fais-toi plaisir, va contribuer.
Mozilla accueille des contributeurs à tout les niveaux : marketing, release, IT, localisation, ingénierie, dev des sites web etc... Y a de quoi faire, quel que soit ton profil et ton créneau. Va donc essayer de participer comme ça chez Chrome par exemple (ah ah !). Y a pas que le code dans un projet.
Si Mozilla a fait une erreur au niveau de leur Fast Release Cycle, c'est parce qu'il y a eu un manque d'études de toutes les conséquences, c'est sûr, mais c'est probablement aussi qu'il n'y avait pas assez de personnes pour leur dire avant, "hey, ho, attention, il va y avoir tel ou tel problème si vous prenez telle décision, voici ce que je propose". Parce que Mozilla ne peut pas être partout, dans toutes les entreprises, chez tous les particuliers, pour leur demander ce qu'ils utilisent et comment.
Il y a toujours des gens pour dire YavaitKa après la bataille, mais avant la bataille, chacun est dans son coin et attend.
Si les entreprises, qui pour beaucoup ont gueulé et je les comprends, avaient été plus à l'écoute de ce qui se passait chez Mozilla (même si c'est pas évident aussi je le reconnais), et qu'ils faisaient un peu plus de feedback, peut être que chez Mozilla ils auraient pris un peu plus conscience du problème. Mozilla ne peut pas non plus deviner tout ce qui se passe partout avec leurs produits, surtout en entreprise.
Rappel, Mozilla, ce n'est pas Microsoft ou Google. Ils n'ont pas une armée de commerciaux et de marketeux à "l'écoute" de leur "client" prospectant chez leurs clients.
La seule force de Mozilla, c'est vous, utilisateurs. Alors n'hésitez pas à aller contribuer, ne serait-ce qu'en allant participer aux discussions qui vous intéressent dans les newsgroup Mozilla.
Si vous êtes 50 à vous plaindre dans une discussion sur un futur projet, ça passera moins inaperçu que si il n'y a qu'un seul pauvre gars qui tente de se faire entendre au milieu de toutes ces discussions.
Tu te plains du manque de communication ? Bien. Alors, tu as le choix. Soit tu fais dons de quelques millions afin que Mozilla mettent des affiches 4x3 dans toutes les grandes villes comme Google a fait pour Chrome (on ne le voit pas trop en France, mais le budget marketing de Chrome est hallucinant aux US). Soit tu commences par ajouter dans ton agrégateur http://planet.mozilla.org , et tu seras alors au courant de beaucoup de chose. Et tu pourras alors réagir si tu vois qu'il y a un truc en préparation qui ne te semble pas judicieux.
Cette course à la numérotation m'embête au plus haut point, elle est inutile et néfaste pour les utilisateurs qui ne savent plus où ils en sont.
s/utilisateurs/geek
Les utilisateurs s'en fichent du numéro de version. Et ça ne gênent vraiment que les geeks : la preuve est dans les stats. Il n'y a pas eu de désertion massive depuis la 4.
Pour les entreprises, ça ne les gêne pas non plus. Ce qui les gêne, c'est qu'il n'y ait pas de LTS (appelée ESR chez Mozilla). Mais ça va être résolut d'ici la fin de l'année, avec des ESR de plus d'un an (54 semaines) avec une ESR par an. Firefox 10 ou 11 sera la prochaine ESR.
Notez également qu'au début 2012, les mises à jours seront silencieuses par défaut. L'utilisateur sera encore moins "ennuyé" par les numéros de version (si tant est qu'il l'était). Et je parie qu'il n'y aura pas plus de défection que ça. D'ailleurs l'augmentation fulgurante du nombre d'utilisateurs de chrome prouve bien que ces utilisateurs en ont rien à foutre du numéro de version et des mises à jour.
c'est plus facile de savoir où on en est par rapport aux versions majeures,
Justement, ce que tu n'as pas compris, c'est qu'il n'y a plus la notion de version majeure ou mineure.
les utilisateurs (et les développeurs web) n'ont pas à attendre 1 an ou 2 pour profiter des nouvelles améliorations.
au lieu de sortir des versions sans saveurs.
au niveau interface, c'était cosmétique jusqu'ici, mais tu auras des versions avec plus de changements visuels. Et tu les auras dés que leur développement sera terminé, tu n'auras pas à attendre 1 an ou 2 qu'une version "majeure" sorte. (Par ex, les nouveaux outils développeurs dans Fx 10).
On est vendredi, c'est la journée des Trolls. Par contre, on n'a jamais dit que c'était la journée du FUD.
Journal raté donc.
Tout ceux qui suivent d'assez près le projet Mozilla savent que tout le contenu de ce journal est rempli d'informations fausses et de raccourcis à la con aboutissant à des conclusions débiles.
alors qu'il y a quelques années mozilla disait que XUL était l'avenir
Ils n'ont jamais vraiment dit ça. Par contre, c'est peut être de ma faute si tu le penses, puisque c'est plus ou moins ce que je disais à l'époque sur xulfr.org et ailleurs, croyant au développement de XulRunner &co. Et puis patatra, un jour Mozilla annonça que XulRunner ne sera jamais un "produit" (ils l'ont fait parce que je pense qu'ils se rendaient compte que XulRunner prenait trop d'ampleur, et que ça allait gêner le développement de Firefox dans le futur).
Et comme toi je fus extrêmement déçu... XulRunner et XUL restera un truc de geek, pas une technologie utilisée massivement en dehors de Firefox et TB.
Si au contraire. Le terme Webapp est peut être utilisé à tord, mais dans le cas de B2G, ça ne veut pas dire hebergé sur un serveur. Une webapp au sens B2G, est une appli qui utilise les technos web, mais qui est packagée pour être installé sur le téléphone. Heureusement encore, parce que si il fallait obligatoirement une connectivité pour faire fonctionner la moindre appli :-)
Euh si.. Tout est en XUL dans seamonkey. Depuis 99, tous les produits Mozilla (ou dérivé) sont en XUL. (Mozilla suite, Firefox, Thunderbird, Sunbird...).
Kompozer est le descendant de Nvu, qui est un descendant de l'éditeur Composer, qui était fourni dans la suite mozilla. Donc eux aussi en XUL.
comme moins-value que, bah, le code est pas natif.
à l'heure actuel, les applis dans android sont en java. Donc déjà pas en code natif. y a probablement du JIT, mais bon, les applis web aussi c'est pareil, y a du JIT au niveau javascript (la lourdeur java en moins).
Bref, je ne vois pas de moins value là dedans.
La moins value que je vois (c'est mon opinion), c'est que developper une webapp va être probablement plus long, car on n'a pas forcément tous les widgets d'interface prêt à l'emploi que l'on dispose dans le toolkit d'android par exemple (bon, j'y connais pas grand chose à android non plus). à moins que Mozilla passe la seconde sur un remplaçant standardisé de XBL (permettant de développer des composants réutilisables).
De ce que j'ai compris : ils partent d'android pour ne pas avoir à démarrer from scratch et pouvoir aussi utiliser au minimum le téléphone pour tester les nouvelles api. Et petit à petit ils vont remplacer les applis natives par des webapp.
à priori, au final, il ne restera d'android pas grand chose, si ce n'est le noyau linux et ce qui va autour au niveau système. Si j'ai bien compris. :-)
Est-il beaucoup plus compliqué d'embarquer un webkit qu'un gecko ?
Je pense que tu veux dire l'inverse. Oui, gecko est plus compliqué à embarqué que webkit. En même temps, gecko est plus fait pour embarquer (cf xulrunner), que pour être embarqué. Et puis l'API d'embedding a été supprimé recement car plus maintenue et super trop obsolète. Une discussion a eu lieu sur gecko embedding au mozcamp de ce week end, avec notamment des packageurs linux (dont Glandium, pour Debian, packageur officiel pour les softs mozilla). Est ce qu'il y a un intérêt à refaire une API embedding ? qui a besoin d'embedding etc. Si vous vous sentez concerné, allez en discuter sur les newsgroup de mozilla (voir google groups)
mais là si on pense au "support" de XUL, on se dit que Mozilla n'a malheureusement jamais su faire de ses produits une vrai plateforme
Ce n'est pas une question de n'avoir pas su faire, c'était une question de volonté, une question politique produit. La principale raison : si ils avaient voulu faire de la plateforme un vrai produit (genre promouvoir XulRunner etc), ils auraient été obligé de gelée un certain nombre d'API, ils auraient eu plus de boulot parce qu'il y aura fatalement eu des choses à développer et à corriger qui n'ont pas de rapport avec Firefox. Or, la guerre des navigateurs sévi, le web se propriétise de plus en plus et Firefox est devenu le fer de lance de Mozilla. C'est LE produit par lequel Mozilla peut se faire entendre, peut promouvoir un web libre et ouvert (cf le manifesto mozilla). Ne pas supporter officiellement la plateforme gecko (par XulRunner etc), permet aux développeurs mozilla de faire évoluer gecko dans la direction qu'ils veulent, en toute liberté, en cassant tout ce qu'ils veulent casser quand c'est nécessaire.
Quand je dis plateforme, je parle bien de la plateforme gecko, XUL. Ce que Mozilla promeut par contre bien évidement, c'est la plateforme "web", qui est la couche au dessus si on peut dire. Et qui fait abstraction au final du navigateur (en théorie :)). On le voit d'ailleurs avec B2G : utilisation des technos web partout.
Je reviens du meeting mozcamp qui a eu lieu à Berlin ce week-end dernier, regroupant bon nombre de contributeurs européens et africains.
Et nous avons eu droit à une conf sur B2G, avec demo etc. (Sachant que je suis bien pote avec les deux français qui font parti de l'équipe B2G, Vivien et Mounir, j'ai déjà eu droit à une démo il y a quelques semaines déjà :) (ouai, je crâne grave))
Ce qu'il faut savoir donc :
Mozilla est déjà en relation avec des fabricants, qui sont très intéresses pour avoir une alternative à android.
Si la roadmap est tenu (hum), il y aura des téléphones B2G à la fin 2012
Dans le projet B2G, il y a deux projets en gros :
les API web, qui vont taper dans le système
l'interface.
L'interface sera interchangeable, personnalisable à donf par les utilisateurs ou fabricants, et pour cause : tout sera en HTML. Donc si pour le moment ça ressemble à de l'android, ça pourrait ne plus l'être dans quelques mois, ou en tout cas, des alternatives seront possibles.
le but est de permettre d'avoir des applis webphone qui soient interopérable entre webphone "html" (il y a des specs aux W3C pour les paquets webapp, je suppose qu'ils vont reprendre ça, je ne sais pas). Pas besoin de SDK apple ou windows qui coute la peau des fesses, pas besoin d'apprendre un enième langage si vous faites déjà du web. Et pas obligé de passer par un trucstore pour installer l'appli (comme les app d'android).
le but aussi est de fournir une alternative d'os qui ne soit pas dépendant obligatoire d'un fournisseur (google ou apple par ex) pour tout ce qui est données persos etc.. Les autres projets mozilla qui sont en cours et concernant le respect de la vie privée etc serviront dans B2G à priori.
pour le moment, B2G marchouille (avec pleins de bug, c'est encore super experimental) : on peut envoyer et recevoir des SMS, on peut émettre et recevoir un appel (un bug empêche pour le moment de raccrocher :-) ).
il y a encore pas mal de dépendance avec des composants android, mais ça disparaitra à l'avenir, (pour n'avoir au final qu'un linusque et un gecko avec les libs qui vont bien)
Et petit rappel : c'est un projet libre !!! Vous pouvez y contribuer !! C'est l'occasion de faire du html hard core (cool ! plus besoin de se préoccuper d'une compatibilité avec tel navigateur, vous pouvez utiliser les dernières fonctionnalités CSS et HTML sans retenu !), l'occasion de faire de la prog système (développement des apis entre autre), ou encore l'occasion de proposer des solutions qui permettent d'améliorer l'expérience utilisateur, ou encore qui permettent d'avoir une interface "différente".
Que le travail soit de fond ou pas, c'est toujours bien que l'utilisateur en profite le plus rapidement possible.
Tu oublie les développeurs web aussi. Même si dans la 8, il n'y a pas de révolutions, quand il y a des nouvelles fonctionnalités intéressantes, c'est sympa de savoir qu'on va pouvoir les utiliser rapidement, parce que la majorité des internautes auront un navigateur à jour dans une période qui se comptent en quelques semaines, plutôt qu'en mois ou années. Et c'est d'autant plus vrai que c'est la course avec les autres browsers.
Et avoir telle ou telle fonctionnalité, ça peut changer pas mal de chose dans un projet, parce que ça peut permettre probablement d'économiser du temps à trouver une alternative, ou ça peut permettre d'ouvrir de nouvelles perspectives au niveau applicatif (par exemple, l'arrivée du drag'n drop de fichiers, et la manipulation des fichiers avec FileReader, il y a quelques temps, sont des trucs qui permettent de changer la done en matière d'interface de publication de données, de photos...).
il y a surtout un problème d'utilisation du logiciel.
Apparemment, de ce que j'ai vu, les personnes qui ont rapporté ce genre de chiffres (100,150..) sont des power users.
Je pense au contraire que ce sont des personnes qui utilisent au maximum le navigateur : utilisation de panorama, utilisation de l'autocomplétion dans la barre d'adresse pour retrouver rapidement le tab ouvert etc...
Et puis quand tu codes et que tu as souvent besoin d'accéder à de la doc, à un navigateur web de code source (genre, quand tu es dev Mozilla, http://mxr.mozilla.org ), ou à un bug tracker etc, le nombre de tab peut vite augmenter, pour éviter d'avoir à relancer un moteur de recherche, ou à recharger les pages. Car ce genre de chose c'est plus lent que d'activer un tab...
perso, je peux arriver à 40-50 tabs quand je suis en mode dev.
Bref, le nombre de tab ne présage à mon avis pas d'un problème d'utilisation de logiciel. Surtout qu'il y a pas mal d'extensions qui permettent de gérer toutes ces tabs, dont celle qui a été intégré dans Firefox, "panorama".
oui le multi-process, ça ne fait pas tout, et c'est l'une des raisons je crois de leur non-empressement à l'activer. Ils préfèrent mettre leur energie sur la réduction de la mémoire et la correction des crash.
Oui en effet :-), mais j'imagine que sur mobile il y avait d'autres contraintes (que je ne connais pas) qui rendait avantageux le multi process (plus de vélocité ? ce qui est important sur ces petits processeurs).
Tu remarqueras aussi que sur un mobile, tu ne vas pas lancer 30 tab. Donc la consommation mémoire au finale, ne va pas être beaucoup plus importante.
Par contre, sur le desktop, tu arrives vite à 30-40 voir 200 tabs pour certains. Et dans ces conditions en effet, la consommation mémoire explose, on le voit avec chrome. C'est probablement aussi une des raisons qu'ils ne se pressent pas trop pour la version desktop. Ils travaillent pas mal plutôt en ce moment à réduire la consommation mémoire sur pas mal d'endroits dans Gecko : projet memshrinck ?
C'est déjà le cas depuis de nombreuses années. Sous windows tu as le selecteur de windows, sous mac, celui du mac, et sous linux, celui de gtk. Si tu es sous kde, compile toi une version avec le support qt au lieu de gtk. (le port qt existe, mais il n'y a pas de build officiel, vu qu'il ne doit pas être super super stable). Si tu es sur un autre desktop linux, bah tant pis. fait un patch.
[^] # Re: Ca m'inquiète un peu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 6.
Oui, ils comblent les quelques retards qu'ils ont (ils sont en avancent sur pas mal de trucs, mais ça, tous les trolleurs l'oublient).
Et si vous trouvez que cela ne va pas assez vite, et que vous voulez aider mozilla à garder un web ouvert et gratuit pour tous, faites un don : https://donate.mozilla.org/page/contribute/openwebfund
# pas seulement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 8.
Oui et non. Il faut distinguer app et extension. Les apps ne sont pas des extensions, mais des sites webs. Et par définition, les sites webs devraient être accessibles à tout navigateurs, puisqu'ils sont censés respecter les standards du web.
Or le problème, c'est que ces applis sont "optimisées" pour Chrome. Et il n'y a pas que les apps de leur appstore, mais aussi des services google. Tu n'as pas chrome ? tu n'as le droit qu'à un site dégradé.
C'est franchement dommage, d'autant plus que pour pas mal de chose, comme par exemple en CSS, il suffit de dupliquer certaines propriétés en remplaçant le préfixe.
Non, mais tu compares des choux et des carottes.
Le système d'extension de Firefox a plus de dix ans (il y était déjà dans les premières releases alpha de la suite Mozilla, même si il n'y avait pas la boite de dialogue pour les gérer).
Et une extension Firefox n'est pas un simple bout de code HTML/JS, pour la simple et bonne raison que ce qu'on pouvait faire avec HTML (la version 4 en l'occurrence), était plus que limité à l'époque. Donc il fallait que Mozilla fournisse un autre moyen d'étendre son navigateur. Et même aujourd'hui, ce qu'on pourrait faire avec une extension HTML/JS, reste limité par rapport à ce qu'on peut faire avec du XUL (puisque dans une extension Firefox, on a accès à une tonne d'API interne, on peut faire des composants binaires; aucune limite quoi).
Bref, tu oublies qu'il y a un historique, et ce n'est qu'aujourd'hui que l'on peut commencer à envisager de faire des choses puissantes avec les technologies HTML5.
Donc si personne n'a râlé contre Mozilla pour son système d'extension, c'est qu'il n'existait pas d'autres choix technologiques. Des trucs en HTML/JS n'étaient pas envisageables.
Depuis quelques années, il y a une volonté de la part de beaucoup d'acteurs, de pousser HTML pour faire des applis, et donc de le faire évoluer, parce que cela a une caractéristique intéressante : il suffit d'un browser pour l'exécuter, et donc tout le monde peut y accéder.
Google semble cependant dériver, à faire (ou à encourager à faire) de plus en plus de services et d'appli qui soient "optimisés pour Chrome". Si ça continue, avec la part de marché croissante, on va se retrouver comme en 2001 : un navigateur dominant, et des sites "optimisées" pour Chrome. Comme IE6.
"don't be evil", mais bon, leur stratégie semble être celle du loup dans la bergerie, "on suit les standards mais presque". Et si les autres ne suivent pas, tant pis pour eux, "et tant mieux pour nous, on va pouvoir canaliser les utilisateurs vers nos services, et donc gagner encore plus de millions".
Google n'est pas une entreprise philanthrope, faut se le rappeler.
Tout le contraire de la mission de Mozilla.
[^] # Re: L'api, elle est cassé
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Seeks en version stable 0.4. Évalué à 3.
oui, quand quelque chose est cassé, y a plusieurs fragments. logique. Mais ça ne fonctionne plus.
Or l'API ici fonctionne à priori, même si elle est séparée (split) en plusieurs éléments.
Quand une API (ou du code..) est "broken", en général, cela veut dire qu'elle est cassé. Elle ne fonctionne plus. Fais une recherche sur google avec "api broken", tu verras que ça ne parle que d'API qui ne fonctionnent plus.
# L'api, elle est cassé
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Seeks en version stable 0.4. Évalué à 5.
Juste un truc sans réèl importance au regard du travail fourni, mais qui m'a gêné.
Sur la page de l'api, http://seeks-project.info/wiki/index.php/API-0.4.0 , il est dit que "API is broken into plugin dependent fragments."
Je ne pense pas qu'il faille dire "broken". Car broken, ça veux plutôt dire "cassé" au sens, "ça ne fonctionne plus". Je pense qu'il faudrait plutôt dire "API is split into..."
my two cents :)
[^] # Re: Navigateur
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Premières impressions sur le Samsung Galaxy Note. Évalué à 2.
j'ai oublié http://fr.wikipedia.org/wiki/Compl%C3%A8tement
[^] # Re: Navigateur
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Premières impressions sur le Samsung Galaxy Note. Évalué à 3.
Eh bien non, les deux termes sont valables. Le vrai mot français étant justement "complètement". Complétion étant le mot dérivé de l'anglais.
http://fr.wikipedia.org/wiki/Compl%C3%A9tion
[^] # Re: Mise à jour
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 2.
Oui mais non. Mercurial permet d'identifier un commit par deux choses : un hash effectivement, et son ordre sur le dépôt local (qui peut bien sûr ne pas être le même sur un clone). Sur une machine de build/release, qui a donc forcément un clone, elle pourrait très bien se basée sur ce numéro d'ordre.
C'est ce que je fais pour faire les releases de snapshot du trunk de mes projets..
[^] # Re: A part le troll
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 3.
Tu n'as pas dis sur quelle plateforme tu as fait ces tests. Si c'est sur windows avec Direct2D, ton résultat avec canvas n'est pas normal, puisqu'une nouvelle lib graphique, Azure, a été inclus dans Firefox 7 pour ça.
Pour tout le reste (canvas sous linux/mac, et SVG partout), Firefox utilise Cairo comme lib graphique. Et Cairo ça sux un peu niveau performance. Depuis plusieurs mois donc, ils sont sur le développement de cette nouvelle lib Azure, mais pour le moment donc, seul le backend windows Direct2D est dispo.
les explications du pourquoi du comment :
- http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-project/
- http://www.basschouten.com/blog1.php/comparing-performance-azure-vs-cairo
Il y a eu aussi déjà pas mal d'explications là dessus sur linuxfr, faire une recherche...
[^] # Re: Troll^W FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 0.
pourtant il est clair.
Tu aimes le projet Mozilla ? Tu aimerais que ça bouge autrement ? Fais-toi plaisir, va contribuer.
Mozilla accueille des contributeurs à tout les niveaux : marketing, release, IT, localisation, ingénierie, dev des sites web etc... Y a de quoi faire, quel que soit ton profil et ton créneau. Va donc essayer de participer comme ça chez Chrome par exemple (ah ah !). Y a pas que le code dans un projet.
Si Mozilla a fait une erreur au niveau de leur Fast Release Cycle, c'est parce qu'il y a eu un manque d'études de toutes les conséquences, c'est sûr, mais c'est probablement aussi qu'il n'y avait pas assez de personnes pour leur dire avant, "hey, ho, attention, il va y avoir tel ou tel problème si vous prenez telle décision, voici ce que je propose". Parce que Mozilla ne peut pas être partout, dans toutes les entreprises, chez tous les particuliers, pour leur demander ce qu'ils utilisent et comment.
Il y a toujours des gens pour dire YavaitKa après la bataille, mais avant la bataille, chacun est dans son coin et attend.
Si les entreprises, qui pour beaucoup ont gueulé et je les comprends, avaient été plus à l'écoute de ce qui se passait chez Mozilla (même si c'est pas évident aussi je le reconnais), et qu'ils faisaient un peu plus de feedback, peut être que chez Mozilla ils auraient pris un peu plus conscience du problème. Mozilla ne peut pas non plus deviner tout ce qui se passe partout avec leurs produits, surtout en entreprise.
Rappel, Mozilla, ce n'est pas Microsoft ou Google. Ils n'ont pas une armée de commerciaux et de marketeux
à "l'écoute" de leur "client"prospectant chez leurs clients.La seule force de Mozilla, c'est vous, utilisateurs. Alors n'hésitez pas à aller contribuer, ne serait-ce qu'en allant participer aux discussions qui vous intéressent dans les newsgroup Mozilla.
Si vous êtes 50 à vous plaindre dans une discussion sur un futur projet, ça passera moins inaperçu que si il n'y a qu'un seul pauvre gars qui tente de se faire entendre au milieu de toutes ces discussions.
Tu te plains du manque de communication ? Bien. Alors, tu as le choix. Soit tu fais dons de quelques millions afin que Mozilla mettent des affiches 4x3 dans toutes les grandes villes comme Google a fait pour Chrome (on ne le voit pas trop en France, mais le budget marketing de Chrome est hallucinant aux US). Soit tu commences par ajouter dans ton agrégateur http://planet.mozilla.org , et tu seras alors au courant de beaucoup de chose. Et tu pourras alors réagir si tu vois qu'il y a un truc en préparation qui ne te semble pas judicieux.
[^] # Re: Troll^W FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 2.
s/utilisateurs/geek
Les utilisateurs s'en fichent du numéro de version. Et ça ne gênent vraiment que les geeks : la preuve est dans les stats. Il n'y a pas eu de désertion massive depuis la 4.
Pour les entreprises, ça ne les gêne pas non plus. Ce qui les gêne, c'est qu'il n'y ait pas de LTS (appelée ESR chez Mozilla). Mais ça va être résolut d'ici la fin de l'année, avec des ESR de plus d'un an (54 semaines) avec une ESR par an. Firefox 10 ou 11 sera la prochaine ESR.
Notez également qu'au début 2012, les mises à jours seront silencieuses par défaut. L'utilisateur sera encore moins "ennuyé" par les numéros de version (si tant est qu'il l'était). Et je parie qu'il n'y aura pas plus de défection que ça. D'ailleurs l'augmentation fulgurante du nombre d'utilisateurs de chrome prouve bien que ces utilisateurs en ont rien à foutre du numéro de version et des mises à jour.
Justement, ce que tu n'as pas compris, c'est qu'il n'y a plus la notion de version majeure ou mineure.
les utilisateurs (et les développeurs web) n'ont pas à attendre 1 an ou 2 pour profiter des nouvelles améliorations.
au niveau interface, c'était cosmétique jusqu'ici, mais tu auras des versions avec plus de changements visuels. Et tu les auras dés que leur développement sera terminé, tu n'auras pas à attendre 1 an ou 2 qu'une version "majeure" sorte. (Par ex, les nouveaux outils développeurs dans Fx 10).
Et puis bon, c'est pas sans saveur pour tout le monde hein:
- https://developer.mozilla.org/en/Firefox_5_for_developers
- https://developer.mozilla.org/en/Firefox_6_for_developers
- https://developer.mozilla.org/en/Firefox_7_for_developers
- https://developer.mozilla.org/en/Firefox_8_for_developers
Et il n'y aurait pas de travail de fond dans Mozilla ?
[^] # Re: Troll^W FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 2.
Je l'ai bien lu. Même un vendredi, ça m'arrive de répondre aux trolls.
Mais là, ça manque vraiment trop de subtilité, c'est trop "voyant" :-p (de mon point de vue en tout cas)
# Troll^W FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 6.
On est vendredi, c'est la journée des Trolls. Par contre, on n'a jamais dit que c'était la journée du FUD.
Journal raté donc.
Tout ceux qui suivent d'assez près le projet Mozilla savent que tout le contenu de ce journal est rempli d'informations fausses et de raccourcis à la con aboutissant à des conclusions débiles.
Je ne répondrais donc pas à ce truc.
[^] # Re: Régression
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 3.
Depuis quand on a besoin d'un serveur web pour afficher un fichier html ? ;-)
[^] # Re: Et sinon Gecko il est où ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 4.
Ils n'ont jamais vraiment dit ça. Par contre, c'est peut être de ma faute si tu le penses, puisque c'est plus ou moins ce que je disais à l'époque sur xulfr.org et ailleurs, croyant au développement de XulRunner &co. Et puis patatra, un jour Mozilla annonça que XulRunner ne sera jamais un "produit" (ils l'ont fait parce que je pense qu'ils se rendaient compte que XulRunner prenait trop d'ampleur, et que ça allait gêner le développement de Firefox dans le futur).
Et comme toi je fus extrêmement déçu... XulRunner et XUL restera un truc de geek, pas une technologie utilisée massivement en dehors de Firefox et TB.
[^] # Re: Régression
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 4.
Si au contraire. Le terme Webapp est peut être utilisé à tord, mais dans le cas de B2G, ça ne veut pas dire hebergé sur un serveur. Une webapp au sens B2G, est une appli qui utilise les technos web, mais qui est packagée pour être installé sur le téléphone. Heureusement encore, parce que si il fallait obligatoirement une connectivité pour faire fonctionner la moindre appli :-)
Donc installation, et donc mise à jour à faire. Et au niveau format de paquet, on peut imaginer que ça utilisera ça http://www.w3.org/TR/2011/REC-widgets-20110927/ . ou pas.
[^] # Re: Et sinon Gecko il est où ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 6.
Euh si.. Tout est en XUL dans seamonkey. Depuis 99, tous les produits Mozilla (ou dérivé) sont en XUL. (Mozilla suite, Firefox, Thunderbird, Sunbird...).
Kompozer est le descendant de Nvu, qui est un descendant de l'éditeur Composer, qui était fourni dans la suite mozilla. Donc eux aussi en XUL.
[^] # Re: Régression
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 3.
à l'heure actuel, les applis dans android sont en java. Donc déjà pas en code natif. y a probablement du JIT, mais bon, les applis web aussi c'est pareil, y a du JIT au niveau javascript (la lourdeur java en moins).
Bref, je ne vois pas de moins value là dedans.
La moins value que je vois (c'est mon opinion), c'est que developper une webapp va être probablement plus long, car on n'a pas forcément tous les widgets d'interface prêt à l'emploi que l'on dispose dans le toolkit d'android par exemple (bon, j'y connais pas grand chose à android non plus). à moins que Mozilla passe la seconde sur un remplaçant standardisé de XBL (permettant de développer des composants réutilisables).
[^] # Re: Concrètement ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 5.
De ce que j'ai compris : ils partent d'android pour ne pas avoir à démarrer from scratch et pouvoir aussi utiliser au minimum le téléphone pour tester les nouvelles api. Et petit à petit ils vont remplacer les applis natives par des webapp.
à priori, au final, il ne restera d'android pas grand chose, si ce n'est le noyau linux et ce qui va autour au niveau système. Si j'ai bien compris. :-)
[^] # Re: Et sinon Gecko il est où ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 7.
Je pense que ce que tu cherches, c'est ça : http://www.mozilla.org/projects/mozilla-based.html ;-)
De rien.
Je pense que tu veux dire l'inverse. Oui, gecko est plus compliqué à embarqué que webkit. En même temps, gecko est plus fait pour embarquer (cf xulrunner), que pour être embarqué. Et puis l'API d'embedding a été supprimé recement car plus maintenue et super trop obsolète. Une discussion a eu lieu sur gecko embedding au mozcamp de ce week end, avec notamment des packageurs linux (dont Glandium, pour Debian, packageur officiel pour les softs mozilla). Est ce qu'il y a un intérêt à refaire une API embedding ? qui a besoin d'embedding etc. Si vous vous sentez concerné, allez en discuter sur les newsgroup de mozilla (voir google groups)
Ce n'est pas une question de n'avoir pas su faire, c'était une question de volonté, une question politique produit. La principale raison : si ils avaient voulu faire de la plateforme un vrai produit (genre promouvoir XulRunner etc), ils auraient été obligé de gelée un certain nombre d'API, ils auraient eu plus de boulot parce qu'il y aura fatalement eu des choses à développer et à corriger qui n'ont pas de rapport avec Firefox. Or, la guerre des navigateurs sévi, le web se propriétise de plus en plus et Firefox est devenu le fer de lance de Mozilla. C'est LE produit par lequel Mozilla peut se faire entendre, peut promouvoir un web libre et ouvert (cf le manifesto mozilla). Ne pas supporter officiellement la plateforme gecko (par XulRunner etc), permet aux développeurs mozilla de faire évoluer gecko dans la direction qu'ils veulent, en toute liberté, en cassant tout ce qu'ils veulent casser quand c'est nécessaire.
Quand je dis plateforme, je parle bien de la plateforme gecko, XUL. Ce que Mozilla promeut par contre bien évidement, c'est la plateforme "web", qui est la couche au dessus si on peut dire. Et qui fait abstraction au final du navigateur (en théorie :)). On le voit d'ailleurs avec B2G : utilisation des technos web partout.
# Quelques compléments
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 10.
Hello,
Je reviens du meeting mozcamp qui a eu lieu à Berlin ce week-end dernier, regroupant bon nombre de contributeurs européens et africains.
Et nous avons eu droit à une conf sur B2G, avec demo etc. (Sachant que je suis bien pote avec les deux français qui font parti de l'équipe B2G, Vivien et Mounir, j'ai déjà eu droit à une démo il y a quelques semaines déjà :) (ouai, je crâne grave))
Ce qu'il faut savoir donc :
Et petit rappel : c'est un projet libre !!! Vous pouvez y contribuer !! C'est l'occasion de faire du html hard core (cool ! plus besoin de se préoccuper d'une compatibilité avec tel navigateur, vous pouvez utiliser les dernières fonctionnalités CSS et HTML sans retenu !), l'occasion de faire de la prog système (développement des apis entre autre), ou encore l'occasion de proposer des solutions qui permettent d'améliorer l'expérience utilisateur, ou encore qui permettent d'avoir une interface "différente".
[^] # Re: Firefox 9
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 7.
Que le travail soit de fond ou pas, c'est toujours bien que l'utilisateur en profite le plus rapidement possible.
Tu oublie les développeurs web aussi. Même si dans la 8, il n'y a pas de révolutions, quand il y a des nouvelles fonctionnalités intéressantes, c'est sympa de savoir qu'on va pouvoir les utiliser rapidement, parce que la majorité des internautes auront un navigateur à jour dans une période qui se comptent en quelques semaines, plutôt qu'en mois ou années. Et c'est d'autant plus vrai que c'est la course avec les autres browsers.
Et avoir telle ou telle fonctionnalité, ça peut changer pas mal de chose dans un projet, parce que ça peut permettre probablement d'économiser du temps à trouver une alternative, ou ça peut permettre d'ouvrir de nouvelles perspectives au niveau applicatif (par exemple, l'arrivée du drag'n drop de fichiers, et la manipulation des fichiers avec FileReader, il y a quelques temps, sont des trucs qui permettent de changer la done en matière d'interface de publication de données, de photos...).
[^] # Re: Firefox 9
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 9.
Apparemment, de ce que j'ai vu, les personnes qui ont rapporté ce genre de chiffres (100,150..) sont des power users.
Je pense au contraire que ce sont des personnes qui utilisent au maximum le navigateur : utilisation de panorama, utilisation de l'autocomplétion dans la barre d'adresse pour retrouver rapidement le tab ouvert etc...
Et puis quand tu codes et que tu as souvent besoin d'accéder à de la doc, à un navigateur web de code source (genre, quand tu es dev Mozilla, http://mxr.mozilla.org ), ou à un bug tracker etc, le nombre de tab peut vite augmenter, pour éviter d'avoir à relancer un moteur de recherche, ou à recharger les pages. Car ce genre de chose c'est plus lent que d'activer un tab...
perso, je peux arriver à 40-50 tabs quand je suis en mode dev.
Bref, le nombre de tab ne présage à mon avis pas d'un problème d'utilisation de logiciel. Surtout qu'il y a pas mal d'extensions qui permettent de gérer toutes ces tabs, dont celle qui a été intégré dans Firefox, "panorama".
[^] # Re: Toujours pas de multithread
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 3.
oui le multi-process, ça ne fait pas tout, et c'est l'une des raisons je crois de leur non-empressement à l'activer. Ils préfèrent mettre leur energie sur la réduction de la mémoire et la correction des crash.
[^] # Re: Firefox 9
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 7.
Oui en effet :-), mais j'imagine que sur mobile il y avait d'autres contraintes (que je ne connais pas) qui rendait avantageux le multi process (plus de vélocité ? ce qui est important sur ces petits processeurs).
Tu remarqueras aussi que sur un mobile, tu ne vas pas lancer 30 tab. Donc la consommation mémoire au finale, ne va pas être beaucoup plus importante.
Par contre, sur le desktop, tu arrives vite à 30-40 voir 200 tabs pour certains. Et dans ces conditions en effet, la consommation mémoire explose, on le voit avec chrome. C'est probablement aussi une des raisons qu'ils ne se pressent pas trop pour la version desktop. Ils travaillent pas mal plutôt en ce moment à réduire la consommation mémoire sur pas mal d'endroits dans Gecko : projet memshrinck ?
[^] # Re: Amélioration du sélecteur de fichiers
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 0.
C'est déjà le cas depuis de nombreuses années. Sous windows tu as le selecteur de windows, sous mac, celui du mac, et sous linux, celui de gtk. Si tu es sous kde, compile toi une version avec le support qt au lieu de gtk. (le port qt existe, mais il n'y a pas de build officiel, vu qu'il ne doit pas être super super stable). Si tu es sur un autre desktop linux, bah tant pis. fait un patch.