Y a une API pour ça en préparation au W3C : http://www.w3.org/2009/dap/ (je ne sais pas si les navigateurs ont commencé à les implémenter, mais je pense que non, c'est assez jeune)
En fait, y a une API pour presque tout dans Firefox, et probablement dans webkit ou autre.
Et tout ça c'est dans HTML5 ou dans d'autres specs du W3C, la plupart en brouillon mais qui commencent à être implémentés dans les navigateurs.
Donc oui, on peut maintenant faire des applications web aussi puissantes que beaucoup d'applis desktop.
Et je ne parle pas de la 3D qui, elle aussi, est en train de débarquer dans la balise canvas HTML5 dans nos navigateurs, ni des animations vectoriels (SVG+SMIL)...
Alors certes, rien n'empêche à Apple de désactiver ces features dans le safari embarqué dans l'iphone et l'ipad. Pourtant ils ne se privent pas de les développer...
>cest qui bloque surtout l'achat d'un mac c'est le prix
Dans l'absolu, c'est cher, c'est vrai. Mais si tu prend un portable PC de même qualité, de poids, de puissance et de taille, tu arrives au même prix, voir plus cher. J'ai fait pas mal de comparaison avec des thinkpad, lenovo, hp, toshiba etc, très franchement, le prix d'un macbook pro de base (qui est déjà une belle bête) est à peu prés normal par rapport à la concurrence.
En fait le souci est qu'Apple ne fait pas dans le moyen et bas de gamme.
Tu dis ça juste parce que tu es déçu qu'on ne puisse pas installer des appli Java certifiée J2EE, ce qui va t'empêcher de jouer au lead architect dans des beaux projets bloatw^W java pour cette plateforme.
Les plugins, ces trucs que l'on peut incorporer dans une page web au moyen d'une balise object, ce sont des "îlots" dans le navigateur. Y a une API précise et plutôt minimaliste, à respecter pour implémenter un plugin, afin que le navigateur puisse le manipuler un minimum (faire passer des valeurs via js, l'instancier, le détruire etc...). c'est la NPAPI.
La NPAPI, incorporée dans TOUT les navigateurs depuis des lustres, y compris les navigateurs libres, ne permet absolument pas de différencier un plugin libre d'un plugin proprio.
Cependant, même si ils arrivent à detecter le type de plugin (via des tests en tout genre http://www.mozilla.com/fr/plugincheck/ ), interdire des trucs qui sont en places depuis des lustres, c'est totalement contre-productif pour l'utilisateur et Mozilla n'a aucun intérêt à interdire flash (parce que là, c'est clair, du coup, les parts de marché de Firefox s'écroulent). à signaler toutefois que Mozilla combat flash d'une autre manière : en implémentant des trucs de HTML5, en améliorant le support SVG/SMILE, dans l'optique d'offrir une alternative à flash.
Par contre, ne pas supporter un NOUVEAU truc (le format H264 via la balise video) qui est pour l'instant utilisé très minoritairement, et pour laquelle il reste des chances que l'on puisse imposer un format libre (même si tu penses le contraire), ça reste à mon sens, totalement acceptable.
Enfin bref, comparer le support de flash (et encore, Mozilla ne supporte pas flash, il support les plugins implémentant la NPAPI, nuance) et le support du H264, ça n'a aucun rapport.
>The "Chrome" is Mozilla's term for the little search box to the upper right,
non, ce n'est pas vraiment exact. Dans Mozilla, depuis la nuit des temps, "chrome" désigne l'interface, et tout ce qui tourne en mode "privilegié" (les pages XUL de l'interface, les extensions...), à l'opposition à ce qui tourne en "non privilegié" (les pages web).
Pour rappel, l'interface de Firefox (menu et cie), c'est une fenêtre ayant chargé un fichier XUL+CSS+JS. Et l'adresse d'une page XUL en mode chrome (de l'application ou d'une extension), utilise un protocol custom chrome:// . Tapez par exemple chrome://browser/content/browser.xul dans la barre d'adresse (et affichez la source ;-) )
Je ne sais pas si l'appellation de "Chrome" pour le browser de Google embête Mozilla, mais personnellement, ça m'embête, car ça apporte plutôt de la confusion quand j'explique maintenant le développement XUL.
À noter que les développeurs à l'origine du navigateur Chrome, sont des anciens de Mozilla. Ceci explique peut-être cela... Si c'est eux qui ont choisi, ce n'est pas malin de leur part... m'enfin, c'est peut être tout simplement les marketeux qui ont pondu ce nom là, sans vraiment vérifier l'origine technique...
je confirme qu'ils utilisent la lib theora officielle. Ils ont même aidé, au moins financièrement, aux récents développements sur cette lib (version 1.1 de theora)
Avec un plugin flash/autre, tu n'as quasi aucun controle sur l'affichage depuis ta page web, puisque c'est une boite noire, qui a sa propre zone d'affichage qu'il est particulièrement difficile de controler (y compris par le navigateur lui même, le plugin faisant ce qu'il veut).
Avec la balise video :
- tu as une API standardisée pour manipuler la lecture de la video en javascript
- de ce fait, tu peux fournir ta propre interface utilisateur en HTML (tes propres boutons html etc, avec ton propre design et cie)
- tu peux la "manipuler" en JS, CSS ou autre, comme n'importe quel autre élément HTML.
Bref, la balise video ouvre des nouveaux possibilités d'intégration multimédia dans les navigateurs.
Et ça bien sûr, quelque soit le format sous-jacent utilisé.
>Le navigateur lui même devient lecteur vidéo. C'est ça ? Alors, si effectivement il s'agit bien de cela, je ne vois pas vraiment l'intérêt .
Si on suit ton raisonnement, il faudrait que Firefox utilise gimp ou xv pour afficher les images...
Une page web de nos jours, ce n'est plus seulement que du texte et quelques images, mais de véritables applications ou de véritables document multimédia.
>donc du oui, de la HD avec la plus haute qualite possible.
Bof. je vois pas ce que ça apporte de regarder la roue de la fortune ou le journal de 20h en HD (comme pour 90% des emissions qui passent à la télé ou le cable). À part pour les grands films, cette surenchère de qualité est juste ridicule. Juste un truc marketing de la part des fabricants de matos informatique ou electronique grand publique, pour vendre leurs produits et t'obliger à renouveller ton matos.
>Pour l'instant Theora n'a presque rien de tout ca.
parce que personne ne veut s'y mettre. c'est le serpent qui se mort la queue. Pas de puce theora parce que theora peu utilisé. Theora peu utilisé parce que pas de puce theora. Il faut donc bien essayer de pousser le format d'un coté, et briser ce cercle vicieux. C'est ce que Mozilla tente de faire, et qu'il serait bon d'encourager également.
>Mais c'est toujours plus facile de faire dire aux autres ce qu'ils n'ont pas dit. Ca fait un peu troll minable la.
Tu parlais de quel format alors ? Qui est en mesure de concurrencer H264, à part Theora ? (et à part dirac, hors course, car pire, semble-t-il, que theora en terme de BP)
>Reste que la problematique technique (utilisation d'une autre version de Theora que celle choisie par Moxilla sans patcher et tout recompiler) reste entiere. Et tu evites soigneusement de repondre a tout ca en prenant juste le seul bout ou tu peux polemiquer...
je n'évites pas. C'est juste que je n'ai rien à dire sur la problèmatique technique. Tu veux que je te dises quoi ? je n'ai jamais programmé avec gstreamer, ni avec aucune lib video. Je peux juste te dire que techniquement, d'après mes lectures, il me semble qu'utiliser gstreamer, n'est pas aussi trivial que ça en à l'air (cf les commentaires sur le bug), et comme l'a dit roc, ce n'est que déporter le problème : le gars devra installer la plupart du temps lui même le plugin. Tu crois que l'utilisateur lambda va installer ce plugin ?
bref, "out of the box", h264 ou theora, le problème reste entier. Autant alors peut être rester sur un format libre, non encombré de brevets connus. Ce que semblent expliquer Roc et Shaver.
>c'est toujours la meme chose, il mele technique et politique tout le long
oui, il donne des raisons techniques ET idéologique. Et alors ? On n'implemente pas n'importe quoi dans un logiciels juste pour la beauté de la technique. Il faut forcément une part de reflexion idéologique/politique, surtout quand on parle de licences, de brevets logiciels. Quand on choisi une licence libre ou un format ouvert, ce n'est pas juste pour des questions techniques. Il y a toujours une question politique ou idéologique derrière.
>c'est l'opinion officielle de Mozilla, vraiment?
à priori, si tu a lu le post de shaver, il semble que ça le soit quand même, puisqu'il confirme les dire de Roc. En même temps, Roc, c'est un des piliers du développement de Gecko, donc, il a beau dire que ce n'est pas l'opinion officiel, ça l'est.
À contrario, ce que j'exprime dans les commentaires, ce n'est que ma propre opinion, le résultat de ma propre compréhension du problème dont on parle. Je ne parle pas au nom de Mozilla, je ne suis qu'un tout petit contributeur bénévole au projet.
>pourquoi participer au feeback sur le bug pour le support GStreamer si c'est pour repeter en meme temps qu'il ne veut pas de tout ca
parce qu'apparement,si j'ai bien compris, ils veulent du gstreamer pour la version mobile de Firefox, pour des plateformes spécifiques (pourquoi précisement, je n'en sais rien, je ne connais pas toute l'histoire de ce bug en détails). Ils n'en veulent pas pour la version desktop.
> on ne demande pas a Mozilla (...) de pousser H264 politiquement
bah si. Fournir un support gstreamer/directshow, c'est pousser implicitement H264. ça ne va encourager personne à utiliser un format libre comme Theora.
L'avenir dira si Mozilla aura eu raison de pousser Theora. En tout cas, leurs arguments me font croire que oui. Et l'histoire leur a déjà donné raison sur d'autres sujets (activex, extensions proprio de IE etc... http://weblogs.mozillazine.org/roc/archives/2010/01/activex_(...) ). Peut être que cela sera le cas encore pour Theora.
> si c'est pour pousser une solution inferieure techniquement, j
Faut un peu arreter les conneries. Je ne vois pas à quoi ça sert de mettre de la HD partout ou du super haut niveau de qualité de h264. Theora est suffisant à 90-99% des videos que l'on trouve sur le web (en particulier la majorité des vidéos à la con que l'on trouve sur youtube et consorts).
>je parle d'ajouter un backend pour acceder aux codecs du systeme, pas de pousser H264 en particulier
c'est pourtant ce que tu sous-entend dans la deuxième partie de ton commentaire : par "Maintenant il n'y a plus qu'a attendre que Theora se retame", tu as voulu dire "vivement que H264 gagne". CQFD.
>sans attendre que Mozilla mette a jour son fork
Mozilla n'a pas de fork. Ils intégrent la libogg telle quelle (y a juste un patch pour corriger un bug, et leurs patchs sont toujours proposés en upstream)
>t'as des arguments techniques a ajouter en plus de ceux (non critiques) sur le bug pour refuser d'ajouter ce genre de chose?
Le problème n'est pas tant technique, que "philosophique" et pécunier.
Mozilla vient à nouveau de s'expliquer sur les raisons du non support de H264 :
pour des extensions comme firebug, qui utilisent beaucoup de fonctions internes non gelées, c'est risqué, et même très déconseillé. (mais on n'a pas à le faire pour firebug, l'extension est à jour)
Je parlais surtout des extensions du genre affichage d'un bouton pour la meteo.
c'est quoi cette histoire de startup notification ? Parce que chez moi, je n'ai pas de souci pour utiliser Firefox sous linux (à te croire, c'est un truc super bloquant...)
>Et j'ajouterais que cela aurait pour but de ne pas devoir revalider toutes les extensions Car un changement de version de 3.x vers 3.x+1 désactive les extensions pour non compatibilité
Ce n'est pas tout à fait exact. Le critère d'activation et désactivation est au bon vouloir du développeur. Si il met, dans son extension, qu'elle est compatible 3.*, elle ne sera pas désactivée pour toute les versions 3.x.
malheureusement, il y a pas mal d'extensions simples qui indique une compatibilité 3.5.* par ex, alors que bon, elles utilisent des apis stabilisées depuis des lustres.
il est triste ton avis sur theora, un format libre.
Poussez à l'utilisation d'un format fermé, sur un site qui prone les logiciels libres et les formats ouverts, c'est un peu être à coté de la plaque. M'enfin.
Ce qui est sûr, c'est que ce n'est pas grâce à toi que Theora va progresser.
l'interet du XML, c'est que l'encodage est en principe indiqué dans l'entete xml, et fait partie de la spec. Autrement dit, les outils qui brassent du xml savent gérer son contenu sans problème d'encodage.
Ce n'est pas le cas des fichiers de conf plain/text. À moins qu'il y ait un caractère BOM qui permet de reconnaitre de l'utf-8 (caractère qui n'est pas toujours bien supporté, surtout par les applis qui lisent les fichiers de conf), l'application, et voir même l'éditeur, ne peuvent deviner le charset utilisé (ou se trompe une fois sur deux, la divination d'un charset n'étant pas une science exacte).
Alors ok, tu peux choisir le charset dans un éditeur. Mais encore faut-il que tu saches, TOI, avec quel charset le fichier a été enregistré. Même si il y a beaucoup de chance, dans nos contrées, pour que ce soit de l'utf-8 ou de l'iso-8859-1(5).
je suis à peu prêt certain qu'il existe des plugins pour vim/emacs, qui te permettent de charger des schémas de fichiers xml ( schémas qui sont super simple à faire en relaxng par ex), et donc d'avoir, Ô magie, la complétion automatique.
IMHO, l'argument "le XML c'est trop verbeux" etc ou "trop chiant à écrire", ne tient pas. Tout éditeur de nos jours sait gérer le XML, même sans le support de schemas.
>Il est aussi possible d'écrire la conf directement dans le langage du programme
et donc, impossible pour une application tierce (comme un clicodrome pour configurer ton truc, ou un outils tiers qui exploite les possibilités de ton appli) de lire ce fichier de conf, de le modifier ou autre...
personnellement, je ne trouve pas yaml plus lisible, tout simplement parce que la syntaxe est finalement super compliquée, avec plein de signes différents, et des règles plutôt compliquées. (genre --- | vs --- > : désolé, mais à lire ça comme ça, je ne comprendre pas ce que ça veut dire, sans aller lire la spec)
Alors que XML, ok, c'est plus verbeux, mais c'est bien plus simple à écrire.
Franchement, YAML, ça ne vaut vraiment pas la pire des syntaxes wiki. C'est du grand bricolage et c'est tout sauf simple.
Quitte à utiliser un format de fichier de conf structuré sans passer par XML, autant prendre JSON. Il n'y a pas 50 signes cabalistiques à apprendre, même pour pondre des données complexes.
Pour avoir une vision la plus réaliste possible, il faut regarder les stats de sites ayant des themes que je qualifierai de "transversaux", c'est à dire des sites qui ne parlent pas de techniques, qui sont censés être consulté par n'importe qui, par l'internaute "lambda".
Et sur ce genre de site, il n'y a effectivement qu'1% d'internautes sous linux (j'ai accès à des stats de sites de ce genre). Sachant que de nos jours, tout ceux qui ont un ordinateur sont aussi internautes, on peut dire que la part de marché de linux sur le desktop est de 1% environ. malheureusement.
Mais ton impression est quand même bonne. Linux est en progression. Mais pour l'instant, cette progression de nouveaux utilisateurs est insignifiante par rapport aux dizaines de millions d'internautes. Faut pas croire que les quelques dizaines d'utilisateurs convertis par un LUG chaque mois, va faire progresser les stats mondiales de manière "significatives" ;-) (sans vouloir dénigrer le travail des LUG ou autre associations libristes). La boule de neige n'est pour le moment pas assez grosse pour que "ça se voit".
oui, ça peut preter à confusion. le powered by Mozilla, ça ne veut pas dire que c'est la fondation/société Mozilla qui "powered" le projet, mais que ce projet utilise les technologies Mozilla.
De plus, canvas avance plus vite, normal, ce n'est qu'une surface de rendu avec des primitives graphiques de base. Absolument rien à voir avec la spec de SVG qui fait plusieurs centaines de pages. (et donc plus longue et plus complexe à implémenter).
[^] # Re: huhu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Chronique d'un flop annoncé. Évalué à 5.
acceleromètre, c'est en cours de discussion : http://www.google.com/search?hl=en&safe=off&q=site%3(...)
carnet d'adresse : http://www.w3.org/2009/dap/
device/camera : http://www.whatwg.org/specs/web-apps/current-work/multipage/(...) http://dev.w3.org/2009/dap/camera/
offline: http://www.w3.org/TR/html5/offline.html
3D dans canvas == webgl = en cours de normalisation par le consortium opengl http://www.khronos.org/webgl/
SMIL, SVG : http://www.w3.org/Graphics/SVG/ http://www.w3.org/AudioVideo/
conclusion : tout ce que j'ai cité, à par l'accelerometre, c'est pris en charge par le W3C ou chronos group
[^] # Re: huhu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Chronique d'un flop annoncé. Évalué à 6.
Y a une API pour ça dans Firefox. https://developer.mozilla.org/en/Detecting_device_orientatio(...)
> l'appareil photo
Y aura une balise device (ou input type=camera je sais plus) pour ça dans Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=507749
> le carnet d'adresses
Y a une API pour ça en préparation au W3C : http://www.w3.org/2009/dap/ (je ne sais pas si les navigateurs ont commencé à les implémenter, mais je pense que non, c'est assez jeune)
> le gps
Y a une API pour ça dans Firefox. https://developer.mozilla.org/En/Using_geolocation
> une application native peut fonctionner offline, pas une application web
Y a une API pour ça dans Firefox. http://hacks.mozilla.org/2010/01/offline-web-applications/
En fait, y a une API pour presque tout dans Firefox, et probablement dans webkit ou autre.
Et tout ça c'est dans HTML5 ou dans d'autres specs du W3C, la plupart en brouillon mais qui commencent à être implémentés dans les navigateurs.
Donc oui, on peut maintenant faire des applications web aussi puissantes que beaucoup d'applis desktop.
Et je ne parle pas de la 3D qui, elle aussi, est en train de débarquer dans la balise canvas HTML5 dans nos navigateurs, ni des animations vectoriels (SVG+SMIL)...
Alors certes, rien n'empêche à Apple de désactiver ces features dans le safari embarqué dans l'iphone et l'ipad. Pourtant ils ne se privent pas de les développer...
[^] # Re: honnêtement où avez-vous vu un fanboy Apple ici???
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Chronique d'un flop annoncé. Évalué à 3.
Dans l'absolu, c'est cher, c'est vrai. Mais si tu prend un portable PC de même qualité, de poids, de puissance et de taille, tu arrives au même prix, voir plus cher. J'ai fait pas mal de comparaison avec des thinkpad, lenovo, hp, toshiba etc, très franchement, le prix d'un macbook pro de base (qui est déjà une belle bête) est à peu prés normal par rapport à la concurrence.
En fait le souci est qu'Apple ne fait pas dans le moyen et bas de gamme.
[^] # Re: huhu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Chronique d'un flop annoncé. Évalué à 8.
[^] # Re: huhu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Chronique d'un flop annoncé. Évalué à 5.
# arrete ton char(255)
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Chronique d'un flop annoncé. Évalué à 5.
[^] # Re: Petit article récapitulatif
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 5.
Les plugins, ces trucs que l'on peut incorporer dans une page web au moyen d'une balise object, ce sont des "îlots" dans le navigateur. Y a une API précise et plutôt minimaliste, à respecter pour implémenter un plugin, afin que le navigateur puisse le manipuler un minimum (faire passer des valeurs via js, l'instancier, le détruire etc...). c'est la NPAPI.
http://en.wikipedia.org/wiki/NPAPI
La NPAPI, incorporée dans TOUT les navigateurs depuis des lustres, y compris les navigateurs libres, ne permet absolument pas de différencier un plugin libre d'un plugin proprio.
Cependant, même si ils arrivent à detecter le type de plugin (via des tests en tout genre http://www.mozilla.com/fr/plugincheck/ ), interdire des trucs qui sont en places depuis des lustres, c'est totalement contre-productif pour l'utilisateur et Mozilla n'a aucun intérêt à interdire flash (parce que là, c'est clair, du coup, les parts de marché de Firefox s'écroulent). à signaler toutefois que Mozilla combat flash d'une autre manière : en implémentant des trucs de HTML5, en améliorant le support SVG/SMILE, dans l'optique d'offrir une alternative à flash.
Par contre, ne pas supporter un NOUVEAU truc (le format H264 via la balise video) qui est pour l'instant utilisé très minoritairement, et pour laquelle il reste des chances que l'on puisse imposer un format libre (même si tu penses le contraire), ça reste à mon sens, totalement acceptable.
Enfin bref, comparer le support de flash (et encore, Mozilla ne supporte pas flash, il support les plugins implémentant la NPAPI, nuance) et le support du H264, ça n'a aucun rapport.
[^] # Re: y'a tout qui s'appelle Chrome dans leur bordel
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Dans Ubuntu Lucid ce sera Yahoo qui cherchera sur le net. Évalué à 5.
non, ce n'est pas vraiment exact. Dans Mozilla, depuis la nuit des temps, "chrome" désigne l'interface, et tout ce qui tourne en mode "privilegié" (les pages XUL de l'interface, les extensions...), à l'opposition à ce qui tourne en "non privilegié" (les pages web).
Pour rappel, l'interface de Firefox (menu et cie), c'est une fenêtre ayant chargé un fichier XUL+CSS+JS. Et l'adresse d'une page XUL en mode chrome (de l'application ou d'une extension), utilise un protocol custom chrome:// . Tapez par exemple chrome://browser/content/browser.xul dans la barre d'adresse (et affichez la source ;-) )
Je ne sais pas si l'appellation de "Chrome" pour le browser de Google embête Mozilla, mais personnellement, ça m'embête, car ça apporte plutôt de la confusion quand j'explique maintenant le développement XUL.
À noter que les développeurs à l'origine du navigateur Chrome, sont des anciens de Mozilla. Ceci explique peut-être cela... Si c'est eux qui ont choisi, ce n'est pas malin de leur part... m'enfin, c'est peut être tout simplement les marketeux qui ont pondu ce nom là, sans vraiment vérifier l'origine technique...
[^] # Re: MoFo, H.264 et liberté.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 2.
[^] # Re: MoFo, H.264 et liberté.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 5.
Techniquement, (sans parler du format de la video), elle apporte beaucoup pour le developpeur web : http://ljouanneau.com/blog/post/2008/10/16/L-element-video
Avec un plugin flash/autre, tu n'as quasi aucun controle sur l'affichage depuis ta page web, puisque c'est une boite noire, qui a sa propre zone d'affichage qu'il est particulièrement difficile de controler (y compris par le navigateur lui même, le plugin faisant ce qu'il veut).
Avec la balise video :
- tu as une API standardisée pour manipuler la lecture de la video en javascript
- de ce fait, tu peux fournir ta propre interface utilisateur en HTML (tes propres boutons html etc, avec ton propre design et cie)
- tu peux la "manipuler" en JS, CSS ou autre, comme n'importe quel autre élément HTML.
Bref, la balise video ouvre des nouveaux possibilités d'intégration multimédia dans les navigateurs.
Par exemple, ça http://people.mozilla.com/~prouget/demos/mashup/video.xhtml une demo avec video + styles CSS3 appliqué dessus, tu ne peux pas le faire en utilisant un plugin (flash, vlc ou autre). Voir d'autres démos aussi http://people.mozilla.com/~prouget/demos/ avec video+svg (http://people.mozilla.com/~prouget/demos/round/index.xhtml ) etc..
Et ça bien sûr, quelque soit le format sous-jacent utilisé.
>Le navigateur lui même devient lecteur vidéo. C'est ça ? Alors, si effectivement il s'agit bien de cela, je ne vois pas vraiment l'intérêt .
Si on suit ton raisonnement, il faudrait que Firefox utilise gimp ou xv pour afficher les images...
Une page web de nos jours, ce n'est plus seulement que du texte et quelques images, mais de véritables applications ou de véritables document multimédia.
[^] # Re: Le support du HTML 5 s'améliore...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 4.
Bof. je vois pas ce que ça apporte de regarder la roue de la fortune ou le journal de 20h en HD (comme pour 90% des emissions qui passent à la télé ou le cable). À part pour les grands films, cette surenchère de qualité est juste ridicule. Juste un truc marketing de la part des fabricants de matos informatique ou electronique grand publique, pour vendre leurs produits et t'obliger à renouveller ton matos.
>Pour l'instant Theora n'a presque rien de tout ca.
parce que personne ne veut s'y mettre. c'est le serpent qui se mort la queue. Pas de puce theora parce que theora peu utilisé. Theora peu utilisé parce que pas de puce theora. Il faut donc bien essayer de pousser le format d'un coté, et briser ce cercle vicieux. C'est ce que Mozilla tente de faire, et qu'il serait bon d'encourager également.
>Mais c'est toujours plus facile de faire dire aux autres ce qu'ils n'ont pas dit. Ca fait un peu troll minable la.
Tu parlais de quel format alors ? Qui est en mesure de concurrencer H264, à part Theora ? (et à part dirac, hors course, car pire, semble-t-il, que theora en terme de BP)
>Reste que la problematique technique (utilisation d'une autre version de Theora que celle choisie par Moxilla sans patcher et tout recompiler) reste entiere. Et tu evites soigneusement de repondre a tout ca en prenant juste le seul bout ou tu peux polemiquer...
je n'évites pas. C'est juste que je n'ai rien à dire sur la problèmatique technique. Tu veux que je te dises quoi ? je n'ai jamais programmé avec gstreamer, ni avec aucune lib video. Je peux juste te dire que techniquement, d'après mes lectures, il me semble qu'utiliser gstreamer, n'est pas aussi trivial que ça en à l'air (cf les commentaires sur le bug), et comme l'a dit roc, ce n'est que déporter le problème : le gars devra installer la plupart du temps lui même le plugin. Tu crois que l'utilisateur lambda va installer ce plugin ?
bref, "out of the box", h264 ou theora, le problème reste entier. Autant alors peut être rester sur un format libre, non encombré de brevets connus. Ce que semblent expliquer Roc et Shaver.
>c'est toujours la meme chose, il mele technique et politique tout le long
oui, il donne des raisons techniques ET idéologique. Et alors ? On n'implemente pas n'importe quoi dans un logiciels juste pour la beauté de la technique. Il faut forcément une part de reflexion idéologique/politique, surtout quand on parle de licences, de brevets logiciels. Quand on choisi une licence libre ou un format ouvert, ce n'est pas juste pour des questions techniques. Il y a toujours une question politique ou idéologique derrière.
>c'est l'opinion officielle de Mozilla, vraiment?
à priori, si tu a lu le post de shaver, il semble que ça le soit quand même, puisqu'il confirme les dire de Roc. En même temps, Roc, c'est un des piliers du développement de Gecko, donc, il a beau dire que ce n'est pas l'opinion officiel, ça l'est.
À contrario, ce que j'exprime dans les commentaires, ce n'est que ma propre opinion, le résultat de ma propre compréhension du problème dont on parle. Je ne parle pas au nom de Mozilla, je ne suis qu'un tout petit contributeur bénévole au projet.
>pourquoi participer au feeback sur le bug pour le support GStreamer si c'est pour repeter en meme temps qu'il ne veut pas de tout ca
parce qu'apparement,si j'ai bien compris, ils veulent du gstreamer pour la version mobile de Firefox, pour des plateformes spécifiques (pourquoi précisement, je n'en sais rien, je ne connais pas toute l'histoire de ce bug en détails). Ils n'en veulent pas pour la version desktop.
> on ne demande pas a Mozilla (...) de pousser H264 politiquement
bah si. Fournir un support gstreamer/directshow, c'est pousser implicitement H264. ça ne va encourager personne à utiliser un format libre comme Theora.
L'avenir dira si Mozilla aura eu raison de pousser Theora. En tout cas, leurs arguments me font croire que oui. Et l'histoire leur a déjà donné raison sur d'autres sujets (activex, extensions proprio de IE etc... http://weblogs.mozillazine.org/roc/archives/2010/01/activex_(...) ). Peut être que cela sera le cas encore pour Theora.
Vive le libre et les formats ouverts.
[^] # Re: Le support du HTML 5 s'améliore...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 3.
Faut un peu arreter les conneries. Je ne vois pas à quoi ça sert de mettre de la HD partout ou du super haut niveau de qualité de h264. Theora est suffisant à 90-99% des videos que l'on trouve sur le web (en particulier la majorité des vidéos à la con que l'on trouve sur youtube et consorts).
>je parle d'ajouter un backend pour acceder aux codecs du systeme, pas de pousser H264 en particulier
c'est pourtant ce que tu sous-entend dans la deuxième partie de ton commentaire : par "Maintenant il n'y a plus qu'a attendre que Theora se retame", tu as voulu dire "vivement que H264 gagne". CQFD.
>sans attendre que Mozilla mette a jour son fork
Mozilla n'a pas de fork. Ils intégrent la libogg telle quelle (y a juste un patch pour corriger un bug, et leurs patchs sont toujours proposés en upstream)
>t'as des arguments techniques a ajouter en plus de ceux (non critiques) sur le bug pour refuser d'ajouter ce genre de chose?
Le problème n'est pas tant technique, que "philosophique" et pécunier.
Mozilla vient à nouveau de s'expliquer sur les raisons du non support de H264 :
http://weblogs.mozillazine.org/roc/archives/2010/01/video_fr(...)
http://shaver.off.net/diary/2010/01/23/html5-video-and-codec(...)
[^] # Re: A venir
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 2.
Je parlais surtout des extensions du genre affichage d'un bouton pour la meteo.
[^] # Re: Encore merci pour le support Linux
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 4.
[^] # Re: A venir
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 5.
Ce n'est pas tout à fait exact. Le critère d'activation et désactivation est au bon vouloir du développeur. Si il met, dans son extension, qu'elle est compatible 3.*, elle ne sera pas désactivée pour toute les versions 3.x.
malheureusement, il y a pas mal d'extensions simples qui indique une compatibilité 3.5.* par ex, alors que bon, elles utilisent des apis stabilisées depuis des lustres.
[^] # Re: Le support du HTML 5 s'améliore...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 8.
Poussez à l'utilisation d'un format fermé, sur un site qui prone les logiciels libres et les formats ouverts, c'est un peu être à coté de la plaque. M'enfin.
Ce qui est sûr, c'est que ce n'est pas grâce à toi que Theora va progresser.
[^] # Re: BOF
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La France et l'Allemagne déconseillent l'utilisation d'Internet Explorer. Évalué à 2.
--->[]
[^] # Re: Règle du KISS et XML
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Requête aux devs de logiciels libres. Évalué à 2.
Ce n'est pas le cas des fichiers de conf plain/text. À moins qu'il y ait un caractère BOM qui permet de reconnaitre de l'utf-8 (caractère qui n'est pas toujours bien supporté, surtout par les applis qui lisent les fichiers de conf), l'application, et voir même l'éditeur, ne peuvent deviner le charset utilisé (ou se trompe une fois sur deux, la divination d'un charset n'étant pas une science exacte).
Alors ok, tu peux choisir le charset dans un éditeur. Mais encore faut-il que tu saches, TOI, avec quel charset le fichier a été enregistré. Même si il y a beaucoup de chance, dans nos contrées, pour que ce soit de l'utf-8 ou de l'iso-8859-1(5).
[^] # Re: Règle du KISS et XML
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Requête aux devs de logiciels libres. Évalué à 1.
IMHO, l'argument "le XML c'est trop verbeux" etc ou "trop chiant à écrire", ne tient pas. Tout éditeur de nos jours sait gérer le XML, même sans le support de schemas.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Requête aux devs de logiciels libres. Évalué à 3.
et donc, impossible pour une application tierce (comme un clicodrome pour configurer ton truc, ou un outils tiers qui exploite les possibilités de ton appli) de lire ce fichier de conf, de le modifier ou autre...
Personnellement, je trouve ça ballot.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Requête aux devs de logiciels libres. Évalué à 9.
Alors que XML, ok, c'est plus verbeux, mais c'est bien plus simple à écrire.
Franchement, YAML, ça ne vaut vraiment pas la pire des syntaxes wiki. C'est du grand bricolage et c'est tout sauf simple.
Quitte à utiliser un format de fichier de conf structuré sans passer par XML, autant prendre JSON. Il n'y a pas 50 signes cabalistiques à apprendre, même pour pondre des données complexes.
[^] # Re: part de marché de Linux
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 3.5 en tête du classement des navigateurs. Évalué à 2.
Et sur ce genre de site, il n'y a effectivement qu'1% d'internautes sous linux (j'ai accès à des stats de sites de ce genre). Sachant que de nos jours, tout ceux qui ont un ordinateur sont aussi internautes, on peut dire que la part de marché de linux sur le desktop est de 1% environ. malheureusement.
Mais ton impression est quand même bonne. Linux est en progression. Mais pour l'instant, cette progression de nouveaux utilisateurs est insignifiante par rapport aux dizaines de millions d'internautes. Faut pas croire que les quelques dizaines d'utilisateurs convertis par un LUG chaque mois, va faire progresser les stats mondiales de manière "significatives" ;-) (sans vouloir dénigrer le travail des LUG ou autre associations libristes). La boule de neige n'est pour le moment pas assez grosse pour que "ça se voit".
[^] # Re: Excellent logiciel ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal SongBird. Évalué à 2.
http://www.mozilla.org/projects/powered-by.html
[^] # Re: Rectification
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal SongBird. Évalué à 5.
http://www.mozilla.org/projects/mozilla-based.html
https://developer.mozilla.org/en/XULRunner_Hall_of_Fame
;-)
(ok, y a pas autant que d'applis en gtk ou qt, mais quand même :-) )
[^] # Re: Encore combien de temps ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Point sur le format SVG. Évalué à 1.
Faut pas confondre document et API. http://ljouanneau.com/blog/post/2009/03/26/Differences-entre(...)
De plus, canvas avance plus vite, normal, ce n'est qu'une surface de rendu avec des primitives graphiques de base. Absolument rien à voir avec la spec de SVG qui fait plusieurs centaines de pages. (et donc plus longue et plus complexe à implémenter).