J'ai vu le salaire de Mitchell Baker (je ne me souviens plus du montant exact). D'après mes souvenirs, il n'avait rien de mirobolant, en tout cas pour quelqu'un qui dirige une société comme Mozilla Corp. En prenant en compte le fait que les salaires là bas sont en général plus élevé qu'en France, à cause du coût de la vie plus élevé, de l'immobilier beaucoup plus cher, et de l'absence de sécurité sociale etc.
Maintenant, si on parle d'enrichissement personnel quand on parle de salaire...
>soit certain que le jour où Mozilla voudra sortir quelque chose qui ne sera pas du gout de Google, la menace de la suppression des aides sortira (bon, peut être sous la forme d'un coup de file...) et vu le paquet de pognon en jeu, La fondation Mozilla y réfléchira à deux fois...
Comme je l'ai dit en dessous, ce n'est pas du mécénat comme le dit le journal, mais un contrat purement commercial avec Mozilla Corp. Si menace il y a, ça veut dire menace de rupture de contrat. Rupture de contrat égale bien souvent indemnité. De plus, si rupture de contrat, ça veut dire plus de google par défaut dans Firefox. Google y perdra aussi alors (car Firefox concerne quand même maintenant plus de 30% des internautes...). Bref, c'est donnant donnant.
Et puis si demain Google rompt le contrat ou ne le renouvelle pas dans 3-4 ans (je n'ai plus la date en tête), ça ne sera pas trop grave à mon avis. Il y a je pense assez de sous de coté pour continuer quelques mois au même rythme le temps de retrouver une autre source de revenus (ce serait les autres moteurs de recherches qui vont être content). Ils organiseront juste moins de meetings Mozilla, et inviteront moins les contributeurs à ces meetings :-) (l'année derniere, Mozilla Summit = plus de 400 contributeurs venu de par le monde, à Whisler au Canada pendant presque une semaine, tout frais payé), moins de marketing etc...
Et puis au pire, c'est pas la première fois que le projet Mozilla aura à "survivre" et être sous restriction. Le projet est passé par des étapes bien plus difficile que ça le serait si le contrat avec Google cessait. Ils ont la peau dure (de gros lezard) chez Mozilla ;-)
>Elle a eu la chance de tomber sur un "mécène" en la personne de Google mais a réussit à garder son indépendance.
Attention, la relation entre Google et Mozilla n'a absolument rien de mécénat.
Il s'agit d'un véritable contrat commercial entre Mozilla Corporation (et non Mozilla Fondation) et Google. Le deal en gros c'est "je te met en premier de la liste des moteurs de recherche et en page d'accueil par défaut, et tu me file des sous à chaque fois qu'un internaute fait une recherche sur ton moteur en utilisant mon navigateur".
C'est pas Google qui file des sous comme ça sans contrepartie, pour faire du mécénat. C'est vraiment commercial.
Ce qui distingue par contre Mozilla Corporation d'une autre société classique commerciale, c'est qu'elle appartient à 100% à la Mozilla Fondation. Pas d'actionnaire. Pas d'enrichissement personnel. Tout pour faire fonctionner le projet : payer les couts des infrastructures, administratifs &co, payer les développeurs, aider les contributeurs, mettre des sous de coté pour garantir l'avenir du projet, satisfaire les utilisateurs, promouvoir l'innovation et la diversité sur le web etc. Et tout ça est contrôlé par la fondation.
Comme pour Gimp, plein de personne disent : Mais Photoshop le fait comme ça, pourquoi pas Gimp. Réponse d'un développeur : Je n'ai jamais utilisé Photoshop, expliquez moi un peu plus précisement de quoi il retourne.
C'est simple, Photoshop, juste ça marche.
ça fait 8-9 ans que je suis sous linux à plein temps, peut-être 6 que je me démerde comme je peux avec gimp pour faire des retouches ou des créations d'images principalement pour le design de site web persos. Je n'ai jamais utilisé photoshop avant un essai il y a 3-4 ans.
L'interface de Gimp est à chier. point. Pour faire des opérations simples, il faut 15 manipulation dans tout les sens. C'est contre productif. Il y a 3-4 ans donc, lors d'une séance de Gimp, j'ai crisé (comme souvent avec Gimp) et j'en ai eu ras le bol. J'ai choppé un vieux Photoshop[1] et je l'ai installé sur un windows qui traînait dans un coin histoire de voir comme était Photoshop, et voir si j'allais réussir à faire ce que je voulais.
En 5 minutes, sans avoir googlé sur 15 sites web pour comprendre comment on l'utilisait, j'avais réussi à retoucher mon image comme je voulais, là où j'avais passé 30 minutes péniblement sur Gimp sans grand résultat (que je connaissais pourtant). Et mieux, je pouvais changer les paramètres de mes effets après coup, après plusieurs manipulations, chose impossible avec Gimp, sauf à noter toutes les manips que tu fais, avec les valeurs des effets, et à faire des dizaines d'undo pour retrouver l'application de l'effet, l'annuler et réappliquer tout les autres manips/effets.
Bref. Gimp, c'est juste pas possible. Ou peut-être que ça rentre pas dans ma logique de pensée. Mais pourtant la majorité des gens que je connais et qui ont essayé Gimp, n'ont jamais été convaincu par Gimp non plus. Photoshop est beaucoup plus intuitif à utiliser, plus simple (seul reproche que j'entend sur Photoshop: il est très gourmand en ressource).
Sous mac, c'est encore pire. L'intégration dans MacOS de Gimp est une horreur, surtout avec ses multitudes de fenêtres. Comme on est toujours à cliquer constamment sur des fenêtres différentes, et que sous Mac pour interagir avec la fenêtre il faut d'abord cliquer sur elle (j'ai pas trouvé le moyen de désactiver ce comportement :-( ), on est donc à double cliquer dans tout les sens. Je ne sais pas si c'est un problème Mac qui ne permettrait pas de faire des fenêtres "fille" dépendantes d'une fenêtre principal, ou si c'est un problème Gimp/Gtk qui n'utiliserait pas le bon mécanisme de fenêtre, mais en tout cas, Gimp est inutilisable.
Pour moi, quand un logiciel est bien conçu ergonomiquement, il n'y a pas besoin de lire une seule page de manuel pour l'utiliser.
1) oui, c'était un piraté, mais c'était juste pour un essai et je ne l'ai pas utilisé par la suite parce que ça m'embêtait de devoir bosser sous Windows, et puis parce que je préfère le libre tout simplement.. Et puis j'arrive quand même à me débrouiller avec Gimp pour ce que je fais, même si c'est en maudissant son manque d'ergonomie.
dans ce cas, moi je te dirais : je ne vois pas une seule raison de rester sous svn par rapport à Mercurial, puisque Mercurial est quasi aussi simple à utiliser que svn (les commandes se ressemblent pas mal avec svn), et fonctionne très bien sous windows.
ou à la limite, sans propose un tarif minimal, juste dire "ça coute tant par membres", et ensuite à chacun de donner en fonction de ses moyens, de ce qu'il juge etc..
Mais c'est vrai que d'avoir au moins une idée du cout, c'est je pense indispensable.
conçernant drizzle, c'est plutôt facile de forker quand on enlève plein de features.
Le truc qui m'a fait sursauter :http://drizzle.org/wiki/MySQL_Differences . Ils ont enlever les vues, les procédures stockées, les triggers, les requêtes préparées, et d'autres trucs. Bref, ils reviennent à mysql 3.
Bon, ok, c'est pour un usage plutôt spécifique (cloud computing et cie) mais bon...
oui c'est trivial. Mais il n'y a rien de spécifié dans les standards "pour faire un menu dynamique". Et vu qu'il y a mille manière de faire un menu dynamique, je vois pas pourquoi tu parles d'implémentation correcte de menu dynamique. Mais bon je pense avoir compris de travers ton premier commentaire.
>Rien n'empêche d'implémenter un draft, surtout que cela existe depuis très très longtemps 2002
C'est justement ce qui est fait dans Mozilla et Webkit. Cependant, comme c'est pas finalisé, ils ont mis leur prefixe -moz- et -webkit- (comme c'est autorisé dans la spec css), parce qu'effectivement, la spec peut changer d'ici l'etape "recommandation", et donc leur implementation ne plus correspondre avec la spec définitive (qui ne l'est toujours pas, definitive).
Maintenant, rien ne t'empêche à mettre les styles -moz-border-radius, -webkit-border-radius et même border-radius, en même temps dans ta feuille de style (comme ça, ton site sera pret ;-). Pour les autres navigateurs ne reconnaissant pas ces styles, bah tant pis, coin carré, et c'est pas un drame ;-)
>Faire un site portable est un enfer...
bah oui, et c'est pour ça que Mozilla et Webkit font la course à l'implementation des standards, car ça force les autres à suivre (en particulier IE). Et même si IE8 a encore du retard, beaucoup de progrés ont été fait, pour le bien des developeurs web.
>Je me suis contenté de t'expliquer ce que pouvait être un menu dynamique "standard". Et très humblement en plus car il y a peut-être d'autres méthodes.
Oui la méthode que tu as indiqué est celle que nous avons expliqué sur openweb.eu.org, (crée par moi et 10 autres gus dans un garage en 2003).
>dire "Firefox sait faire" ne fait pas (mais alors pas du tout) avancer le schmilblick.
Si, bien au contraire. Si IE8 (et puis avant IE7) respecte un peu mieux les standards, c'est grâce à quoi à ton avis ? Grâce au fait que Firefox respecte les standards (ou presque : disons que l'on s'efforce d'implémenter au maximum tout les standards, mais c'est un travail de longue haleine), et grâce au fait que les developpeurs gueulent après les mauvais navigateurs, qui ne fonctionnent pas comme attendu quand on utilise les standards. Ils gueulent, font pour certains le forcing à utiliser des navigateurs plus respectueux, d'où perte de marché pour les mauvais, ce qui forcent ceux-ci à réagir et à donc s'améliorer.
Et ça ne fait pas avancer le schmilblick seulement du coté des mauvais, mais aussi des "bons". Pour preuve cette deuxième guerre des navigateurs qui a démarré depuis le succés de Firefox.
Toutefois, c'est une guerre "saine", dans le sens où c'est plutôt une course à l'implémentation des standards.
Donc, oui, que "Firefox sait faire", ou même que "Webkit/Opera/Whatever sait faire", ça fait avancer le schmilblick.
Y a qu'à voir les avancées sur le support de CSS de Firefox 3.5 par rapport à 3.0 (et 3.0 par rapport à 2.5), forcées plus ou moins par les tests Acid, mais aussi par d'autres avancées dans Webkit comme les css transforms (spec qui est maintenant devenu un draft au W3C).
>Seul le respect des standards établis fera avancer le Web dans la bonne direction.
C'est justement ce qui se passe chez toutes les equipes de dev des navigateurs, IE compris.
Cependant, la spécification ne précise pas que le choix doit être persistant. Donc <mode mauvaise foi>Firefox respecte le standard de ce point de vu là</mode mauvaise foi> :-)
>Certes il n'y a pas de balise menudynamique mais il est possible d'en faire en HTML "standard"
Oui ok, mais je ne comprend pas : sous firefox, il n'y a pas besoin de faire du js pour ça, je vois donc pas où veut en venir Alenvers.
C'est certes emmerdant que dans certains navigateurs, on ne puisse toujours pas faire des choses simples et pourtant très utile, mais on ne va quand même pas arrêter d'implémenter des nouveaux trucs parce que d'autres sont à la traîne. Sinon personne n'avancerait ou n'innoverait.
Comment ça menu dynamique ? C'est quoi un menu "dynamique" pour toi ? Y a des choses en HTML "standard" ou "css" qui permettent de faire des menus dynamiques ?
>Coins arrondi
Mozilla a été le premier à implementer les coins arrondis. ça fait des années que je fais des coins arrondis en CSS. Mise à part ça, les coins arrondis ne sont pas un standard, vu que la specification est encore en brouillon...
>Feuilles de style alternatives
Firefox supporte très bien les css alternatives: menu affichage > style de la page
>Si j'ai bien compris, la personne qui maintient cette branche est un salarié de la MoFo
Plus que ça même. Pour ceux qui ont la flemme de lire son post, c'est un contributeur de longue date de valgrind.
Un premier port pour mac a été fait par un autre contributeur, employé Apple, il y a plus de 4 ans, mais ça avait été retombé plus ou moins dans l'oublie.
Nicholas a alors été embauché par Mozilla pour continuer à bosser dessus car de plus en plus de dev Mozilla sont sous Mac...
>Il m'a toujours semblé que Thunderbird était surtout un moyen pour la MoFo de prouver qu'on pouvait faire autre chose avec ses technologies (gecko, XUL ...)
pas du tout, c'est juste le descendant de la suite mozilla qui contenait browser, client mail, client irc et editeur html.
Firefox a ensuite été crée, n'ayant que la fonction navigateur. Et ne voulant plus continuer le developpement de la suite Mozilla, il a été logique de continuer à proposer une alternative de Mozilla Mail sous forme d'appli standalone : Thunderbird.
Le client irc, chatzilla, est toujours dispo sous forme d'extension pour firefox ou d'appli xulrunner.
> la cerise sur le gâteau : pouvoir définir un certains nombres de comportements ou d'options de thunderbird (voire même d'autres logiciels), avec juste une chaine de caractères simples et surtout en une seule ligne (par exemple les options "citer sous la réponse + mettre un texte alternatif aux images + autoriser un antivirus externe à scanner les messages etc" pourraient s'afficher dans une chaîne genre xDfpOKRT, automatiquement générée bien entendu,
Euh, copier le fichier prefs.js du profil (ou une partie de ce ficher, qui, je le rappelle, contient toutes les options du logiciel), ça ne serait pas plus simple ?
Je n'ai pas vérifié si c'etait une généralité, voir un "standard", mais j'ai remarqué que souvent, il suffisait d'enficher la prise avec le logo usb vers le haut, pour que ça rentre dans le bon sens....
Le développement de Gecko a débuté en 1998, mais la plupart des devs de Gecko avaient déjà une grosse expérience puisqu'ils venaient des équipes de Netscape 4 et précédent. Et puis le développement de Gecko (qui se faisait au sein de la societé Netscape), était fait par des devs à temps complets. Ce n'était pas le cas des devs de KHTML. le developpement de kHTML (tel qu'il est aujourd'hui) n'a réellement débuté qu'en 1999. À ceci il faut ajouter que Gecko, à la même époque, supportait non seulement HTML, mais aussi MATHML et surtout XUL/XBL, qui était une révolution à l'époque. Et puis certaines briques comme NSS (1) et NSPR (2) ont été reprises de feu Netscape 4.
Bref, Gecko a avancé plus vite que kHTML (sous la pression aussi de Netscape/AOL). Par contre il n'a pas forcément avancé vite de la meilleur façon. On se souvient de Nescape 6 sortie en 2006, qui n'était franchement pas exemplaire en terme de performance et de stabilité. De l'aveux même des développeurs, Gecko n'était franchement pas prêt.
Et puis, en plus de la non maturité du code, des choix techniques à l'époque du démarrage du projet sont responsables de certaines lourdeurs, qui ont depuis été corrigé, mais qui perdurent encore dans certaines parties du code.
Un exemple d'erreur : l'utilisation de XPCOM (3) à tout les niveaux. C'est un système génial pour l'extensibilité, pour pouvoir ajouter des composants binaires à un executable sans avoir à le recompiler, et pouvoir appeler ces composants dans un contexte javascript. XPCOM permet aussi une meilleur gestion automatique de la mémoire (en tout cas à l'époque). Mais utiliser XPCOM dans le coeur du moteur de rendu a été une erreur, car c'est un système lourd. C'est pourquoi depuis quelques années il y a un processus de "déCOMtamination" dans Gecko, et on commence seulement à en voir le bout du tunnel (c'est long parce que ça concerne des dizaines de milliers de lignes de code). Cette déCOMtamination a permis d'améliorer un peu les perfs dans les dernières versions de Firefox.
Bref, c'est ce genre de passif dont je parlais, entre autre chose.
>c'est que l'avantage qu'il pourrait exister à faire des applis en utilisant XulRunner n'est en réalité pas du tout un avantage mais un boulet?
Si tu veux faire de l'optimisation PGO, oui. Mais c'est le même problème pour toutes les libs des systèmes linux, il me semble.
> Un peu comme il faudrait une libc pour chaque applis?
Oui. C'est pourquoi il n'y a pas d'optimisation PGO sur la libc (enfin à ce qu'il me semble). Ni sur aucune autre lib linux. Ni sur tout ce qui est partagé quoi.
>Et que en conclusion il faudrait avoir un Xul pour chaque applis fondé dessus?
Si tu recherches les perfs, évidement. C'est tout le problème des profiles d'optimisations. C'est pourquoi PGO est peu utilisé en fin de compte.
De toute façon, en pratique, toutes les grosses applis XUL (songbird, Thunderbird, Miro etc) ont leur propre XulRunner, parce que patchés à leur sauce, parce que options de compils spécifiques etc...
>1. À quoi ça sert de proposer les binaires sur mozilla.org ?
Pouvoir utiliser les binaires vanilla (sans patchs dans tout les sens), tester, avoir les mises à jour pour les nightlies. Et pouvoir l'installer où on veut.
C'est surtout pour les tests et pour ceux qui ont des distribs qui ne reposent pas sur des systemes de paquages ou qui ne proposent pas de paquets firefox.
J'utilise ces binaires et ça me pose pas de problèmes.
>2. Il ne faut pas prétendre être le plus Linux-friendly
Sous gnome, je double click sur le tar.gz (tout comme sur un deb), ça me decompresse le truc, j'ai alors plus qu'à cliquer sur le binaire firefox. Bref, je ne trouve pas tant moins user friendly qu'un deb.
Et puis de toute façon, installe le paquet de ta distro (ce que tu n'as en général pas à faire puisque c'est souvent installé d'office), et tu auras une icone dans ton menu application. Pourquoi voudrais-tu donc un .deb ou .rpm ?
>3. Il faut reconnaître que Windows et Mac sont favorisés
Et je rajouterai ceci : fourni un .deb générique, c'est à coup sûr avoir des retour d'utilisateurs qui auront des problèmes à installer un paquet, pour des problemes de compatibilité avec leur distro, de conflit avec l'eventuel paquet firefox préinstallé etc... Je doute que faire un deb générique qui fonctionne sans problème sur les dizaines de distro existantes soit si trivial que ça... Au moins, un tar.gz, il y a plus de chance que ça fonctionne.
La raison de la non activation de PGO pour les builds linux semble être le manque de temps pour configurer les machines de build automatiques, et faire du PGO avec GCC est apparement un peu plus acrobatique et prend plus de ressources que faire du PGO avec visual C++. Il y a peut etre aussi une histoire de version de GCC par défaut... Enfin bon, pas clair tout ça. Il y a en tout cas un bug pour ceux qui veulent être au courant de quand ça sera fait officiellement. https://bugzilla.mozilla.org/show_bug.cgi?id=418866.
Mais ça ne concerne que les builds vanilla. Pour les builds dans vos distros, plaignez vous aux mainteneurs des paquets qui n'ont pas activé les options adéquates. exemple chez Ubuntu : https://bugs.launchpad.net/xulrunner/+bug/213708
Un des problèmes dans les distro, c'est qu'ils veulent fournir un paquet xulrunner qui soit utilisé par Firefox (Firefox est en fait une appli XulRunner).
Or, si on optimise XulRunner pour Firefox, il se peut que ce ne soit pas du tout optimisé pour d'autres applications utilisant XulRunner. Rappel: l'optimisation PGO consiste à optimiser les parties de codes d'un binaire qui sont les plus sollicités (selon un profile d'execution donc, d'où l'acronyme PGO). Bref, en optimisant le binaire XulRunner pour executer Firefox, ça va optimiser par exemple les parties du moteur de rendu les plus sollicités pour afficher une page web (et probablement au détriment d'autres parties). Hors, ces optimisations peuvent être totalement inutiles (et peut être même avec l'effet inverse) pour une application XulRunner qui n'affiche pas de page web.
Problème donc pour les mainteneurs des paquets Firefox : soit ils livrent d'un coté un Firefox complet optimisé en PGO, et de l'autre un paquet XulRunner non optimisé indépendant du paquet Firefox, soit ils livrent un paquet XulRunner dépendant de Firefox et utilisable par toutes les applis xulrunner, mais alors sans optimisation PGO.
Doit y avoir d'autres raisons, mais j'ai pas plus investigué.
[^] # Re: Remarque de taille
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Faire du libre ... vendre du libre (Mon point de vue de yacafocon).. Évalué à 3.
Pourtant, ce que je dis est plutôt proche de la vérité. Y a qu'à éplucher mozilla.com, les comptes rendus financiers etc.. (ex: http://www.mozilla.org/foundation/documents/ )
J'ai vu le salaire de Mitchell Baker (je ne me souviens plus du montant exact). D'après mes souvenirs, il n'avait rien de mirobolant, en tout cas pour quelqu'un qui dirige une société comme Mozilla Corp. En prenant en compte le fait que les salaires là bas sont en général plus élevé qu'en France, à cause du coût de la vie plus élevé, de l'immobilier beaucoup plus cher, et de l'absence de sécurité sociale etc.
Maintenant, si on parle d'enrichissement personnel quand on parle de salaire...
[^] # Re: Le savoir est une arme...comerciale
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Faire du libre ... vendre du libre (Mon point de vue de yacafocon).. Évalué à 4.
Comme je l'ai dit en dessous, ce n'est pas du mécénat comme le dit le journal, mais un contrat purement commercial avec Mozilla Corp. Si menace il y a, ça veut dire menace de rupture de contrat. Rupture de contrat égale bien souvent indemnité. De plus, si rupture de contrat, ça veut dire plus de google par défaut dans Firefox. Google y perdra aussi alors (car Firefox concerne quand même maintenant plus de 30% des internautes...). Bref, c'est donnant donnant.
Et puis si demain Google rompt le contrat ou ne le renouvelle pas dans 3-4 ans (je n'ai plus la date en tête), ça ne sera pas trop grave à mon avis. Il y a je pense assez de sous de coté pour continuer quelques mois au même rythme le temps de retrouver une autre source de revenus (ce serait les autres moteurs de recherches qui vont être content). Ils organiseront juste moins de meetings Mozilla, et inviteront moins les contributeurs à ces meetings :-) (l'année derniere, Mozilla Summit = plus de 400 contributeurs venu de par le monde, à Whisler au Canada pendant presque une semaine, tout frais payé), moins de marketing etc...
Et puis au pire, c'est pas la première fois que le projet Mozilla aura à "survivre" et être sous restriction. Le projet est passé par des étapes bien plus difficile que ça le serait si le contrat avec Google cessait. Ils ont la peau dure (de gros lezard) chez Mozilla ;-)
# Remarque de taille
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Faire du libre ... vendre du libre (Mon point de vue de yacafocon).. Évalué à 6.
Attention, la relation entre Google et Mozilla n'a absolument rien de mécénat.
Il s'agit d'un véritable contrat commercial entre Mozilla Corporation (et non Mozilla Fondation) et Google. Le deal en gros c'est "je te met en premier de la liste des moteurs de recherche et en page d'accueil par défaut, et tu me file des sous à chaque fois qu'un internaute fait une recherche sur ton moteur en utilisant mon navigateur".
C'est pas Google qui file des sous comme ça sans contrepartie, pour faire du mécénat. C'est vraiment commercial.
Ce qui distingue par contre Mozilla Corporation d'une autre société classique commerciale, c'est qu'elle appartient à 100% à la Mozilla Fondation. Pas d'actionnaire. Pas d'enrichissement personnel. Tout pour faire fonctionner le projet : payer les couts des infrastructures, administratifs &co, payer les développeurs, aider les contributeurs, mettre des sous de coté pour garantir l'avenir du projet, satisfaire les utilisateurs, promouvoir l'innovation et la diversité sur le web etc. Et tout ça est contrôlé par la fondation.
# Gimp vs photoshop
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal IHM et le libre. Évalué à 9.
C'est simple, Photoshop, juste ça marche.
ça fait 8-9 ans que je suis sous linux à plein temps, peut-être 6 que je me démerde comme je peux avec gimp pour faire des retouches ou des créations d'images principalement pour le design de site web persos. Je n'ai jamais utilisé photoshop avant un essai il y a 3-4 ans.
L'interface de Gimp est à chier. point. Pour faire des opérations simples, il faut 15 manipulation dans tout les sens. C'est contre productif. Il y a 3-4 ans donc, lors d'une séance de Gimp, j'ai crisé (comme souvent avec Gimp) et j'en ai eu ras le bol. J'ai choppé un vieux Photoshop[1] et je l'ai installé sur un windows qui traînait dans un coin histoire de voir comme était Photoshop, et voir si j'allais réussir à faire ce que je voulais.
En 5 minutes, sans avoir googlé sur 15 sites web pour comprendre comment on l'utilisait, j'avais réussi à retoucher mon image comme je voulais, là où j'avais passé 30 minutes péniblement sur Gimp sans grand résultat (que je connaissais pourtant). Et mieux, je pouvais changer les paramètres de mes effets après coup, après plusieurs manipulations, chose impossible avec Gimp, sauf à noter toutes les manips que tu fais, avec les valeurs des effets, et à faire des dizaines d'undo pour retrouver l'application de l'effet, l'annuler et réappliquer tout les autres manips/effets.
Bref. Gimp, c'est juste pas possible. Ou peut-être que ça rentre pas dans ma logique de pensée. Mais pourtant la majorité des gens que je connais et qui ont essayé Gimp, n'ont jamais été convaincu par Gimp non plus. Photoshop est beaucoup plus intuitif à utiliser, plus simple (seul reproche que j'entend sur Photoshop: il est très gourmand en ressource).
Sous mac, c'est encore pire. L'intégration dans MacOS de Gimp est une horreur, surtout avec ses multitudes de fenêtres. Comme on est toujours à cliquer constamment sur des fenêtres différentes, et que sous Mac pour interagir avec la fenêtre il faut d'abord cliquer sur elle (j'ai pas trouvé le moyen de désactiver ce comportement :-( ), on est donc à double cliquer dans tout les sens. Je ne sais pas si c'est un problème Mac qui ne permettrait pas de faire des fenêtres "fille" dépendantes d'une fenêtre principal, ou si c'est un problème Gimp/Gtk qui n'utiliserait pas le bon mécanisme de fenêtre, mais en tout cas, Gimp est inutilisable.
Pour moi, quand un logiciel est bien conçu ergonomiquement, il n'y a pas besoin de lire une seule page de manuel pour l'utiliser.
1) oui, c'était un piraté, mais c'était juste pour un essai et je ne l'ai pas utilisé par la suite parce que ça m'embêtait de devoir bosser sous Windows, et puis parce que je préfère le libre tout simplement.. Et puis j'arrive quand même à me débrouiller avec Gimp pour ce que je fais, même si c'est en maudissant son manque d'ergonomie.
[^] # Re: Bon bon bon...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Support Mercurial sur google code. Évalué à 5.
[^] # Re: Bon bon bon...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Support Mercurial sur google code. Évalué à 2.
[^] # Re: je DETESTE les prix libres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Nouvelles de toile libre, l'hébergeur à prix libre .. Évalué à 7.
Mais c'est vrai que d'avoir au moins une idée du cout, c'est je pense indispensable.
[^] # Re: Attention chérie ca va forker
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Oracle rachète Sun. Évalué à 3.
Le truc qui m'a fait sursauter :http://drizzle.org/wiki/MySQL_Differences . Ils ont enlever les vues, les procédures stockées, les triggers, les requêtes préparées, et d'autres trucs. Bref, ils reviennent à mysql 3.
Bon, ok, c'est pour un usage plutôt spécifique (cloud computing et cie) mais bon...
[^] # Re: Je serais déjà content avec beaucoup moins
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les possibilités des nouvelles techno web. Évalué à 3.
oui c'est trivial. Mais il n'y a rien de spécifié dans les standards "pour faire un menu dynamique". Et vu qu'il y a mille manière de faire un menu dynamique, je vois pas pourquoi tu parles d'implémentation correcte de menu dynamique. Mais bon je pense avoir compris de travers ton premier commentaire.
>Rien n'empêche d'implémenter un draft, surtout que cela existe depuis très très longtemps 2002
C'est justement ce qui est fait dans Mozilla et Webkit. Cependant, comme c'est pas finalisé, ils ont mis leur prefixe -moz- et -webkit- (comme c'est autorisé dans la spec css), parce qu'effectivement, la spec peut changer d'ici l'etape "recommandation", et donc leur implementation ne plus correspondre avec la spec définitive (qui ne l'est toujours pas, definitive).
Maintenant, rien ne t'empêche à mettre les styles -moz-border-radius, -webkit-border-radius et même border-radius, en même temps dans ta feuille de style (comme ça, ton site sera pret ;-). Pour les autres navigateurs ne reconnaissant pas ces styles, bah tant pis, coin carré, et c'est pas un drame ;-)
>Faire un site portable est un enfer...
bah oui, et c'est pour ça que Mozilla et Webkit font la course à l'implementation des standards, car ça force les autres à suivre (en particulier IE). Et même si IE8 a encore du retard, beaucoup de progrés ont été fait, pour le bien des developeurs web.
[^] # Re: Je serais déjà content avec beaucoup moins
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les possibilités des nouvelles techno web. Évalué à 4.
en effet, contributeur depuis 2003.
>Je me suis contenté de t'expliquer ce que pouvait être un menu dynamique "standard". Et très humblement en plus car il y a peut-être d'autres méthodes.
Oui la méthode que tu as indiqué est celle que nous avons expliqué sur openweb.eu.org, (crée par moi et 10 autres gus dans un garage en 2003).
>dire "Firefox sait faire" ne fait pas (mais alors pas du tout) avancer le schmilblick.
Si, bien au contraire. Si IE8 (et puis avant IE7) respecte un peu mieux les standards, c'est grâce à quoi à ton avis ? Grâce au fait que Firefox respecte les standards (ou presque : disons que l'on s'efforce d'implémenter au maximum tout les standards, mais c'est un travail de longue haleine), et grâce au fait que les developpeurs gueulent après les mauvais navigateurs, qui ne fonctionnent pas comme attendu quand on utilise les standards. Ils gueulent, font pour certains le forcing à utiliser des navigateurs plus respectueux, d'où perte de marché pour les mauvais, ce qui forcent ceux-ci à réagir et à donc s'améliorer.
Et ça ne fait pas avancer le schmilblick seulement du coté des mauvais, mais aussi des "bons". Pour preuve cette deuxième guerre des navigateurs qui a démarré depuis le succés de Firefox.
Toutefois, c'est une guerre "saine", dans le sens où c'est plutôt une course à l'implémentation des standards.
Donc, oui, que "Firefox sait faire", ou même que "Webkit/Opera/Whatever sait faire", ça fait avancer le schmilblick.
Y a qu'à voir les avancées sur le support de CSS de Firefox 3.5 par rapport à 3.0 (et 3.0 par rapport à 2.5), forcées plus ou moins par les tests Acid, mais aussi par d'autres avancées dans Webkit comme les css transforms (spec qui est maintenant devenu un draft au W3C).
>Seul le respect des standards établis fera avancer le Web dans la bonne direction.
C'est justement ce qui se passe chez toutes les equipes de dev des navigateurs, IE compris.
[^] # Re: Je serais déjà content avec beaucoup moins
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les possibilités des nouvelles techno web. Évalué à 2.
Cependant, la spécification ne précise pas que le choix doit être persistant. Donc <mode mauvaise foi>Firefox respecte le standard de ce point de vu là</mode mauvaise foi> :-)
http://www.w3.org/TR/html401/present/styles.html#h-14.3
[^] # Re: Je serais déjà content avec beaucoup moins
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les possibilités des nouvelles techno web. Évalué à 3.
Oui ok, mais je ne comprend pas : sous firefox, il n'y a pas besoin de faire du js pour ça, je vois donc pas où veut en venir Alenvers.
C'est certes emmerdant que dans certains navigateurs, on ne puisse toujours pas faire des choses simples et pourtant très utile, mais on ne va quand même pas arrêter d'implémenter des nouveaux trucs parce que d'autres sont à la traîne. Sinon personne n'avancerait ou n'innoverait.
[^] # Re: Je serais déjà content avec beaucoup moins
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les possibilités des nouvelles techno web. Évalué à 2.
Comment ça menu dynamique ? C'est quoi un menu "dynamique" pour toi ? Y a des choses en HTML "standard" ou "css" qui permettent de faire des menus dynamiques ?
>Coins arrondi
Mozilla a été le premier à implementer les coins arrondis. ça fait des années que je fais des coins arrondis en CSS. Mise à part ça, les coins arrondis ne sont pas un standard, vu que la specification est encore en brouillon...
>Feuilles de style alternatives
Firefox supporte très bien les css alternatives: menu affichage > style de la page
# salarié et contributeur
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal valgrind sous darwin. Évalué à 7.
Plus que ça même. Pour ceux qui ont la flemme de lire son post, c'est un contributeur de longue date de valgrind.
Un premier port pour mac a été fait par un autre contributeur, employé Apple, il y a plus de 4 ans, mais ça avait été retombé plus ou moins dans l'oublie.
Nicholas a alors été embauché par Mozilla pour continuer à bosser dessus car de plus en plus de dev Mozilla sont sous Mac...
[^] # Re: Thunderbird pour qui ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Comment peut-on sauver Thunderbird alors que le courrier électronique se meurt ?. Évalué à 3.
pas du tout, c'est juste le descendant de la suite mozilla qui contenait browser, client mail, client irc et editeur html.
Firefox a ensuite été crée, n'ayant que la fonction navigateur. Et ne voulant plus continuer le developpement de la suite Mozilla, il a été logique de continuer à proposer une alternative de Mozilla Mail sous forme d'appli standalone : Thunderbird.
Le client irc, chatzilla, est toujours dispo sous forme d'extension pour firefox ou d'appli xulrunner.
[^] # Re: mort le mail??
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Comment peut-on sauver Thunderbird alors que le courrier électronique se meurt ?. Évalué à 2.
Euh, copier le fichier prefs.js du profil (ou une partie de ce ficher, qui, je le rappelle, contient toutes les options du logiciel), ça ne serait pas plus simple ?
# Logo
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal pas de détrompeur USB.... Évalué à 2.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 9.
Bref, Gecko a avancé plus vite que kHTML (sous la pression aussi de Netscape/AOL). Par contre il n'a pas forcément avancé vite de la meilleur façon. On se souvient de Nescape 6 sortie en 2006, qui n'était franchement pas exemplaire en terme de performance et de stabilité. De l'aveux même des développeurs, Gecko n'était franchement pas prêt.
Et puis, en plus de la non maturité du code, des choix techniques à l'époque du démarrage du projet sont responsables de certaines lourdeurs, qui ont depuis été corrigé, mais qui perdurent encore dans certaines parties du code.
Un exemple d'erreur : l'utilisation de XPCOM (3) à tout les niveaux. C'est un système génial pour l'extensibilité, pour pouvoir ajouter des composants binaires à un executable sans avoir à le recompiler, et pouvoir appeler ces composants dans un contexte javascript. XPCOM permet aussi une meilleur gestion automatique de la mémoire (en tout cas à l'époque). Mais utiliser XPCOM dans le coeur du moteur de rendu a été une erreur, car c'est un système lourd. C'est pourquoi depuis quelques années il y a un processus de "déCOMtamination" dans Gecko, et on commence seulement à en voir le bout du tunnel (c'est long parce que ça concerne des dizaines de milliers de lignes de code). Cette déCOMtamination a permis d'améliorer un peu les perfs dans les dernières versions de Firefox.
Bref, c'est ce genre de passif dont je parlais, entre autre chose.
(1) http://en.wikipedia.org/wiki/Network_Security_Services
(2) http://en.wikipedia.org/wiki/Netscape_Portable_Runtime
(3) http://en.wikipedia.org/wiki/XPCOM
[^] # Re: La réponse est dans la question
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 2.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 2.
j'ai déjà expliqué plus haut
>vu que chaque appli de la MoFo a son XULRunner ?
les applis que j'ai cité, excepté Thunderbird, ne sont pas des applis de la MoFo.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 3.
Si tu veux faire de l'optimisation PGO, oui. Mais c'est le même problème pour toutes les libs des systèmes linux, il me semble.
> Un peu comme il faudrait une libc pour chaque applis?
Oui. C'est pourquoi il n'y a pas d'optimisation PGO sur la libc (enfin à ce qu'il me semble). Ni sur aucune autre lib linux. Ni sur tout ce qui est partagé quoi.
>Et que en conclusion il faudrait avoir un Xul pour chaque applis fondé dessus?
Si tu recherches les perfs, évidement. C'est tout le problème des profiles d'optimisations. C'est pourquoi PGO est peu utilisé en fin de compte.
De toute façon, en pratique, toutes les grosses applis XUL (songbird, Thunderbird, Miro etc) ont leur propre XulRunner, parce que patchés à leur sauce, parce que options de compils spécifiques etc...
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 10.
Pouvoir utiliser les binaires vanilla (sans patchs dans tout les sens), tester, avoir les mises à jour pour les nightlies. Et pouvoir l'installer où on veut.
C'est surtout pour les tests et pour ceux qui ont des distribs qui ne reposent pas sur des systemes de paquages ou qui ne proposent pas de paquets firefox.
J'utilise ces binaires et ça me pose pas de problèmes.
>2. Il ne faut pas prétendre être le plus Linux-friendly
Sous gnome, je double click sur le tar.gz (tout comme sur un deb), ça me decompresse le truc, j'ai alors plus qu'à cliquer sur le binaire firefox. Bref, je ne trouve pas tant moins user friendly qu'un deb.
Et puis de toute façon, installe le paquet de ta distro (ce que tu n'as en général pas à faire puisque c'est souvent installé d'office), et tu auras une icone dans ton menu application. Pourquoi voudrais-tu donc un .deb ou .rpm ?
>3. Il faut reconnaître que Windows et Mac sont favorisés
pas du tout. Il y a des raisons pertinentes à ne pas fournir des paquets:
https://bugzilla.mozilla.org/show_bug.cgi?id=419473#c1
Et je rajouterai ceci : fourni un .deb générique, c'est à coup sûr avoir des retour d'utilisateurs qui auront des problèmes à installer un paquet, pour des problemes de compatibilité avec leur distro, de conflit avec l'eventuel paquet firefox préinstallé etc... Je doute que faire un deb générique qui fonctionne sans problème sur les dizaines de distro existantes soit si trivial que ça... Au moins, un tar.gz, il y a plus de chance que ça fonctionne.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 3.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 2.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 8.
Pour les différences entre win et linux, cf commentaire plus haut. Il y a en effet des optimisations PGO faites lors du build sous windows : https://developer.mozilla.org/En/Building_with_Profile-Guide(...)
La raison de la non activation de PGO pour les builds linux semble être le manque de temps pour configurer les machines de build automatiques, et faire du PGO avec GCC est apparement un peu plus acrobatique et prend plus de ressources que faire du PGO avec visual C++. Il y a peut etre aussi une histoire de version de GCC par défaut... Enfin bon, pas clair tout ça. Il y a en tout cas un bug pour ceux qui veulent être au courant de quand ça sera fait officiellement. https://bugzilla.mozilla.org/show_bug.cgi?id=418866.
Mais ça ne concerne que les builds vanilla. Pour les builds dans vos distros, plaignez vous aux mainteneurs des paquets qui n'ont pas activé les options adéquates. exemple chez Ubuntu : https://bugs.launchpad.net/xulrunner/+bug/213708
Un des problèmes dans les distro, c'est qu'ils veulent fournir un paquet xulrunner qui soit utilisé par Firefox (Firefox est en fait une appli XulRunner).
Or, si on optimise XulRunner pour Firefox, il se peut que ce ne soit pas du tout optimisé pour d'autres applications utilisant XulRunner. Rappel: l'optimisation PGO consiste à optimiser les parties de codes d'un binaire qui sont les plus sollicités (selon un profile d'execution donc, d'où l'acronyme PGO). Bref, en optimisant le binaire XulRunner pour executer Firefox, ça va optimiser par exemple les parties du moteur de rendu les plus sollicités pour afficher une page web (et probablement au détriment d'autres parties). Hors, ces optimisations peuvent être totalement inutiles (et peut être même avec l'effet inverse) pour une application XulRunner qui n'affiche pas de page web.
Problème donc pour les mainteneurs des paquets Firefox : soit ils livrent d'un coté un Firefox complet optimisé en PGO, et de l'autre un paquet XulRunner non optimisé indépendant du paquet Firefox, soit ils livrent un paquet XulRunner dépendant de Firefox et utilisable par toutes les applis xulrunner, mais alors sans optimisation PGO.
Doit y avoir d'autres raisons, mais j'ai pas plus investigué.