Gecko ce sont des standards. Et Il y a énormément type d'appli que tu peux faire sans que tu ais besoin des nouvelles APIs qui ne sont pas encore standardisés.
qui ouvre 3 plateformes de plus, toutes 3 à l'avenir incertains, au lieu d'une. C'est toujours ça de gagné.
Et Mozilla propose une solution qui dés aujourd'hui fonctionne sur toutes les plateformes. Partout où il y a un navigateur. Aujourd'hui, tu prend n'importe quelle application web existantes aujourd'hui, elle fonctionne sur FirefoxOS. Si elle n'est pas adaptée pour le mobile (au niveau de l'interface), faire du responsive design, et basta. Ça fonctionnera non seulement sur Firefox OS, mais aussi sur tout les mobiles. Sans avoir à recompiler quelque chose :-p
Alors oui, après il y a les WebAPI pas encore toutes standardisés, pas encore toutes implémentés dans les autres navigateurs (et peut-être pour quelques unes, elles ne le seront jamais, ou alors autrement). Mais un peu d’honnêteté. La majorité des applis n'ont pas besoin de toutes ces nouvelles APIs qui touchent la plupart au matériel. 95% des applis que j'ai installé sur mon Firefox OS, aucune n'a besoin d'être en mode privilégié et je doute que la plupart utilisent ces webapis.
Donc pas besoin de faire du "optimisé pour gecko", pour faire une application pour Firefox OS
Pour quelqu'un qui essaie de défendre une solution, tu lui tires joliment dessus: pourquoi donc on devrait s'intéresser à un OS dont le fournisseur ne s'intéresse pas à nous?
pas pour l'instant. Ils privilégient d'abord un marché qui a longtemps été ignoré par les fabricants de smartphones, donc "assez facile" à conquérir. Et moins risqué. Mais ça va probablement finir par arriver. Tout dépend du succès. En tout cas, ce que je vois, c'est que des fabricants comme ZTE ou Geeksphone, sont débordés par les ventes de leurs appareils sous Firefox OS. En Europe à priori. Bref, ça peut fonctionner.
Et encore une fois. Firefox OS ne t’intéresse pas ? mais tu fais quand même une appli web ? Très bien. Du moment que ton appli respecte les standards (genre pas bourré d'API webkit only par exemple), pas de soucis. Elle fonctionnera sur tout les navigateurs. Et sur Firefox OS.
Il doit coder l'API de gestion de fichiers?
Non. il fait autrement, comme je l'ai indiqué. Il a plusieurs manière de stocker du contenu, pourquoi faudrait-il le stocker dans un système de fichier ?
Dans les pays émergent, les gens ont tous un abonnement web mobile avec un gros volume de données? Nan parce que l'intérêt d'une appli web, c'est de ne pas tout avoir en local, non?
Pas forcément. Une application web, ça se télécharge, et ça s'installe en local (ah, tient, comme sur les autres mobiles…). La technologie s'appelle le cache HTTP (spécification http, ça date pas d'hier), et mieux, Application Cache, implémenté dans tout navigateur, et permettant à l'application de faire du cache agressif, donc installé en local quoi. Et si on veut faire du Firefox OS only, on peut faire un zip, et là l'application est vraiment installée en local (y a l'équivalent dans ChromeOS, et les specs vont probablement fusionner).
Bref, comme tu le vois, pas besoin de serveur HTTP pour faire fonctionner une appli HTML/JS. On peut quand même avoir besoin d'un serveur HTTP pour échanger des données. Finalement, comme dans toutes applications Android/iOS disponibles actuellement.
Sinon, les millions de dévs web vont devoir complètement revoir leurs habitudes.
Bah, y a les newbies (nombreux, j'en conviens), et ceux qui font des vrais applis web qui savent gérer leur cache parce que bon, derrière, sans parler de Firefox OS, ils ont des serveurs web en souffrance à cause de leurs milliers d'utilisateurs. Et au final, au niveau dev, faire du cache HTTP ou du Application Cache, ça change pas des masses par rapport à "d'habitude", l'appli fonctionne pareil, le dev c'est pareil, c'est juste des paramètres coté serveur à régler (pour le cache http), et/ou un manifest à écrire (pour Application Cache).
ces millions de devs web qui pourront faire une app en un rien de temps, ils doivent l'apprendre ou pas l'API Gecko??
Non, comme je l'ai expliqué quelques lignes au dessus :-p. Tu as fait une appli web pour mobile ? Y a juste un fichier manifest à créer pour avoir une icône sur le bureau de Firefox OS, et éventuellement créer une page web (si tu ne veux pas passer par le market place) qui permettra d'appeler quelques lignes de javascript pour que l'utilisateur puisse installer cette icône. Comme tu le constate, même sans être développeur web, c'est super violent comme apprentissage :-p
FF OS arrive avec un toolkit différent de tout ce qui se fait actuellement en mobile. Personne ne développait pour Gecko avant.
Ah ? Les developeurs web, ils developpaient pour quoi alors avant ?
pour que les dévs n'aient pas l'impression d'apprendre un truc qui servira à 1 seule plateforme à l'avenir incertain.
Ah ? parce que les développeurs mobiles connaissent forcément déjà QT ?? Tu nous fais du foutage de gueule ou quoi ?
Désolé de te l'annoncer, mais oui, ils vont devoir apprendre QT, et que Sailfish, Plasma Active et Ubuntu Mobile sont loin, mais alors très loin d'avoir un avenir certain. En tout cas pas plus que Firefox OS.
Tu parlais de devs qui sont dans leur bulle ? J'ai bien l'impression que tu y es toi…
Pour FF OS, il y a un équivalent? Il doit être moins bien exposé parce que je ne l'ai pas vu passer.
parce que tu n'es pas la cible : Mozilla a ciblé les pays de l'amérique du sud en premier. Et maintenant les pays de l'est. Tu fréquentes les réseaux sociaux de ces régions ? Moi pas, donc je ne peux pas te dire si Mozilla est très présent ou pas. En tout cas, je sais que les opérateurs qui lancent leurs offres FirefoxOS dans ces pays, font de la pub comme pas possible (genre des facades d' immeuble entière avec le logo FxOS). après est ce que ça marche ou pas, pas encore assez de recule pour voir.
La concurrence est très rude!!
je ne te le fais pas dire.
que FF OS retombe dans les travers de certains projets Libres: un OS fait par des dévs…
Oui, un OS ou n'importe quel logiciel, c'est fait par des devs… #lapalissade
pour ces mêmes dévs,
Bah oui. Les dev de QT ciblent les autres devs C++ non ? Les devs d'android ciblent les développeurs java, non ?
qui vivent sur une autre planète.
Elle s'appelle le web. Ils sont quelques millions de dev d'ailleurs. C'est vrai, c'est pas grand chose. et totalement fermé comme environnement…
faut savoir ce qu'on parle par "pas grand chose". Parce que bon, des applis web dans quasi tous les domaines, c'est pas ce qu'il manque. Donne moi un exemple d'appli qui pourrait être utile pour la majorité utilisateur de Mobile (c'est à dire pas un truc de nerd), et pour laquelle il faudrait absolument passer par du C++…
mais c'est ce dont je parlais par "c'est pas l'idée la plus brillante".
c'est ton avis, ça veut pas dire que c'est la vrai pour tout le monde.
Et si tu veux bosser pour moi gratos à traduire le C++ en JS, viens
emscripten ? :-)
(pas le temps désolé)
En attendant, j'ai du code C+ qui marche sous android et iOS, et FF poubelle (certes comme WindowsPhone..)
j'ai du code HTML/JS qui marche sous android, IOS, FF, WindowsPhone et globalement tout système qui a un moteur de rendu HTML.
Tu peux fantasmer sur l'idiot en face qui veut pas changer si ça te chante.
Ah mais je ne fantasme pas. Et je n'ai pas dit que celui qui continuait à faire des cubes était un idiot ou était has been. Ce que je voulais dire, c'est que si tu veux porter une appli Qt vers du JS, il va probablement changer complètement l'architecture, afin d'utiliser au mieux les possibilités de la nouvelle plateforme que tu sembles totalement découvrir. Tu veux par exemple absolument accéder au système de fichiers. Pourquoi faire ? Gérer du contenu ? Or un fichier c'est quoi ? un identifiant (chemin) et un contenu. Ça ressemble fortement à du stockage clé valeur n'est-ce pas ? Donc en HTML, tu ne vas pas gérer des fichiers sur un système de fichier classique, tu vas gérer tes "fichiers" dans une base nosql : indexedDb par ex.. Et je suis certain que des changements de manière de fonctionner comme celle-là, on peut en avoir sur d'autres sujets pour le portage.
Maintenant, tu as absolument besoin de faire du C++. Soit. Ok, donc effectivement Firefox OS n'est pas pour toi. Mais qui a dit que ça l'était
la dernière fois que Mozilla a misé sur un cheval, c'était VP8.
Oui, et ? le problème c'est qu'au final personne n'a suivit. Est-ce vraiment de leur faute ? Des boites qui essayent de pousser une techno et qui se plantent, y en a des milliers. Et ça ne veut pas dire que sur le fond, ils avaient tord. Mais là encore, des histoires de fric ont vaincu. Et ce n'est pas parce que sur un sujet ils se sont trompés, que sur d'autres Mozilla a tord. L'avenir le dira.
Et FirefoxOS n'a pas déclanché des motivations…
Bah y a quand même des dizaines d'opérateurs et fabricant de mobiles qui sont intéressés et qui bossent sur des projets basés sur Firefox OS (LG semble bosser sur une tablette Firefox OS par ex). Alors je ne sais pas ce que tu appelles par "pas déclenchés".
D'un mec qui a acheté un smartphone qu'on lui vantait comme aussi bien les autres et qui s'est retrouvé avec un produit qui fait un dizième de ce qu'il espérait et qui ne voit pas le bout du tunnel.
Qui lui a vantait qu'il allait pouvoir faire du C++ ou autre techno ? Depuis le début, il n'y a eu aucune ambiguité : les applis seront HTML/JS et c'est tout. Avec donc les limitations que ça comporte : pas d’accès direct aux lib systèmes. Encore heureux d'ailleurs. Pas envie d'un spyware qui s'installe durablement caché on ne sait où dans le système, et envoie des SMS à tout bout de champs :-) (et de ce coté là, c'est pas android qui empêche ce genre de chose malheureusement)
Comment je peux accéder au système de fichier? j'ai pas encore trouvé comment faire un bête déplacement de fichier par exemple.
Et comment tu fais sur les autres systèmes ?
Ah oui, tu ouvres un gestionnaire de fichier.
Un gestionnaire de fichier, c'est quoi ? Une bete appli.
Et l'appli elle fait quoi ? elle utilise l'API du toolkit.
Mis à part le fait que l'API n'existe pas (encore ?) dans le toolkit "gecko" pour gérer des fichiers, Quel est la différence avec un autre OS ??
Comment je peux accéder à la caméra?
avec les API qui vont bien ? Navigator.getUserMedia, balise video etc..
Comment je peux accéder à xxx dont c'est le rôle de l'OS d'habitude?
Dans un autre OS, on fait comment ? On appelle la fonction qui va bien du toolkit, qui elle même va appeler les fonctions systèmes ou communiquer avec des daemons (par socket ou ce que tu veux).
Et tu crois qu'une appli dans Firefox OS, elle fait comment ? Elle appelle une API, exposée par Gecko. Gecko appel ensuite les fonctions systèmes communiquer avec les daemons qui vont bien. Bref, AUCUNE différence.
Comment je peux compiler mon code C++ pour FF?
Si tu es fournisseur d'une version d'un FirefoxOS spécifique, aucun souci. Tu compiles comme pour n'importe quel OS…
Mais ce n'est effectivement pas pour fournir une appli à n'importe quel utilisateur. C'est normal, le toolkit, c'est basé sur HTML/JS. c'est voulu, c'est comme ça.
M'enfin, vu ce qu'on peut faire avec du HTML/JS, vouloir faire du C++, c'est vraiment pour du très spécifique.
A chaque fois que j'ai demandé quelle API utiliser pour accéder à un truc de l'OS, j'ai eu comme seule réponse du bordel HTML/JS même pas standard ("pour le moment", ok, mais ça reste à FF pour le moment), et rien pour accès plus direct à l'OS
Peut-être faut-il revoir aussi tes paradigmes de développement ? essayer de faire autrement ? Voir même apprendre le développement web ?
Accéder au matériel directement, pourquoi faire ? Vouloir gérer des fichiers, pourquoi faire ? (Si une appli veut stocker du contenu : IndexedDb, localStorage, ou AppCache pour du "statique").
Etc etc..
En te lisant, j'ai l'impression que j'ai en face de moi un gars qui toute ça vie, a fait des cubes, qu'il a devant lui une nouvelle boite, qui possède non plus des trous en forme de carré mais en forme de triangle et qu'il essaye d'y faire rentrer ses cubes. Peut-être faut-il apprendre à faire des triangles ?
Donc pour le moment l'OS est dans le navigateur de manière schématique
non. et encore non.
Tu confonds OS et toolkit. Que le toolkit te paraisse pauvre, ok, pourquoi pas. Mais ne confondons pas OS et toolkit, merci.
c'est à dire que je dois passer par le HTML du navigateur (tiens, le navigateur…) si je veux accéder à quoi que ce soit de la machine et ça craint.
C'est à dire que je dois passer par "ici ton toolkit préféré" si je veux accéder à quoi que ce soit de la machine et ça craint.
Les mots importants sont "même futures".
ouaip, bon gros troll des familles (voire même FUD), car absolument pas argumenté, on ne sait pas de quoi il parle exactement ….
Rien de nouveau, un OS dans un navigateur, c'est pas l'idée la plus brillante.
Pardon ??? Ce n'est pas un OS dans un navigateur. Tu as dû loupé un truc dans la lecture de l'architecture de FirefoxOS
Tu as un noyau linux (pas de Gecko dedans), des drivers (pas de Gecko dedans), des démons pour gérer les divers trucs systèmes (communications & cie) (toujours pas de Gecko dedans), et enfin au dessus tu as Gecko, et ensuite des applis.
Gecko n'est que le toolkit graphique. Ce n'est pas l'OS. Remplace Gecko par Qt, GTK, ou n'importe quel tookit mobile (celui d'android) par exemple, et tu obtiens la même chose que dans n'importe quel OS de mobile ou de desktop. Autrement dit, Firefox OS est comme n'importe quel OS, sauf que le toolkit graphique est un moteur de rendu HTML. point barre.
Parce que quand je vois la doc d'installation du logiciel, je me dis que ce n'est pas gagné : si on ne connait pas l'écosystème python (un peu comme moi), c'est mort. Première ligne de commande à taper : pip install modoboa -> unknow command. voilà voilà… après ça parle de virtualenv (faut intaller ? pas installer ?). Je ne parle même pas des lib de base de donnée : "voilà les liens", et demerden sie sich pour installer ces libs python.
Enfin bref, toute la doc est du même acabit.
Et là je pousse un coup de gueule, parce que maintenant la plupart des projets web, c'est pareil : les gars qui font la doc (quand il y en a une !) croient que tout le monde sont des roxors dans le développement avec (python|ruby|nodejs|langagequetuveux), et donc font l'hypothèse que les outils de dev/deploiement qui vont autour de ces langages sont connus de tous. L'autre jour, j'ai voulu installer un redmine (à la main parce que la version debian trop vieille). Bon ça demande ruby. ok. installation de ruby. Après faut installer Rake. Ah ? Kesako ? bon, allons voir ce que c'est ce Rake (oui, j'aime bien savoir ce que j'installe sur un serveur). Suivre les instructions pour installer Rake. Ah oui mais non, il faut aussi Bundle. Gni ? kesako encore ? lançons l'installation. Ah mais qu'est ce qu'il faut à compiler tout ces libs ? z'etes sûr que Redmine a besoin de ces libs de manipulation 3d ? pfff… Enfin j'ai pu lancer l'installation de redmine…
Moi, quand je veux installer un logiciel, j'en ai STRICTEMENT RIEN A FICHE qu'il soit développé en python, ruby ou je ne sais quoi d'autre. je ne veux pas savoir ce qu'est pip, npm ou autre programme de distribution de paquet. Je veux un zip, éventuellement un ou deux scripts qui vont modifier la conf système. ou mieux, un .deb.
Tout ces frameworks et environnement de langage sont devenus de véritables usines à gaz, avec plein de softs à installer autour (à la main !). ça me gave.
On ne sait toujours pas selon eux quels sont les « fundamental flaws that cannot be fixed merely by evolving the language »
… l'API DOM …
L'API DOM ne fait pas partie de Javascript. C'est une API standardisée de manipulation de contenu XML/HTML, implémenté/implémentable dans n'importe quel langage.
Parce que probablement la spécification n'est pas assez stable pour avoir une implémentation stable.
Je crois avoir lu que maintenant Mozilla désactive avec des prefs les nouvelles fonctionnalités CSS expérimentales. (et les propriétés ne sont plus en -moz-). Cela évite aux développeurs d'utiliser des trucs pas stables en production. (et accessoirement, cela leur évite du coup d'avoir à dupliquer la même propriété en -moz, -webkit etc, puisqu'ils n'ont pas à l'utiliser :-) )
filez votre mail, faites-vous chier à rentrer tous les détails, et après on vous dira
Pour afficher les frais de port, il faudrait peut-être qu'ils sachent où tu veux faire livrer. Parce que forcément, le tarif ne sera pas le même si tu fais livrer à 10km de leur entrepôt, ou à 1500km.
Bon et puis la freebox en ipv6, elle te fout à poil, en tout cas avec la V5. Raison pour laquelle je n'ai pas encore activé l'IPV6, faute d'avoir pas eu le temps de me monter un vrai firewall.
Je vois fleurir des scripts pour aller faire des choses sur une page web, utilisant des libs plus ou moins efficace, parce que n'utilisant pas des "vrais" navigateurs. Par exemple, la page récupérée par mechanize n'est pas "vivante": le javascript n'est pas exécuté, et quand on voit que de plus en plus d'application génère du HTML à la volée : on ne peut pas faire grand chose sur ladite page web si le JS n'est pas executé. D'où d'ailleurs l'utilisation de iMacro pour certaines choses ici, infaisable avec mechanize si j'ai bien compris.
Alors Messieurs Dames, sachez qu'il existe des navigateurs "scriptables", c'est à dire que ce sont des navigateurs pilotables par un script. Et par navigateur, j'entends des vrais navigateurs, avec un vrai moteur de rendu HTML, un vrai moteur JS pour exécuter le js de la page etc. Avec ce genre d'outils, le code de la page web va donc s’exécuter pour de vrai.
Ainsi donc, vous écrivez un script (en JS), qui va dire au navigateur, "ouvre cette page", "click ici", "donne moi le contenu là" etc.. Et le navigateur va faire ce qu'on vous demande. Comme Mechanize, mais en vrai.
Le plus connu : PhantomJS, repose sur Webkit, le moteur de Safari et anciennement Chrome
Le challenger : SlimerJS, repose sur Gecko, le moteur de Firefox.
Le petit dernier : TrifleJS, repose sur Trident, le moteur de IE (encore en plein developpement)
sachant qu'ils ont à peu près la même API…
Et avec le framework CasperJS, l'API est encore plus simple à utiliser. (et "accessoirement", il sert beaucoup à réaliser des tests fonctionnels, en remplacement de Selenium et autres).
PS: ce commentaire est une pub déguisée, écrit par l'auteur de l'un de ces navigateurs ;-)
PS2: désolé :-)
, qui lui, n'a pas besoin de plusieurs Go de RAM (là, il utilise 375Mo avec 5 onglets ouverts).
Ces chiffres ne veulent rien dire. La quantité de RAM occupé par un navigateur dépend des sites qui sont affichées. Une simple page html avec trois paragraphes va demander beaucoup moins de mémoire qu'une appli comme google mail ou twitter, qui chargent des tonnes de JS et génèrent des milliers d’éléments HTML.
Et quand vous avez un navigateur avec plusieurs onglets ouverts, qui ne fait rien, et qui semblent prendre de plus en plus de mémoire, interrogez-vous si ce n'est pas un des sites ouverts qui "travaillent". Ex google mail: des mails arrivent, donc forcément, la liste des mails affichées s'allongent. et donc prend de plus en plus de mémoire.
XULrunner, c'était une technologie d'avenir en 2005, non ?
Disons que cette technologie s'est transformée. Pour rappel, une appli lancée par XULRunner, c'est une appli avec des fichiers XUL (du HTML like +++++, sous stéroïde), CSS pour le design et javascript pour le code. Voir du C++ pour des composants bas niveau (XPCOM) permettant de fournir des API au niveau JS (pratique aussi pour intégrer des libs binaires externes).
Pour l'aspect "appli lancée depuis mon bureau", Mozilla s'est tourné vers les webapps : une appli web peut ainsi être lancé en dehors du navigateur (mais avec son moteur), grâce au "web runner" (cf webapprt-stub dans le dossier Firefox). Techniquement, webapprt n'a pas énormément de différence avec l’exécutable xulrunner ;-)
Pour le langage XUL: beaucoup de choses ont été porté/spécifié vers HTML5 et CSS (en particulier le modèle de boite CSS : flexbox model).
Pour le language XBL (qui permet de faire des composants d'interface réutilisables): après un échec de standardisation de XBL2 il y a quelques années (trop complexe pour les implementeurs), la spec XBL2 a été découpée en plusieurs specs. On obtient les web components (shadow dom + templates html + scope CSS + …). En cours d’implémentation & spécification, dans chrome et firefox.
Et les webapi, permettent de remplacer l'appel à certains composants XPCOM de la plate-forme.
Bref, ce que proposait XULRunner (et propose toujours), préfigurait les technos d'aujourd'hui et de demain au niveau web ;-)
Même si aujourd'hui, on fait encore des choses largement plus puissantes avec XulRunner qu'avec les seules technos du web (HTML5…). Un navigateur scriptable par exemple ;-)
et on n'avait pas envie de reprendre les briques libres, non on recommence tout à 0
Ah ? Firefox OS, c'est un noyau linux (brique pas libre ?), gecko (brique pas libre ?), un bureau en HTML5 (Gaia, libre) et des applis html5.
Tu noteras que la philosophie du projet, c'est d'avoir tout en HTML5. Donc déjà, les bloatwares Java d'android, ça va pas trop le faire (surtout quand on vise un marché emergeant avec des téléphones low cost). Et malheureusement, un bureau en HTML5 pour mobile, ça n'existait pas. Donc ils ont fait Gaia.
Donc voilà, ils ont repris tout ce qu'ils ont pu reprendre. Je ne vois pas ce que tu peux leur reprocher (ne me parle pas de Tizen, la philosophie n'est pas tout à fait la même, et leurs applis HTML5 reposent sur des APIs propriétaires pour communiquer avec le matos, non proposées au W3C…)
Pour les développeurs, tu as toutes les API qu'un développeur attend pour un mobile qui sont en statut "unstable"
Bienvenu dans le monde du web. Il se trouve que, oui, le développeur web lambda utilise tous les jours des implémentations dont les spécifications sont instables. Surtout ceux qui ont rien à carrer des standards du web, et qui utilisent à tout va des styles -webkit-* ou des fonction webkit*…
Donc c'est normal de cracher sur un OS vendu (au niveau marketing) comme prêt alors qu'il ne l'est pas.
Faut pas non plus exagérer. Ça fonctionne. Faut juste pas trop en demander. De toute façon, vu les machines sur lesquelles FxOS est vendu, faut pas trop en demander.. Le Geeksphone, ça fait pas super stable, c'est normal, c'est vendu comme un téléphone pour développeur.
Pour les autres, tu penses bien que les opérateurs n'ont pas vendu à leurs clients des trucs qui ne fonctionnent pas. Ils ont des procédures de certifications exigeantes (et chiantes) pour qu'un téléphone soit commercialisé. La version de FxOS vendu avec les geeksphone n'est pas tout à fait la même que celle des téléphones chez Telefonica par ex.
plutôt que de lire des forums obscures qui racontent que des conneries, sur des choses sorties de leur contexte, va te cultiver sur wikipedia, ça te sera plus bénéfique
La politique du "release often, tous les trois mois" m'a tout de suite parue moins géniale, ça fait depuis que j'ai mon Geekphone Peak en avril/mai que j'attends au choix une MAJ OTA
D'une part, je pense que chez geeksphone, c'est le bordel complet coté organisation, vu la manière dont ils gèrent leurs commandes…
D'autre part pour faire une release, coté Mozilla, il faut que le système passe toutes les certifications imposées par les opérateurs. C'est super lourd…
Je ne sais pas si tout Firefox OS repose sur le code de Firefox
bah, tu enlèves l'interface XUL de Firefox et quelques composants, tu obtiens gecko, qui est utilisé dans Firefox OS (avec des differences au niveau du build, mais c'est globalement le même moteur de rendu, le même moteur JS etc…). Par contre c'est un "vieux" Gecko (18 je crois pour 1.0.1)
mais si c'est le cas il y a de quoi s'en faire, car tout l'OS est dans UN SEUL et UNIQUE processus
Il me semble que ce que tu dis là est totalement faux. Gecko est tout à fait capable de faire du multi-processus (ouvrir une page dans un process séparé). C'est utilisé dans Firefox pour Android, et … dans Firefox OS. (mais pas activé dans Firefox Desktop pour un tas de raisons valables, dont l'une est le temps de migrer tout le code de l'interface et des extensions pour tenir compte du multi process)
Bref, si ça lag, ce n'est pas la faute à du mono processus… Je pense que c'est plus dû au matos qui n'est pas super performant (que ce soit au nivo processeur, qu'au niveau mémoire disponible -> ça doit swapper à mort sur une page linuxfr qui contient des centaines de commentaires)
Mais après, tu peux toujours de compiler un firefox os et remplacer la version du téléphone. Cependant attention à la garantie, et à bien paramétrer le build…
Firefox OS est utilisable, mais pour des personnes averties je pense ou peu utilisatrice, dans le sens où il y a des petits bugs par ci, par là. Mais bonne nouvelle, tout ça évolue assez vite :-)
toujours est-il que mon Geeksphone me sert de téléphone pro (mais je ne suis pas un gros fana des smartphones), et que les sms, les appels téléphoniques se passent bien, tout comme le reste globalement.
Mais ça reste un OS jeune, peut-être manquera-t-il des fonctions que tu utilisais dans tes autres téléphones…
Si tu veux tester un peu la bete sans acheter, installe l'extension firefox os simulator dans Firefox.
cote serveur tu peux te permettre d'etre un peu plus "grumpy cat" et juste repondre "no" avec un 400.
Non. surtout si tu fais une application qui se dégrade correctement quand le JS n'est pas présent (ou pas exécuté parce que y'a un p*t*n de script de pub qui plante, genre à cause de adblock/ghostery). Il faut donc que quand la validation se fait coté serveur, le formulaire puisse se ré-afficher avec les bons messages d'erreur, et pas un "no".
[^] # Re: Oui
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
Gecko ce sont des standards. Et Il y a énormément type d'appli que tu peux faire sans que tu ais besoin des nouvelles APIs qui ne sont pas encore standardisés.
Et Mozilla propose une solution qui dés aujourd'hui fonctionne sur toutes les plateformes. Partout où il y a un navigateur. Aujourd'hui, tu prend n'importe quelle application web existantes aujourd'hui, elle fonctionne sur FirefoxOS. Si elle n'est pas adaptée pour le mobile (au niveau de l'interface), faire du responsive design, et basta. Ça fonctionnera non seulement sur Firefox OS, mais aussi sur tout les mobiles. Sans avoir à recompiler quelque chose :-p
Alors oui, après il y a les WebAPI pas encore toutes standardisés, pas encore toutes implémentés dans les autres navigateurs (et peut-être pour quelques unes, elles ne le seront jamais, ou alors autrement). Mais un peu d’honnêteté. La majorité des applis n'ont pas besoin de toutes ces nouvelles APIs qui touchent la plupart au matériel. 95% des applis que j'ai installé sur mon Firefox OS, aucune n'a besoin d'être en mode privilégié et je doute que la plupart utilisent ces webapis.
Donc pas besoin de faire du "optimisé pour gecko", pour faire une application pour Firefox OS
pas pour l'instant. Ils privilégient d'abord un marché qui a longtemps été ignoré par les fabricants de smartphones, donc "assez facile" à conquérir. Et moins risqué. Mais ça va probablement finir par arriver. Tout dépend du succès. En tout cas, ce que je vois, c'est que des fabricants comme ZTE ou Geeksphone, sont débordés par les ventes de leurs appareils sous Firefox OS. En Europe à priori. Bref, ça peut fonctionner.
Et encore une fois. Firefox OS ne t’intéresse pas ? mais tu fais quand même une appli web ? Très bien. Du moment que ton appli respecte les standards (genre pas bourré d'API webkit only par exemple), pas de soucis. Elle fonctionnera sur tout les navigateurs. Et sur Firefox OS.
Non. il fait autrement, comme je l'ai indiqué. Il a plusieurs manière de stocker du contenu, pourquoi faudrait-il le stocker dans un système de fichier ?
Ah, et puis après avoir jeté un coup d'oeil, en fait, il y a ce qu'il faut .
Pas forcément. Une application web, ça se télécharge, et ça s'installe en local (ah, tient, comme sur les autres mobiles…). La technologie s'appelle le cache HTTP (spécification http, ça date pas d'hier), et mieux, Application Cache, implémenté dans tout navigateur, et permettant à l'application de faire du cache agressif, donc installé en local quoi. Et si on veut faire du Firefox OS only, on peut faire un zip, et là l'application est vraiment installée en local (y a l'équivalent dans ChromeOS, et les specs vont probablement fusionner).
Bref, comme tu le vois, pas besoin de serveur HTTP pour faire fonctionner une appli HTML/JS. On peut quand même avoir besoin d'un serveur HTTP pour échanger des données. Finalement, comme dans toutes applications Android/iOS disponibles actuellement.
Bah, y a les newbies (nombreux, j'en conviens), et ceux qui font des vrais applis web qui savent gérer leur cache parce que bon, derrière, sans parler de Firefox OS, ils ont des serveurs web en souffrance à cause de leurs milliers d'utilisateurs. Et au final, au niveau dev, faire du cache HTTP ou du Application Cache, ça change pas des masses par rapport à "d'habitude", l'appli fonctionne pareil, le dev c'est pareil, c'est juste des paramètres coté serveur à régler (pour le cache http), et/ou un manifest à écrire (pour Application Cache).
Non, comme je l'ai expliqué quelques lignes au dessus :-p. Tu as fait une appli web pour mobile ? Y a juste un fichier manifest à créer pour avoir une icône sur le bureau de Firefox OS, et éventuellement créer une page web (si tu ne veux pas passer par le market place) qui permettra d'appeler quelques lignes de javascript pour que l'utilisateur puisse installer cette icône. Comme tu le constate, même sans être développeur web, c'est super violent comme apprentissage :-p
[^] # Re: Oui
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 0.
Ah ? Les developeurs web, ils developpaient pour quoi alors avant ?
Ah ? parce que les développeurs mobiles connaissent forcément déjà QT ?? Tu nous fais du foutage de gueule ou quoi ?
Désolé de te l'annoncer, mais oui, ils vont devoir apprendre QT, et que Sailfish, Plasma Active et Ubuntu Mobile sont loin, mais alors très loin d'avoir un avenir certain. En tout cas pas plus que Firefox OS.
Tu parlais de devs qui sont dans leur bulle ? J'ai bien l'impression que tu y es toi…
parce que tu n'es pas la cible : Mozilla a ciblé les pays de l'amérique du sud en premier. Et maintenant les pays de l'est. Tu fréquentes les réseaux sociaux de ces régions ? Moi pas, donc je ne peux pas te dire si Mozilla est très présent ou pas. En tout cas, je sais que les opérateurs qui lancent leurs offres FirefoxOS dans ces pays, font de la pub comme pas possible (genre des facades d' immeuble entière avec le logo FxOS). après est ce que ça marche ou pas, pas encore assez de recule pour voir.
je ne te le fais pas dire.
Oui, un OS ou n'importe quel logiciel, c'est fait par des devs… #lapalissade
Bah oui. Les dev de QT ciblent les autres devs C++ non ? Les devs d'android ciblent les développeurs java, non ?
Elle s'appelle le web. Ils sont quelques millions de dev d'ailleurs. C'est vrai, c'est pas grand chose. et totalement fermé comme environnement…
[^] # Re: Oui
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
faut savoir ce qu'on parle par "pas grand chose". Parce que bon, des applis web dans quasi tous les domaines, c'est pas ce qu'il manque. Donne moi un exemple d'appli qui pourrait être utile pour la majorité utilisateur de Mobile (c'est à dire pas un truc de nerd), et pour laquelle il faudrait absolument passer par du C++…
c'est ton avis, ça veut pas dire que c'est la vrai pour tout le monde.
emscripten ? :-)
(pas le temps désolé)
j'ai du code HTML/JS qui marche sous android, IOS, FF, WindowsPhone et globalement tout système qui a un moteur de rendu HTML.
Ah mais je ne fantasme pas. Et je n'ai pas dit que celui qui continuait à faire des cubes était un idiot ou était has been. Ce que je voulais dire, c'est que si tu veux porter une appli Qt vers du JS, il va probablement changer complètement l'architecture, afin d'utiliser au mieux les possibilités de la nouvelle plateforme que tu sembles totalement découvrir. Tu veux par exemple absolument accéder au système de fichiers. Pourquoi faire ? Gérer du contenu ? Or un fichier c'est quoi ? un identifiant (chemin) et un contenu. Ça ressemble fortement à du stockage clé valeur n'est-ce pas ? Donc en HTML, tu ne vas pas gérer des fichiers sur un système de fichier classique, tu vas gérer tes "fichiers" dans une base nosql : indexedDb par ex.. Et je suis certain que des changements de manière de fonctionner comme celle-là, on peut en avoir sur d'autres sujets pour le portage.
Maintenant, tu as absolument besoin de faire du C++. Soit. Ok, donc effectivement Firefox OS n'est pas pour toi. Mais qui a dit que ça l'était
Oui, et ? le problème c'est qu'au final personne n'a suivit. Est-ce vraiment de leur faute ? Des boites qui essayent de pousser une techno et qui se plantent, y en a des milliers. Et ça ne veut pas dire que sur le fond, ils avaient tord. Mais là encore, des histoires de fric ont vaincu. Et ce n'est pas parce que sur un sujet ils se sont trompés, que sur d'autres Mozilla a tord. L'avenir le dira.
Bah y a quand même des dizaines d'opérateurs et fabricant de mobiles qui sont intéressés et qui bossent sur des projets basés sur Firefox OS (LG semble bosser sur une tablette Firefox OS par ex). Alors je ne sais pas ce que tu appelles par "pas déclenchés".
Qui lui a vantait qu'il allait pouvoir faire du C++ ou autre techno ? Depuis le début, il n'y a eu aucune ambiguité : les applis seront HTML/JS et c'est tout. Avec donc les limitations que ça comporte : pas d’accès direct aux lib systèmes. Encore heureux d'ailleurs. Pas envie d'un spyware qui s'installe durablement caché on ne sait où dans le système, et envoie des SMS à tout bout de champs :-) (et de ce coté là, c'est pas android qui empêche ce genre de chose malheureusement)
[^] # Re: Oui
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
Quelle R&D ?
[^] # Re: Oui
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 1. Dernière modification le 08 janvier 2014 à 18:41.
Et comment tu fais sur les autres systèmes ?
Ah oui, tu ouvres un gestionnaire de fichier.
Un gestionnaire de fichier, c'est quoi ? Une bete appli.
Et l'appli elle fait quoi ? elle utilise l'API du toolkit.
Mis à part le fait que l'API n'existe pas (encore ?) dans le toolkit "gecko" pour gérer des fichiers, Quel est la différence avec un autre OS ??
avec les API qui vont bien ? Navigator.getUserMedia, balise video etc..
Dans un autre OS, on fait comment ? On appelle la fonction qui va bien du toolkit, qui elle même va appeler les fonctions systèmes ou communiquer avec des daemons (par socket ou ce que tu veux).
Et tu crois qu'une appli dans Firefox OS, elle fait comment ? Elle appelle une API, exposée par Gecko. Gecko appel ensuite les fonctions systèmes communiquer avec les daemons qui vont bien. Bref, AUCUNE différence.
Si tu es fournisseur d'une version d'un FirefoxOS spécifique, aucun souci. Tu compiles comme pour n'importe quel OS…
Mais ce n'est effectivement pas pour fournir une appli à n'importe quel utilisateur. C'est normal, le toolkit, c'est basé sur HTML/JS. c'est voulu, c'est comme ça.
M'enfin, vu ce qu'on peut faire avec du HTML/JS, vouloir faire du C++, c'est vraiment pour du très spécifique.
Peut-être faut-il revoir aussi tes paradigmes de développement ? essayer de faire autrement ? Voir même apprendre le développement web ?
Accéder au matériel directement, pourquoi faire ? Vouloir gérer des fichiers, pourquoi faire ? (Si une appli veut stocker du contenu : IndexedDb, localStorage, ou AppCache pour du "statique").
Etc etc..
En te lisant, j'ai l'impression que j'ai en face de moi un gars qui toute ça vie, a fait des cubes, qu'il a devant lui une nouvelle boite, qui possède non plus des trous en forme de carré mais en forme de triangle et qu'il essaye d'y faire rentrer ses cubes. Peut-être faut-il apprendre à faire des triangles ?
non. et encore non.
Tu confonds OS et toolkit. Que le toolkit te paraisse pauvre, ok, pourquoi pas. Mais ne confondons pas OS et toolkit, merci.
C'est à dire que je dois passer par "ici ton toolkit préféré" si je veux accéder à quoi que ce soit de la machine et ça craint.
ouaip, bon gros troll des familles (voire même FUD), car absolument pas argumenté, on ne sait pas de quoi il parle exactement ….
[^] # Re: Oui
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 3. Dernière modification le 08 janvier 2014 à 17:59.
Pardon ??? Ce n'est pas un OS dans un navigateur. Tu as dû loupé un truc dans la lecture de l'architecture de FirefoxOS
Tu as un noyau linux (pas de Gecko dedans), des drivers (pas de Gecko dedans), des démons pour gérer les divers trucs systèmes (communications & cie) (toujours pas de Gecko dedans), et enfin au dessus tu as Gecko, et ensuite des applis.
Gecko n'est que le toolkit graphique. Ce n'est pas l'OS. Remplace Gecko par Qt, GTK, ou n'importe quel tookit mobile (celui d'android) par exemple, et tu obtiens la même chose que dans n'importe quel OS de mobile ou de desktop. Autrement dit, Firefox OS est comme n'importe quel OS, sauf que le toolkit graphique est un moteur de rendu HTML. point barre.
# Simplifié ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Modoboa 1.1.0. Évalué à 0.
C'est moi où il y a publicité mensongère ?
Parce que quand je vois la doc d'installation du logiciel, je me dis que ce n'est pas gagné : si on ne connait pas l'écosystème python (un peu comme moi), c'est mort. Première ligne de commande à taper : pip install modoboa -> unknow command. voilà voilà… après ça parle de virtualenv (faut intaller ? pas installer ?). Je ne parle même pas des lib de base de donnée : "voilà les liens", et demerden sie sich pour installer ces libs python.
Enfin bref, toute la doc est du même acabit.
Et là je pousse un coup de gueule, parce que maintenant la plupart des projets web, c'est pareil : les gars qui font la doc (quand il y en a une !) croient que tout le monde sont des roxors dans le développement avec (python|ruby|nodejs|langagequetuveux), et donc font l'hypothèse que les outils de dev/deploiement qui vont autour de ces langages sont connus de tous. L'autre jour, j'ai voulu installer un redmine (à la main parce que la version debian trop vieille). Bon ça demande ruby. ok. installation de ruby. Après faut installer Rake. Ah ? Kesako ? bon, allons voir ce que c'est ce Rake (oui, j'aime bien savoir ce que j'installe sur un serveur). Suivre les instructions pour installer Rake. Ah oui mais non, il faut aussi Bundle. Gni ? kesako encore ? lançons l'installation. Ah mais qu'est ce qu'il faut à compiler tout ces libs ? z'etes sûr que Redmine a besoin de ces libs de manipulation 3d ? pfff… Enfin j'ai pu lancer l'installation de redmine…
Moi, quand je veux installer un logiciel, j'en ai STRICTEMENT RIEN A FICHE qu'il soit développé en python, ruby ou je ne sais quoi d'autre. je ne veux pas savoir ce qu'est pip, npm ou autre programme de distribution de paquet. Je veux un zip, éventuellement un ou deux scripts qui vont modifier la conf système. ou mieux, un .deb.
Tout ces frameworks et environnement de langage sont devenus de véritables usines à gaz, avec plein de softs à installer autour (à la main !). ça me gave.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 1.
euh… non.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 2.
L'API DOM ne fait pas partie de Javascript. C'est une API standardisée de manipulation de contenu XML/HTML, implémenté/implémentable dans n'importe quel langage.
[^] # Re: position : sticky
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 26. Évalué à 3.
Parce que probablement la spécification n'est pas assez stable pour avoir une implémentation stable.
Je crois avoir lu que maintenant Mozilla désactive avec des prefs les nouvelles fonctionnalités CSS expérimentales. (et les propriétés ne sont plus en -moz-). Cela évite aux développeurs d'utiliser des trucs pas stables en production. (et accessoirement, cela leur évite du coup d'avoir à dupliquer la même propriété en -moz, -webkit etc, puisqu'ils n'ont pas à l'utiliser :-) )
[^] # Re: [HS] le mauvais réflexe Amazon
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 1.
Pour afficher les frais de port, il faudrait peut-être qu'ils sachent où tu veux faire livrer. Parce que forcément, le tarif ne sera pas le même si tu fais livrer à 10km de leur entrepôt, ou à 1500km.
[^] # Re: Pourquoi faire ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Contre la phobie du root. Évalué à 2.
Ah bon ? Un machine qui fait que du NAT, c'est un pare-feu ?
http://www.bortzmeyer.org/nat-et-securite.html
Bon et puis la freebox en ipv6, elle te fout à poil, en tout cas avec la V5. Raison pour laquelle je n'ai pas encore activé l'IPV6, faute d'avoir pas eu le temps de me monter un vrai firewall.
[^] # Re: Outils mieux adaptés ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal HowTo: suppression de compte FB. Évalué à 4.
mauvaise url de casper. voici la bonne : http://casperjs.org
# Outils mieux adaptés ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal HowTo: suppression de compte FB. Évalué à 6.
Hello,
Je vois fleurir des scripts pour aller faire des choses sur une page web, utilisant des libs plus ou moins efficace, parce que n'utilisant pas des "vrais" navigateurs. Par exemple, la page récupérée par mechanize n'est pas "vivante": le javascript n'est pas exécuté, et quand on voit que de plus en plus d'application génère du HTML à la volée : on ne peut pas faire grand chose sur ladite page web si le JS n'est pas executé. D'où d'ailleurs l'utilisation de iMacro pour certaines choses ici, infaisable avec mechanize si j'ai bien compris.
Alors Messieurs Dames, sachez qu'il existe des navigateurs "scriptables", c'est à dire que ce sont des navigateurs pilotables par un script. Et par navigateur, j'entends des vrais navigateurs, avec un vrai moteur de rendu HTML, un vrai moteur JS pour exécuter le js de la page etc. Avec ce genre d'outils, le code de la page web va donc s’exécuter pour de vrai.
Ainsi donc, vous écrivez un script (en JS), qui va dire au navigateur, "ouvre cette page", "click ici", "donne moi le contenu là" etc.. Et le navigateur va faire ce qu'on vous demande. Comme Mechanize, mais en vrai.
sachant qu'ils ont à peu près la même API…
Et avec le framework CasperJS, l'API est encore plus simple à utiliser. (et "accessoirement", il sert beaucoup à réaliser des tests fonctionnels, en remplacement de Selenium et autres).
PS: ce commentaire est une pub déguisée, écrit par l'auteur de l'un de ces navigateurs ;-)
PS2: désolé :-)
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 7.
Ces chiffres ne veulent rien dire. La quantité de RAM occupé par un navigateur dépend des sites qui sont affichées. Une simple page html avec trois paragraphes va demander beaucoup moins de mémoire qu'une appli comme google mail ou twitter, qui chargent des tonnes de JS et génèrent des milliers d’éléments HTML.
Et quand vous avez un navigateur avec plusieurs onglets ouverts, qui ne fait rien, et qui semblent prendre de plus en plus de mémoire, interrogez-vous si ce n'est pas un des sites ouverts qui "travaillent". Ex google mail: des mails arrivent, donc forcément, la liste des mails affichées s'allongent. et donc prend de plus en plus de mémoire.
[^] # Re: JavaScript sans HTML5...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Disons que cette technologie s'est transformée. Pour rappel, une appli lancée par XULRunner, c'est une appli avec des fichiers XUL (du HTML like +++++, sous stéroïde), CSS pour le design et javascript pour le code. Voir du C++ pour des composants bas niveau (XPCOM) permettant de fournir des API au niveau JS (pratique aussi pour intégrer des libs binaires externes).
Pour l'aspect "appli lancée depuis mon bureau", Mozilla s'est tourné vers les webapps : une appli web peut ainsi être lancé en dehors du navigateur (mais avec son moteur), grâce au "web runner" (cf webapprt-stub dans le dossier Firefox). Techniquement, webapprt n'a pas énormément de différence avec l’exécutable xulrunner ;-)
Pour le langage XUL: beaucoup de choses ont été porté/spécifié vers HTML5 et CSS (en particulier le modèle de boite CSS : flexbox model).
Pour le language XBL (qui permet de faire des composants d'interface réutilisables): après un échec de standardisation de XBL2 il y a quelques années (trop complexe pour les implementeurs), la spec XBL2 a été découpée en plusieurs specs. On obtient les web components (shadow dom + templates html + scope CSS + …). En cours d’implémentation & spécification, dans chrome et firefox.
Et les webapi, permettent de remplacer l'appel à certains composants XPCOM de la plate-forme.
Bref, ce que proposait XULRunner (et propose toujours), préfigurait les technos d'aujourd'hui et de demain au niveau web ;-)
Même si aujourd'hui, on fait encore des choses largement plus puissantes avec XulRunner qu'avec les seules technos du web (HTML5…). Un navigateur scriptable par exemple ;-)
[^] # Re: JavaScript sans HTML5...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Il y a encore pas mal d'appli.
https://developer.mozilla.org/en-US/docs/XULRunner_Hall_of_Fame
Bon ok, c'est peu comparé à du QT ou gtk…
[^] # Re: Ils doivent se bouger le popotin ! Firefox OS 1.2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 2.
Ah ? Firefox OS, c'est un noyau linux (brique pas libre ?), gecko (brique pas libre ?), un bureau en HTML5 (Gaia, libre) et des applis html5.
Tu noteras que la philosophie du projet, c'est d'avoir tout en HTML5. Donc déjà, les bloatwares Java d'android, ça va pas trop le faire (surtout quand on vise un marché emergeant avec des téléphones low cost). Et malheureusement, un bureau en HTML5 pour mobile, ça n'existait pas. Donc ils ont fait Gaia.
Donc voilà, ils ont repris tout ce qu'ils ont pu reprendre. Je ne vois pas ce que tu peux leur reprocher (ne me parle pas de Tizen, la philosophie n'est pas tout à fait la même, et leurs applis HTML5 reposent sur des APIs propriétaires pour communiquer avec le matos, non proposées au W3C…)
Bienvenu dans le monde du web. Il se trouve que, oui, le développeur web lambda utilise tous les jours des implémentations dont les spécifications sont instables. Surtout ceux qui ont rien à carrer des standards du web, et qui utilisent à tout va des styles -webkit-* ou des fonction webkit*…
Faut pas non plus exagérer. Ça fonctionne. Faut juste pas trop en demander. De toute façon, vu les machines sur lesquelles FxOS est vendu, faut pas trop en demander.. Le Geeksphone, ça fait pas super stable, c'est normal, c'est vendu comme un téléphone pour développeur.
Pour les autres, tu penses bien que les opérateurs n'ont pas vendu à leurs clients des trucs qui ne fonctionnent pas. Ils ont des procédures de certifications exigeantes (et chiantes) pour qu'un téléphone soit commercialisé. La version de FxOS vendu avec les geeksphone n'est pas tout à fait la même que celle des téléphones chez Telefonica par ex.
[^] # Re: Mozilla et la confiance dans la bête
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 1.
plutôt que de lire des forums obscures qui racontent que des conneries, sur des choses sorties de leur contexte, va te cultiver sur wikipedia, ça te sera plus bénéfique
http://en.wikipedia.org/wiki/The_Book_of_Mozilla
[^] # Re: Ils doivent se bouger le popotin ! Firefox OS 1.2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 2.
D'une part, je pense que chez geeksphone, c'est le bordel complet coté organisation, vu la manière dont ils gèrent leurs commandes…
D'autre part pour faire une release, coté Mozilla, il faut que le système passe toutes les certifications imposées par les opérateurs. C'est super lourd…
bah, tu enlèves l'interface XUL de Firefox et quelques composants, tu obtiens gecko, qui est utilisé dans Firefox OS (avec des differences au niveau du build, mais c'est globalement le même moteur de rendu, le même moteur JS etc…). Par contre c'est un "vieux" Gecko (18 je crois pour 1.0.1)
Il me semble que ce que tu dis là est totalement faux. Gecko est tout à fait capable de faire du multi-processus (ouvrir une page dans un process séparé). C'est utilisé dans Firefox pour Android, et … dans Firefox OS. (mais pas activé dans Firefox Desktop pour un tas de raisons valables, dont l'une est le temps de migrer tout le code de l'interface et des extensions pour tenir compte du multi process)
Bref, si ça lag, ce n'est pas la faute à du mono processus… Je pense que c'est plus dû au matos qui n'est pas super performant (que ce soit au nivo processeur, qu'au niveau mémoire disponible -> ça doit swapper à mort sur une page linuxfr qui contient des centaines de commentaires)
[^] # Re: Ils doivent se bouger le popotin ! Firefox OS 1.2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 0.
Le monde ne s'est pas fait en un jour. Pareil pour Firefox OS ;-)
[^] # Re: Mise à jour
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 3.
Par les opérateurs je crois.
Mais après, tu peux toujours de compiler un firefox os et remplacer la version du téléphone. Cependant attention à la garantie, et à bien paramétrer le build…
[^] # Re: Téléphone principal
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 3.
Firefox OS est utilisable, mais pour des personnes averties je pense ou peu utilisatrice, dans le sens où il y a des petits bugs par ci, par là. Mais bonne nouvelle, tout ça évolue assez vite :-)
toujours est-il que mon Geeksphone me sert de téléphone pro (mais je ne suis pas un gros fana des smartphones), et que les sms, les appels téléphoniques se passent bien, tout comme le reste globalement.
Mais ça reste un OS jeune, peut-être manquera-t-il des fonctions que tu utilisais dans tes autres téléphones…
Si tu veux tester un peu la bete sans acheter, installe l'extension firefox os simulator dans Firefox.
[^] # Re: Mozilla et la confiance dans la bête
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox OS 1.1 et autres actualités. Évalué à 2.
t'es vraiment un grand malade…
[^] # Re: Angular JS vs Server Side framework
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Symfony, AngularJS, ..... Évalué à 3.
Non. surtout si tu fais une application qui se dégrade correctement quand le JS n'est pas présent (ou pas exécuté parce que y'a un p*t*n de script de pub qui plante, genre à cause de adblock/ghostery). Il faut donc que quand la validation se fait coté serveur, le formulaire puisse se ré-afficher avec les bons messages d'erreur, et pas un "no".