Paul Rouget a écrit 207 commentaires

Quelle est la manière propre de faire?

Je ne sais pas comment ça marche, mais c'est peut-être ça dont tu parles:
http://hg.mozilla.org/mozilla-central/rev/2572312e17df

> encore une preuve que le support des systèmes libre par la fondation Mozilla n'est pas une priorité.

Arrétez avec ça, ça devient vraiment gonflant. En tout cas, c'est pas avec des commentaires comme ça que tu vas nous aider. Ouvre plutot des bugs au lieu de nous cracher dessus.

Et bien je pense que ma liste énorme est bien plus importante que XMPP.
Après, XMPP, tu peux l'intégrer à travers une extension. Ça ne te convient pas?

Bon, a priori, tu restes persuadé qu'on doit faire à ta manière, et que sans XMPP, on fait une grosse erreur. Ouvre un bug, écrit ton API et écrit le code!

Juste dire "integre l'API XMPP", t'es malin, tu te rends compte du boulot?
Désolé, XMPP n'est pas assez prioritaire, il faut que tu le comprennes. Fais un patch ou va voire l'équipe Thunderbird avec un concept ou bosse avec l'équipe Weave ou envoie une description du projet aux Concept Series, mais arrête de nous dire ce qu'on doit faire.

"Vous feriez mieux de vous occuper des standards existants déjà. On ne peux toujours pas mettre de SVG en background-image ou dans un dans Firefox... Et oui."

Oui, mais ça c'est normal. C'est une question de choix, et pas un problème technique.
Le truc c'est: "SVG, est-ce un document ou une image?". On est pas encore certain que ce soit une bonne idée de mettre un "document" en background.

Mais a priori, on va tout de même le permettre (je ne sais pas pour quand).

Mais bon, tu ne comprends pas qu'on peut avancer en parallèle sur différentes technos.
On ne peut pas par example mettre l'équipe jetpack ou Fennec sur SVG.

Et *tes* priorités ne sont peut être pas celles de tout le monde.

On innove (oui, ça fait du buzz). On avance aussi sur les standards bien établis (on en parle moins probablement).

Mais bon, on ne peut satisfaire tout le monde.

... avec Firefox 3.7 (oui, je sais, c'est pas pour tout de suite), parce qu'on supportera les animations SVG.

+1 mais ne croyez pas que c'est parce qu'on se fiche de Linux (une partie des devs sont sous Linux, dont moi), au contraire, surtout que Linux c'est aussi le monde du mobile.

Je ne m'y connais pas assez, mais je sais que les devs galères à faire une version Linux rapide sous Linux, et ce n'est pas 100% de notre faute (Gcc, la couche graphique Linux, systeme de fichier, ...), mais un peu quand même :)

Je sais que XMPP c'est ton jouet à toi.
On n'a pas le temps de tout faire non plus :)

Mais clairement, je trouve aussi que ça a un sens d'intégrer XMPP, mais il y a des priorités (animations, identité, performances, sécurité, mechanisme d'extensions plus simples, ...).

Il faut aussi définir comment XMPP intervient dans un browser et/ou dans le web (sens "page webs").

Oui, tu as raison... on va laisser de côté l'implémentation de nouveaux standards et de nouvelles fonctionnalités, bêtes que nous sommes :(

C'est plus complexe que ça.

L'idée est d'avoir un moteur de traitement et d'aggrégations de messages qui pourra être requeté à travers une UI XUL (Thunderbird 4) ou via une page web.

Le moteur pourra se trouver coté web, mais rester aussi sur le desktop.

Parce que la nouvelle UI de 4.0 est un gros boulversement, on a besoin de temps pour tout mettre en place.

Pour le startup, je ne sais pas.

Et non :(

Faire fonctionner WebGL avec une carte ATI ou Intel, c'est la misère.
Mais on utilise OpenGL, mais avec les différentes versions et les extensions, galères...

C'est pour ça que je précise:
"Tous ces projets sont en cours de développement, releasés ou pas, mais très actifs."

:)

Oui, c'est lourdingue.

On y pense très très fort :) ... mais il se trouve que le code pour la rédaction d'un message est particulièrement compliqué (et ça c'est pas normal) et que c'est pas évident à coller dans un onglet, mais on y travaille.

Oui, c'est dans 3.6 (multiple file input).

Suivez http://hacks.mozilla.org , on en parle cette semaine.

tar -xf
marche pour tout.

s/plop/`date`

Normal, ils utilisent Mpeg4. Nous, on supporte Ogg/Theora (et plus tard, Dirac).

C'est vrai qu'on reproche souvent à Firefox d'être lent.
J'aimerai en savoir plus.

* Le temps de lancement de Firefox (La premier lancement, les suivants);
* Le chargement d'une page web (gnu.org, gmail.com);
* La réactivité (de l'interface graphique, d'une page web);
* Avec et sans Flash (Flashblock aide bien);
* Avec ou sans extensions;
* L'OS (Plus rapide sur Windows que sous Linux);
* ext4 ?
* Consomation mémoire (au chargement, ou après 4 heures)
.. etc.

Plus on a d'info, plus on peut isoler d'où viennent ces problèmes.
On a déjà beaucoup de données, mais il ne faut pas hésiter à nous donner un max de détails :)

Un truc que j'ai codé pour montrer video + canvas + workers

http://blog.mozbox.org/post/2009/02/20/Video-Canvas-Worker-t(...)

... et un paquet de démos:

https://developer.mozilla.org/En/OpenWebDemos

Marche que avec FF3.1

C'est un sujet vaste et compliqué.

Mais:
1. Les ressources humaines;
2. Promouvoir l'openweb et les standards, c'est la mission originale de Mozilla (cf. le manifesto), donc priorité à la plateforme web;
3. HTML 5 et l'openweb ont plus de chance de concurrencer les technos Adobe & Microsoft;

Mon avis perso:
* Silverlight & Flash, c'est mauvais. Définitvement, la bonne techno pour les concurrencer, c'est le web.
* Air, c'est une supère techno (pas libre, je sais). Ici, 2 solutions chez Mozilla: "XulRunner" ou "Prism + HTML 5". Peut-être qu'ici Mozilla devrait en faire plus.
Je rappelle quand même qu'avec la plateforme Web, on peut désormais faire des trucs vraiment sympa (offline, video, canvas, ...).

Vous en pensez quoi ?

- "Effacer l'URL et mettre le focus dessus" très pratique pour les collers par clic-milieu

Pas si utile que ça:
Copier une URL ( == sélectionner), ensuite, clique du milieu simplement sur une page web, et ça charge l'url.

Non, c'est clairement séparable. Ensuite, il y a une glue entre le langage et le layout/document engine. Chez nous, c'est XpConnect.

Les -moz, c'est pour CSS, juste pour dire que c'est pas standard.

openkomodo == komodoedit

Oui, le soucis vient de DOM qui est encore relativement lent dans Chrome.

Pour cette histoire de multi processus, c'est pour le moment impossible dans Mozilla, et pas envisagé.

Le soucis avec le multi process, c'est les plugins window less (dur dur à faire), comment rendre les fenetres des différents process sous Mac (a priori, pas de solution évidente), soucis de perf si un JS communique avec une autre fenetre et la gestion des iframes (cf. http://weblogs.mozillazine.org/roc/archives/2008/09/chrome.h(...)

Non, pas que des promesses: http://jonoscript.wordpress.com/2008/08/27/plumbing-and-the-(...)

Va faire ça avec ton %s ;)

En fait, un port de Firefox basé sur QT arrive doucement:

http://browser.garage.maemo.org/news/10/
(site down à l'heure où j'écrit ces lignes)

On peut même télécharger une version.
C'est très "early" (bug dans le thème, gestionnaire de fichier, ...), mais ça arrive:

https://bugzilla.mozilla.org/show_bug.cgi?id=448989

Voilà à quoi ça ressemble:
http://www.mozbox.org/pub/ffqt.png

Ça mérite peut etre un journal ça...