Euh non, on n'utilise pas SQLITE sur un serveur web, ce n'est absolument pas fait pour. Concurrence d'accés et cie, bonjour les fichiers corrompus après.
Le web par ci le web par là, chez Mozilla Internet ça se résume par le web,
bah oui, c'est leur truc.
C'est comme si tu te plaignais qu'un restaurant, spécialisé dans la cuisine du sud ouest et se lançant dans la vente à emporter, fournisse ses plats dans des barquettes plutôt que sous forme de sandwich. Bah oui mais non, eux, c'est la cuisine du sud ouest qu'ils savent faire, pas les sandwichs. ni les pizzas.
maintenant en voulant "libérer" les smartphones tels des chevaliers blancs, ils vont niveler nos terminaux par le bas
Mozilla ne pretend pas être des chevaliers blancs. Si le fait de faire tout en html/js ne plait pas, de projets comme Meego et cie n'ont qu'à se bouger. Et si ils ne peuvent pas se bouger (faute de moyen ou autre), ce serait la faute de Mozilla ? N'importe quoi n'est-ce pas…
Si QT est meilleur sur smartphone (chose que je suis incapable de juger), bah monte ta boite, ou prend le lead de Meego ou je ne sais quel projet, tu as à priori des chances si html/js c'est si merdique que ça ;-)
Mozilla n'a pas vocation (ni les moyens) de sauver tous les projets libres moribons, hein..
ok, on a compris que tu n'aimes pas les technos web pour faire des applis. Pas la peine d'en rajouter 3 couches.
Et pas la peine de taper sur Mozilla parce que Meego est plus ou moins à l'abandon. Prends-en toi plutôt à ceux qui l'ont abandonné.
Et je ne vois pas pourquoi Mozilla devrait reprendre Meego. Ce qu'ils maitrisent, ce sont les technos web, ils essayent d'améliorer ces technos. Leur domaine, c'est le web, c'est la défense d'un web ouvert etc.
Donc bref, meego, ça ne correspond pas vraiment à ce qu'ils savent faire, à ce qu'ils maitrisent. Et donc à priori, il n'y a pas vraiment de raison qu'ils réussiraient mieux que les autres à populariser Meego.
Et comme ils savent très bien que le web n'est pas fait pour faire comme les apps natives
Ouai, enfin, tu sais, le XUL, c'est pas éloigné de la stack des technos web (s/html/xul). Et ils utilisent ces technos depuis près de 15 ans pour faire des applis (dont une qui s'appelle Firefox..).
Reprendre Meego qui fait déjà tout ça et est conçu pour
ah ouai, c'est sûr, reprendre des millions de lignes de codes qu'on ne connait pas, ça se fait en un claquement de doigt.
Non, les boites postales n'ont certainement pas été créés pour remplacer l'adresse d'un siège sociale d'une société (aussi petite soit-elle comme celle d'un autoentrepreneur). C'est même carrément interdit. (un coup de google pour t'en convaincre : http://www.juritravail.com/Question/domicilier-son-siege-social/Dossier/Id/5811 )
Je confirme, après avoir eu mon statut d'auto-entrepreneur (que je n'ai désormais plus), j'ai commencé à recevoir les offres de Google.
Mais pire, si vous recevez ce genre de courrier, il y a de fortes chances que votre adresse soit publique, et récupérable via une recherche de votre nom, sur google map par exemple. Et pour les entrepreneurs, l'adresse est souvent une adresse privée, qu'on ne veut pas forcément rendre publique (bon, ça dépend de l'activité après..). Le souci est que pour la faire retirer, y a moyen (il faut faire la demande via le site, ils envoient un courrier avec un code qu'il faut indiquer sur le site pour confirmer la suppression), mais il y a des chances que cette suppression ne soit pas effective sur le moyen terme. Vous êtes à nouveau référencé au bout d'un moment, même si vous n'êtes plus en activité (ça m'est arrivé)
C'est pas en soit déjà un problème ? Pourquoi le fait de l'avoir donné pour accéder à tes sites les a rendu disponibles à toutes les extensions ?
Parce que le fait que j'ai donné mon mot de passe a débloqué le gestionnaire de mot de passe.
Il est très difficile voir impossible pour un composant (donc ici le gestionnaire de mot de passe), de distinguer qui l'appel (c'est l'extension A? B?).
Bon maintenant, je n'ai pas une connaissance assez approfondi du gestionnaire de mot de passe pour te dire ce qui est faisable ou pourquoi ça le fait exactement.
Il faudrait que chacune redemandent le mot de passe
Oui, c'est ce qu'il faut. Mais apparemment, c'est à l'extension de le faire.
Ainsi pour cette extension, il faudrait que quand tu clique sur l’icône, il te demande ton mot de passe. Ça limite déjà pas mal la possibilité pour quelqu'un de voir tes mots de passes via cette extension.
C'est que j'ai expliqué : c'est ce qu'il faudrait qu'elle fasse ! (au moins par elle-même)
Elle devrait redemander le mot de passe principal pour afficher les mots de passe. Actuellement, elle peut récupérer les mots de passe parce que j'ai déjà tapé mon mot de passe principal. Mais elle devrait redemander ce mot de passe pour afficher. Comme le fait le gestionnaire de mot de passe. Que tu ais déjà tapé ou non le mot de passe principal en début de session, le gestionnaire te redemande le mot de passe principal, pour s'assurer que c'est bien toi qui veut voir TES mots de passe (et pas un gars qui squate ton PC pendant une absence de quelques minutes par exemple).
Aie aie aie.. Pour ceux qui ont un mot de passe principal, je vous recommande de désinstaller l'extension password reuse visualizer. Cette extension ne demande même pas le master password avant d'afficher les mots de passes, comme le fait le gestionnaire de mot de passe.
de peur de se prendre une soufflante du père Glazman
pas du tout. Daniel n'a que peu d'influence sur les décisions de Mozilla depuis quelques années. Mozilla ne laisse pas mourrir XulRunner, pour la simple raison que Firefox est basé dessus. Mais Mozilla ne met plus en avant XulRunner, parce qu'ils ne veulent pas dépenser leur énergie sur ce projet en terme de dev, marketing et autre. S'occuper d'un produit de la nature de XulRunner, c'est s'occuper à essayer de résoudre toutes les problématiques des développeurs utilisant cette plateforme, problématiques qui ne rentreraient pas dans les objectifs actuels de Mozilla. Ils préfèrent se concentrer sur la plateforme purement web. Ils bossent ainsi sur la plateforme XUL, uniquement pour répondre à leurs besoins (à ceux de Firefox, TB et autres), et non aux besoins des autres.
Maintenant il y a pas mal de "cinglés" comme moi qui utilisent XulRunner et gecko pour leurs projets, parce qu'ils trouvent cette plateforme géniale malgré ses défauts.
De plus, vu que XulRunner n'est qu'un main() un poil différent de celui de firefox, et ne contient pas les fichiers XUL/JS/CSS de firefox (en gros), refaire un XulRunner ne serait pas compliqué. Le seul moyen pour Mozilla de tuer XulRunner, serait de tuer XUL et tout ce qui va avec (système d'overlay etc). Ce qui n'est pas près d'arriver...
Je ne vois en quoi le fait que ce ne soit pas le but devrait m'empêcher de le faire...
Certes. Mais tu t'embarques dans un truc pas adapté, donc qui te prend 10 fois plus de temps à réaliser que si tu utilisais des outils plus adaptés. C'est comme si tu utilisais un rateau pour faire un trou, alors que si tu utilisais une pelle, tu serais plus efficace.
En prenant un toolkit 100% C++ (puisqu'il semble que ce soit ton langage de prédilection), comme Qt, tu pourrais te concentrer plus sur les éléments de ton framework plutôt que sur des contournements de la plateforme...
d'autant plus si l'on n'a aucune affinité avec JavaScript...
Oui donc tu t'es trompé de plateforme à mon sens...
Si j'ai choisi XUL pour de nombreux développements (depuis des années), c'est bien pour le coté "web" de la plateforme (donc XML/XUL/CSS ET Javascript). Si je voulais faire une appli entièrement en C++, je ne choisirais certainement pas XULRunner...
Toute la partie description de l'interface reste en XUL...
le fait que tu n'utilises plus JS enlève une grande partie de l'intérêt de la plateforme selon moi (dev rapide, maintenance et evolution plus aisées etc..)
On code l'application exactement comme on le ferait en JavaScript, sauf qu'on utilise C++
Donc tu passes 10 fois plus de temps à implémenter un truc (des listeners et autres trucs d'interface), pour un résultat qui n'apporte au final rien en terme de perf (au niveau de l'UI).
disclamer : je fais du xpcom c++ depuis des années...
Lorsque l'on code une application en JavaScript, on accède en fait à des composants écrits en C++ à travers leur interface JavaScript. L'idée c'est d’accéder à ces composants directement en C++, sans passer par JavaScript. On a donc, au contraire, une couche logicielle en moins...
moui ok, je comprend mieux le principe de ton truc. Mais quand même, comme je dis, ça n'apporte rien en terme de perf, au niveau de l'interface utilisateur, sauf si tu manipules à tour de bras des centaines d’éléments XUL. En tout cas le rapport (productivité, facilité de dev, de maintenance etc)/performance est très très faible.
Mais elle ne détaille pas comment manipuler un élément XUL en C++. Par exemple, je n'ai trouvé aucune documentation qui indique qu'un élément 'tree' en XUL correspond, en C++, à l'objet 'nsIDOMXULTreeElement'
Pourtant, tout est indiqué sur la doc de la balise tree, https://developer.mozilla.org/en/XUL/tree , en particulier les interfaces qu'elle utilise, et donc ses propriétés dont la view etc. Etant donné que les objets DOM accessibles en JS sont simplement un accés XPCom aux objets C++ correspondant... Et par le passé, XulPlanet.org était encore mieux documenté au niveau des interfaces etc..
Ça fait plus de 11 ans que j'utilise le CVS de savannah.gnu.org. Pourquoi changer quelque chose qui fonctionne ?
Pour être plus productif ? Pour faciliter les contributions ? Pour avoir un outil plus performant ? pour avoir une interface web agréable à utiliser ? (le browser CVS est juste horrible).
Cela rend le développement d'une application XULRunner entièrement en C++ très compliqué,
Le but de XulRunner n'est pas un framework/une plateforme pour écrire une appli entièrement en C++.
Pourquoi ne pas utiliser QT ou autre toolkit graphique ?? Parce que si dans ton projet, l'utilisation du JS est à proscrire, tu t'es, à mon avis, trompé de framework.
oui, je me pose exactement la même question. D'après ce que j'ai compris, on n'a plus à utiliser de gestionnaire d'évènement ou autres trucs "webesque" de XulRunner. Et en gros, tout le code de l'appli est dans des libs externes en C/C++.
Et au final aussi, un truc à la XPCom à été recodé en passant par XPCom. Au final on a donc une couche qui transmet des appels vers les libs externe, donc comme XPCom. -> double couche logicielle pour accéder à la lib externe. à moins d'avoir rien compris au bidule :-)
Bon, sinon, de la doc sur XPCOM C++, elle existe quand même https://developer.mozilla.org/en/XPCOM. Et il y a aussi une alternative, pour accéder directement aux fonctions d'une lib : js-ctypes.
(hors sujet: CVS, c'est vraiment pénible, je recommande d'utiliser un gestionnaire de source récent :-p)
et pour continuer dans le #fail, quietty.com n'est pas accessible depuis un navigateur web, alors que www.quietty.com, si. Une petite mise à jour DNS et config apache/nginx/autre s'impose ;-)
Bon sinon, l'idée du produit est intéressante. Par contre, il ne faudrait pas que le blog connaisse un succès fou, vu le peu de bande passante en upload qu'on a en ADSL en général.
Un jour peut être, les fournisseurs d’accès nous fournirons des débits symétriques...
Oui il y a cette différence d'ouverture de source et de spec.
Mais il n'y a aucune différence quant à la situation et aux conséquences. Le problème se situe dans l'utilisation de propriété non standards ou experimentales. Tout comme avec IE6, les développeurs utilisent des fonctionnalités qui ne sont implémentées que dans un seul moteur de navigateur (ou qui ne sont interprétables que par un seul moteur de navigateur). Cela conduit donc à un web "optimisé pour", tout comme avec IE6. Le fait que lesdites fonctionnalités soient implémentées sous licence libre ou proprio ne change rien au problème, et encore moins à une éventuel solution. On assiste à nouveau à une balkanisation du web.
oui, c'est une bonne idée. Mais j'ai bien peur qu'il soit trop tard, vu apparemment les centaines de milliers de sites pour mobile qui ciblent webkit..
Si j'utilise disons une fonction non-POSIX, mon but n'est pas de faire chier un organisme de normalisation mais de satisfaire un besoin. Le jour où POSIX inclut une fonctionnalité équivalente, eh ben tant mieux : je peux migrer mon code vers une API plus portable.
Oui. Tout comme les développeurs peuvent migrer leur code. Mais dans 99% des cas, ils ne le font pas. Parce qu'une fois le site développé, les "vieux" trucs restent. Et parfois très longtemps. Surtout quand ceux qui sont chargés de faire évoluer le site ne sont pas les développeurs initiaux. Il arrive trèèèèès souvent qu'ils ne touchent qu'à ce qu'il y a besoin d'être touché, par manque de temps, par peur de casser des choses, par j'm'enfoutisme etc..
Au W3C de les fournir à la nouvelle itération
Tu es à coté de la plaque. Les éditeurs implementent les trucs BIEN AVANT de proposer des specs au W3C. C'est pas le W3C qui "fournit".
Je ne vois pas pourquoi leurs problèmes d'organisation interne les autorisent à incriminer les développeurs Web qui, eux, n'y sont pour rien.
Non, ce sont les développeurs web qui sont responsables. les propriétés prefixées sont pour la plupart des trucs experimentaux. LES DEVELOPPEURS NE SONT PAS CENSES LES UTILISER. Ou si ils les utilisent, qu'ils aient au moins le courage de mettre les propriétés préfixés pour les autres navigateurs ET de mettre celles sans prefixe, ceci afin de garantir un minimum que leur site fonctionnera PARTOUT et dans la durée.
Un développeur web est censé suivre les standards. C'est son job de faire en sorte que son site (public) soit lisible partout, parce que c'est la nature même du web d'être "agent agnostic". Ne pas le faire est une faute professionnelle selon moi. Ne pas le faire, c'est ne pas suivre les "rêgles" du WEB. Si on ne veut pas suivre ces rêgles, il faut changer de branche.
Imaginons qu'un navigateur X non basé sur webkit gagne énormément de part de marché pour X raisons, sur le mobile. Que va-t-il arrivé ? Plein de sites cassés. Parce que des développeurs incompétents n'auront pas fait leur job comme il faut, en utilisant des trucs prefixés ciblant un seul navigateur. Bref, des développeurs comme il y en avait au temps de IE6. Avec les conséquences que l'on connait.
[^] # Re: t'accuse
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal MySQL est une bouse immonde. Évalué à -2.
Euh non, on n'utilise pas SQLITE sur un serveur web, ce n'est absolument pas fait pour. Concurrence d'accés et cie, bonjour les fichiers corrompus après.
[^] # Re: Ça fait plaisir
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles Mozilla : Marketplace, Metro, Persona, B2G, Add-on, API web. Évalué à 4.
bah oui, c'est leur truc.
C'est comme si tu te plaignais qu'un restaurant, spécialisé dans la cuisine du sud ouest et se lançant dans la vente à emporter, fournisse ses plats dans des barquettes plutôt que sous forme de sandwich. Bah oui mais non, eux, c'est la cuisine du sud ouest qu'ils savent faire, pas les sandwichs. ni les pizzas.
Mozilla ne pretend pas être des chevaliers blancs. Si le fait de faire tout en html/js ne plait pas, de projets comme Meego et cie n'ont qu'à se bouger. Et si ils ne peuvent pas se bouger (faute de moyen ou autre), ce serait la faute de Mozilla ? N'importe quoi n'est-ce pas…
Si QT est meilleur sur smartphone (chose que je suis incapable de juger), bah monte ta boite, ou prend le lead de Meego ou je ne sais quel projet, tu as à priori des chances si html/js c'est si merdique que ça ;-)
Mozilla n'a pas vocation (ni les moyens) de sauver tous les projets libres moribons, hein..
[^] # Re: Ça fait plaisir
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles Mozilla : Marketplace, Metro, Persona, B2G, Add-on, API web. Évalué à 6. Dernière modification le 03 mars 2012 à 22:46.
ok, on a compris que tu n'aimes pas les technos web pour faire des applis. Pas la peine d'en rajouter 3 couches.
Et pas la peine de taper sur Mozilla parce que Meego est plus ou moins à l'abandon. Prends-en toi plutôt à ceux qui l'ont abandonné.
Et je ne vois pas pourquoi Mozilla devrait reprendre Meego. Ce qu'ils maitrisent, ce sont les technos web, ils essayent d'améliorer ces technos. Leur domaine, c'est le web, c'est la défense d'un web ouvert etc.
Donc bref, meego, ça ne correspond pas vraiment à ce qu'ils savent faire, à ce qu'ils maitrisent. Et donc à priori, il n'y a pas vraiment de raison qu'ils réussiraient mieux que les autres à populariser Meego.
Ouai, enfin, tu sais, le XUL, c'est pas éloigné de la stack des technos web (s/html/xul). Et ils utilisent ces technos depuis près de 15 ans pour faire des applis (dont une qui s'appelle Firefox..).
ah ouai, c'est sûr, reprendre des millions de lignes de codes qu'on ne connait pas, ça se fait en un claquement de doigt.
[^] # Re: mysqlnd
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de PHP 5.4. Évalué à 3.
Non non, mysqlnd n'est pas écrite en PHP, mais bien en C. http://svn.php.net/viewvc/php/php-src/trunk/ext/mysqlnd/
[^] # Re: RNCS ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Google connaît mon adresse ... postale?!. Évalué à 3.
Non, les boites postales n'ont certainement pas été créés pour remplacer l'adresse d'un siège sociale d'une société (aussi petite soit-elle comme celle d'un autoentrepreneur). C'est même carrément interdit. (un coup de google pour t'en convaincre : http://www.juritravail.com/Question/domicilier-son-siege-social/Dossier/Id/5811 )
[^] # Re: RNCS ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Google connaît mon adresse ... postale?!. Évalué à 4.
quand tu es autoentrepreneur, en général, tu n'as pas vraiment d'autres locaux que le domicile familial..
[^] # Re: RNCS ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Google connaît mon adresse ... postale?!. Évalué à 2.
Je confirme, après avoir eu mon statut d'auto-entrepreneur (que je n'ai désormais plus), j'ai commencé à recevoir les offres de Google.
Mais pire, si vous recevez ce genre de courrier, il y a de fortes chances que votre adresse soit publique, et récupérable via une recherche de votre nom, sur google map par exemple. Et pour les entrepreneurs, l'adresse est souvent une adresse privée, qu'on ne veut pas forcément rendre publique (bon, ça dépend de l'activité après..). Le souci est que pour la faire retirer, y a moyen (il faut faire la demande via le site, ils envoient un courrier avec un code qu'il faut indiquer sur le site pour confirmer la suppression), mais il y a des chances que cette suppression ne soit pas effective sur le moyen terme. Vous êtes à nouveau référencé au bout d'un moment, même si vous n'êtes plus en activité (ça m'est arrivé)
[^] # Re: Déjà soulevé
Posté par Laurent J (site web personnel, Mastodon) . En réponse à l’entrée du suivi Changer ou améliorer la lib diff pour visualiser les changements. Évalué à 3 (+0/-0).
c'est bien dommage. Parce qu'à priori, son algorithme est tout pourri (désolé pour ce vilain mot, mais je n'arrive pas à trouver d'autres termes).
J'utilise personnellement une lib de diff en PHP, qui est plutôt efficace https://github.com/jelix/jelix/tree/master/lib/diff
Je sais que le site est en ruby, mais peut-être pourriez-vous vous inspirer de l'algo...
[^] # Re: Gros trou de sécu
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Deux extensions originales pour Firefox. Évalué à 2.
Parce que le fait que j'ai donné mon mot de passe a débloqué le gestionnaire de mot de passe.
Il est très difficile voir impossible pour un composant (donc ici le gestionnaire de mot de passe), de distinguer qui l'appel (c'est l'extension A? B?).
Bon maintenant, je n'ai pas une connaissance assez approfondi du gestionnaire de mot de passe pour te dire ce qui est faisable ou pourquoi ça le fait exactement.
Oui, c'est ce qu'il faut. Mais apparemment, c'est à l'extension de le faire.
C'est que j'ai expliqué : c'est ce qu'il faudrait qu'elle fasse ! (au moins par elle-même)
# du RIA avec canvas ??
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Recherche désespérément framework pour application RIA HTML5 basées sur Canvas (et non le DOM). Évalué à 4.
J'ai du mal à comprendre ce que tu veux faire exactement. Tu veux faire une interface utilisateur avec canvas ?
Parce que si c'est le cas, canvas n'est pas fait pour ça.
[^] # Re: Gros trou de sécu
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Deux extensions originales pour Firefox. Évalué à 5.
ce trou existe avec l'extension.
Elle devrait redemander le mot de passe principal pour afficher les mots de passe. Actuellement, elle peut récupérer les mots de passe parce que j'ai déjà tapé mon mot de passe principal. Mais elle devrait redemander ce mot de passe pour afficher. Comme le fait le gestionnaire de mot de passe. Que tu ais déjà tapé ou non le mot de passe principal en début de session, le gestionnaire te redemande le mot de passe principal, pour s'assurer que c'est bien toi qui veut voir TES mots de passe (et pas un gars qui squate ton PC pendant une absence de quelques minutes par exemple).
# Gros trou de sécu
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Deux extensions originales pour Firefox. Évalué à 5. Dernière modification le 16 février 2012 à 10:22.
Aie aie aie.. Pour ceux qui ont un mot de passe principal, je vous recommande de désinstaller l'extension password reuse visualizer. Cette extension ne demande même pas le master password avant d'afficher les mots de passes, comme le fait le gestionnaire de mot de passe.
Pour moi, ça craint...
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.
pas du tout. Daniel n'a que peu d'influence sur les décisions de Mozilla depuis quelques années. Mozilla ne laisse pas mourrir XulRunner, pour la simple raison que Firefox est basé dessus. Mais Mozilla ne met plus en avant XulRunner, parce qu'ils ne veulent pas dépenser leur énergie sur ce projet en terme de dev, marketing et autre. S'occuper d'un produit de la nature de XulRunner, c'est s'occuper à essayer de résoudre toutes les problématiques des développeurs utilisant cette plateforme, problématiques qui ne rentreraient pas dans les objectifs actuels de Mozilla. Ils préfèrent se concentrer sur la plateforme purement web. Ils bossent ainsi sur la plateforme XUL, uniquement pour répondre à leurs besoins (à ceux de Firefox, TB et autres), et non aux besoins des autres.
Maintenant il y a pas mal de "cinglés" comme moi qui utilisent XulRunner et gecko pour leurs projets, parce qu'ils trouvent cette plateforme géniale malgré ses défauts.
De plus, vu que XulRunner n'est qu'un main() un poil différent de celui de firefox, et ne contient pas les fichiers XUL/JS/CSS de firefox (en gros), refaire un XulRunner ne serait pas compliqué. Le seul moyen pour Mozilla de tuer XulRunner, serait de tuer XUL et tout ce qui va avec (système d'overlay etc). Ce qui n'est pas près d'arriver...
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 3.
Certes. Mais tu t'embarques dans un truc pas adapté, donc qui te prend 10 fois plus de temps à réaliser que si tu utilisais des outils plus adaptés. C'est comme si tu utilisais un rateau pour faire un trou, alors que si tu utilisais une pelle, tu serais plus efficace.
En prenant un toolkit 100% C++ (puisqu'il semble que ce soit ton langage de prédilection), comme Qt, tu pourrais te concentrer plus sur les éléments de ton framework plutôt que sur des contournements de la plateforme...
Oui donc tu t'es trompé de plateforme à mon sens...
Si j'ai choisi XUL pour de nombreux développements (depuis des années), c'est bien pour le coté "web" de la plateforme (donc XML/XUL/CSS ET Javascript). Si je voulais faire une appli entièrement en C++, je ne choisirais certainement pas XULRunner...
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.
le fait que tu n'utilises plus JS enlève une grande partie de l'intérêt de la plateforme selon moi (dev rapide, maintenance et evolution plus aisées etc..)
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.
Donc tu passes 10 fois plus de temps à implémenter un truc (des listeners et autres trucs d'interface), pour un résultat qui n'apporte au final rien en terme de perf (au niveau de l'UI).
disclamer : je fais du xpcom c++ depuis des années...
moui ok, je comprend mieux le principe de ton truc. Mais quand même, comme je dis, ça n'apporte rien en terme de perf, au niveau de l'interface utilisateur, sauf si tu manipules à tour de bras des centaines d’éléments XUL. En tout cas le rapport (productivité, facilité de dev, de maintenance etc)/performance est très très faible.
Pourtant, tout est indiqué sur la doc de la balise tree, https://developer.mozilla.org/en/XUL/tree , en particulier les interfaces qu'elle utilise, et donc ses propriétés dont la view etc. Etant donné que les objets DOM accessibles en JS sont simplement un accés XPCom aux objets C++ correspondant... Et par le passé, XulPlanet.org était encore mieux documenté au niveau des interfaces etc..
Pour être plus productif ? Pour faciliter les contributions ? Pour avoir un outil plus performant ? pour avoir une interface web agréable à utiliser ? (le browser CVS est juste horrible).
M'enfin chacun utilise ce qu'il veut :-)
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à -5.
Je ne parles pas de QuickTime, mais de QT : http://en.wikipedia.org/wiki/Qt_%28framework%29
# Pourquoi pas un autre toolkit ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.
Le but de XulRunner n'est pas un framework/une plateforme pour écrire une appli entièrement en C++.
Pourquoi ne pas utiliser QT ou autre toolkit graphique ?? Parce que si dans ton projet, l'utilisation du JS est à proscrire, tu t'es, à mon avis, trompé de framework.
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal XULRunner et C++.. Évalué à 2.
oui, je me pose exactement la même question. D'après ce que j'ai compris, on n'a plus à utiliser de gestionnaire d'évènement ou autres trucs "webesque" de XulRunner. Et en gros, tout le code de l'appli est dans des libs externes en C/C++.
Et au final aussi, un truc à la XPCom à été recodé en passant par XPCom. Au final on a donc une couche qui transmet des appels vers les libs externe, donc comme XPCom. -> double couche logicielle pour accéder à la lib externe. à moins d'avoir rien compris au bidule :-)
Bon, sinon, de la doc sur XPCOM C++, elle existe quand même https://developer.mozilla.org/en/XPCOM. Et il y a aussi une alternative, pour accéder directement aux fonctions d'une lib : js-ctypes.
(hors sujet: CVS, c'est vraiment pénible, je recommande d'utiliser un gestionnaire de source récent :-p)
[^] # Re: français
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal qy.blog: l'auto hébergement de blog / site Internet à la maison. Évalué à 2.
et pour continuer dans le #fail, quietty.com n'est pas accessible depuis un navigateur web, alors que www.quietty.com, si. Une petite mise à jour DNS et config apache/nginx/autre s'impose ;-)
Bon sinon, l'idée du produit est intéressante. Par contre, il ne faudrait pas que le blog connaisse un succès fou, vu le peu de bande passante en upload qu'on a en ADSL en général.
Un jour peut être, les fournisseurs d’accès nous fournirons des débits symétriques...
[^] # Re: hum...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 6.
Oui il y a cette différence d'ouverture de source et de spec.
Mais il n'y a aucune différence quant à la situation et aux conséquences. Le problème se situe dans l'utilisation de propriété non standards ou experimentales. Tout comme avec IE6, les développeurs utilisent des fonctionnalités qui ne sont implémentées que dans un seul moteur de navigateur (ou qui ne sont interprétables que par un seul moteur de navigateur). Cela conduit donc à un web "optimisé pour", tout comme avec IE6. Le fait que lesdites fonctionnalités soient implémentées sous licence libre ou proprio ne change rien au problème, et encore moins à une éventuel solution. On assiste à nouveau à une balkanisation du web.
[^] # Re: Level : Asian
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Apple = Microsoft + Google. Évalué à 2.
indice. à 00:09, on était vendredi. Et vendredi, c'est le jour des ...
[^] # Re: Please fill out this field
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 3.
oui, c'est une bonne idée. Mais j'ai bien peur qu'il soit trop tard, vu apparemment les centaines de milliers de sites pour mobile qui ciblent webkit..
[^] # Re: Please fill out this field
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 10.
Oui. Tout comme les développeurs peuvent migrer leur code. Mais dans 99% des cas, ils ne le font pas. Parce qu'une fois le site développé, les "vieux" trucs restent. Et parfois très longtemps. Surtout quand ceux qui sont chargés de faire évoluer le site ne sont pas les développeurs initiaux. Il arrive trèèèèès souvent qu'ils ne touchent qu'à ce qu'il y a besoin d'être touché, par manque de temps, par peur de casser des choses, par j'm'enfoutisme etc..
Tu es à coté de la plaque. Les éditeurs implementent les trucs BIEN AVANT de proposer des specs au W3C. C'est pas le W3C qui "fournit".
Non, ce sont les développeurs web qui sont responsables. les propriétés prefixées sont pour la plupart des trucs experimentaux. LES DEVELOPPEURS NE SONT PAS CENSES LES UTILISER. Ou si ils les utilisent, qu'ils aient au moins le courage de mettre les propriétés préfixés pour les autres navigateurs ET de mettre celles sans prefixe, ceci afin de garantir un minimum que leur site fonctionnera PARTOUT et dans la durée.
Un développeur web est censé suivre les standards. C'est son job de faire en sorte que son site (public) soit lisible partout, parce que c'est la nature même du web d'être "agent agnostic". Ne pas le faire est une faute professionnelle selon moi. Ne pas le faire, c'est ne pas suivre les "rêgles" du WEB. Si on ne veut pas suivre ces rêgles, il faut changer de branche.
Imaginons qu'un navigateur X non basé sur webkit gagne énormément de part de marché pour X raisons, sur le mobile. Que va-t-il arrivé ? Plein de sites cassés. Parce que des développeurs incompétents n'auront pas fait leur job comme il faut, en utilisant des trucs prefixés ciblant un seul navigateur. Bref, des développeurs comme il y en avait au temps de IE6. Avec les conséquences que l'on connait.
[^] # Re: Please fill out this field
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 7. Dernière modification le 09 juillet 2020 à 19:35.
Un bel article pour mieux comprendre le problème
http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/NdM: lien cassé remplacé par https://www.wired.com/2012/02/webkit-isnt-breaking-the-web-you-are/