MountyZilla sur GitHub

Rokü a écrit:Sur Github, je déposerai uniquement les sources avec un beau README.md expliquant comment :
* Mettre en place un env de dev
** Téléchargement du SDK : https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/jetpack-sdk-latest.tar.gz
** Activation de l'env de dév : source bin/activate
* Charger l'add-on dans une session de dev FF : cfx run
* Compiler l'add-on : cfx xpi
* Liens vers de la documentation utile :
** https://developer.mozilla.org/en-US/Add-ons

Finalement, la version compilée est utile que pour les "utilisateurs". J'opterai pour un tag git à chaque fois que tu releases un xpi. C'est un bon compris. Qu'en penses-tu ?

Que j'ai rien compris. Première fois que j'entends parler de jetpack (et première fois aussi que j'entends l'acronyme SDK, mais ça j'ai pigé). J'ignorais totalement qu'il existait des outils automatisés pour monter des modules FF. MZ existait bien avant tout ça, donc si tu veux passer de la version actuelle vers ton jetpack là, il risque d'y avoir du boulot.

Rokü a écrit:Sinon, je ne comprends pas pourquoi le script principal charge les scripts depuis le site http://mountyzilla.tilk.info/scripts_0.9/. Les scripts devraient être directement dans l'add-on

Et donc à chaque fois que tu fais une mise à jour mineure, tu es obligé de refaire un paquet, de le mettre en ligne, de faire l'annonce de la release, et tout le monde est obligé de télécharger l'intégralité de l'extension. C'est un des gros avantages de MZ sur Chrall par exemple, il vient pas te prendre la tête tous les 3 jours pour télécharger une mise à jour.

Rokü a écrit:Pourquoi ne pas livrer l'add-on sur https://addons.mozilla.org/fr/firefox/ ? Cela permettra de s'appuyer sur le système de mise à jour de Mozilla. Non, qu'en penses-tu ?

Ce n'est pas le choix qu'a fait l'auteur de MountyZilla, et vu son niveau il était parfaitement conscient de ce qu'il faisait.

Rokü a écrit:Sinon, j'ai commencé à travailler sur MZ. J'ai tenté de réorganisé l'add-on comme je le pense histoire de te livrer un code source à relire. Toutefois, je me confronte à une difficulté un peu bête.

Code:

console.error: my-addon:
  Message: ReferenceError: MZ_getValue is not defined

J'ai cherché dans les scripts online, dans le script teubreu, dans le js de MH. Je ne l'ai pas trouvé. Je ne comprend pas. C'est quoi cette fonction ?

C'est l'équivalent du GM_getValue de GreaseMonkey, dont MZ est très largement inspiré. Les scripts online ne contiennent que des instructions pour traiter les pages de MH : fouiller dans le DOM, extraire des données, faire des calculs, réinjecter des données. Le coeur de l'add-on est contenu dans le jar du xpi. En l'occurence, MZ_getValue est définie dans mhOverlay :
xpi > chrome > mountyzilla.jar > content > mountyzilla > mountyhallOverlay.js

Code:

sandbox.MZ_getValue=mountyzilla_compiler.hitch(storage, "getValue");

Par contre je pourrai pas t'en dire plus. J'y connais pas grand chose en informatique, et le code du coeur de MZ est assez obscur pour moi. Par exemple je pige pas comment il est possible de définir deux méthodes de même clé "hitch" pour l'object mountyzilla_compiler, du coup je ne sais pas comment fonctionne la définition ci-dessus.

EDIT: si tu ne connais pas GM, GM_setValue et GM_getValue servent à écrire/lire des données dans le pref.js de Firefox (le about:config si tu préfères).

Dabihul a écrit:
Que j'ai rien compris. Première fois que j'entends parler de jetpack (et première fois aussi que j'entends l'acronyme SDK, mais ça j'ai pigé). J'ignorais totalement qu'il existait des outils automatisés pour monter des modules FF. MZ existait bien avant tout ça, donc si tu veux passer de la version actuelle vers ton jetpack là, il risque d'y avoir du boulot.

Je m'avance peut-être mais je ne pense pas que ce soit très compliqué ... je peux essayer

Dabihul a écrit:
Et donc à chaque fois que tu fais une mise à jour mineure, tu es obligé de refaire un paquet, de le mettre en ligne, de faire l'annonce de la release, et tout le monde est obligé de télécharger l'intégralité de l'extension. C'est un des gros avantages de MZ sur Chrall par exemple, il vient pas te prendre la tête tous les 3 jours pour télécharger une mise à jour.

Oui, c'est vrai que ça peut être vu comme une contrainte mais cela présente également beaucoup d'avantages :
* Tu ne dépends pas de la disponibilité du site http://mountyzilla.tilk.info/scripts_0.9/ car les scripts sont disponibles offline
* Tu n'as pas la problématique de cache navigateur que présente la récupération des scripts via HTTP
* Si tu t'appuies sur le système de MàJ des add-ons de FF, un simple upload sur le site et tu peux gérer : les versions de FF, la distribution de la MàJ, un CHANGELOG, ... et cela ne nécessite pas forcément un redémarrage du navigateur et est donc transparent pour les utilisateurs

Dabihul a écrit:
Ce n'est pas le choix qu'a fait l'auteur de MountyZilla, et vu son niveau il était parfaitement conscient de ce qu'il faisait.

Ok, ok ! Je me renseigne et je veux juste aider pour le plaisir. Mon idée ici n'est pas de critiquer qui que ce soit ou de venir mettre le bazar hein
Pour le coup, je trouvais beaucoup d'avantage à utiliser le gestionnaire centralisé de Mozilla.

Dabihul a écrit:
C'est l'équivalent du GM_getValue de GreaseMonkey, dont MZ est très largement inspiré. Les scripts online ne contiennent que des instructions pour traiter les pages de MH : fouiller dans le DOM, extraire des données, faire des calculs, réinjecter des données. Le coeur de l'add-on est contenu dans le jar du xpi. En l'occurence, MZ_getValue est définie dans mhOverlay :
xpi > chrome > mountyzilla.jar > content > mountyzilla > mountyhallOverlay.js

Ok, je comprends mieux ! Vu que j'étais parti sur un add-on from-scratch dans lequel j'avais inclu les scripts online, je ne disposais pas de cette dépendence.

Dabihul a écrit:

Code:

sandbox.MZ_getValue=mountyzilla_compiler.hitch(storage, "getValue");

Par contre je pourrai pas t'en dire plus. J'y connais pas grand chose en informatique, et le code du coeur de MZ est assez obscur pour moi. Par exemple je pige pas comment il est possible de définir deux méthodes de même clé "hitch" pour l'object mountyzilla_compiler, du coup je ne sais pas comment fonctionne la définition ci-dessus.

EDIT: si tu ne connais pas GM, GM_setValue et GM_getValue servent à écrire/lire des données dans le pref.js de Firefox (le about:config si tu préfères).

Je suis loin d'être un expert JS mais je pense que seul la seconde méthode est utile, la première est écrasée.
En faisant un petit test rapide :

Code:


var test = {
    hello: function(name) {
        alert("Hello, " + name);
    },
    hello: function(name) {
        alert("Hi, " + name);
    }
}

test.hello("Roku");


J'obtiens une alerte box qui m'affiche "Hi, Roku".

Je résume, tu proposes :
- un nouveau mode de développement (jetpack),
- un nouveau mode de fonctionnement (statique au lieu de distant),
- un nouveau serveur de màj (FF au lieu de MZ).

Pour le fonctionnement statique, je pense que c'est une connerie vue le nombre de (centaines de) fois où ça a déjà servi, mais bon je veux bien te faire confiance. (Si c'est la dispo du site qui t'inquiète, mz.info n'a jamais été down depuis que j'utilise MZ, ça fait 8 ans.)

Pour le reste, je vais aller me siroter un calvok et laisser faire le pro. J'aurais une requête tout de même : changer le nom de l'extension du coup, ça simplifiera la vie de ceux qui voudront migrer.

Meh. Je ne suis pas du tout un pro. Je découvre totalement l'add-on MZ et n'ai jamais fait d'extension pour FF.

C'est juste que j'essaye de m'y mettre pour contribuer un peu. Dans toutes mes propositions et/ou questions, c'est juste de la curiosité et de la discussion par rapport à ce que je découvre au fur et à mesure.

Je sent que je t'ai vexé mais sincèrement ce n'était pas mon but et tu m'en vois désolé

Je suis pas vexé, ou du moins ce n'est pas de ton fait. J'essaie juste de prévoir le temps qu'il va falloir investir pour assimiler tous ces changements, et j'avoue que ça commence à me faire un peu peur. Si ton oeil de pro te dit que ce sont les bons choix à faire, allons-y on fonce, par contre dis-toi que de mon côté il me faudra pas juste 2-3 semaines pour m'y mettre.
Pour situer mon niveau, imagine que quand j'ai repris MZ il y a presque deux ans maintenant, je ne savais pas ce qu'était le JavaScript, une requête serveur ou comment diable pouvait fonctionner Firefox (ni aucun logiciel graphique, d'ailleurs).

Pour GitHub j'ai mis un sérieux coup de collier pour me mettre à niveau, ça m'a englouti un nombre conséquent d'heures, je sais pas trop si je pourrais refaire ça. Comme j'ai pas les bases, à chaque fois que j'apprends "juste un petit truc" en fait il faut que j'engouffre aussi tous les prérequis, et c'est long.

Le truc qui m'agace c'est que je pensais naïvement pouvoir revoir le module interne et lancer une nouvelle version propre dans les 6 mois, mais je me rends compte que c'était totalement utopique. J'ai déjà passé pas mal de temps à essayer de décrypter la doc à tiroirs de MDN sur les extensions FF "classiques avec overlay" et vu que c'était super pénible, je préfère te laisser gérer la version jetpack. (C'est un peu salaud j'avoue, mais l'alternative c'est que tu attendes 8-10 mois que je lise tout ça petits bouts par petits bouts.)

Et pour le changement de nom c'est pas une boutade c'est très sérieux, si tu essaies d'expliquer à un millier de trõlls que MZ s'appelle encore MZ et qu'il fonctionnera pareil mais que c'est une extension différente, ça va faire claquer un certain nombre de neurones ^^

Ouf, tu m'en vois rassuré, je n'ai aucunement l'envie de me mettre mon Chef de guilde sur le dos, hein.

Non mais en fait je me suis enflammé sur les échanges et propositions d'évolutions car à la vitesse où je t'ai vu maitriser git je me suis dit que c'était ton métier le développement !

Le fait que tu souhaites me laisser la version jetpack n'est pas du tout salaud, c'est ça une communauté open-source. Ce sont des gens qui s'appuient les uns sur les autres pour développer un produit dont ils ont besoins et qui le font évoluer en fonction de leur envie et temps libre.

Je ne l'avais pas vu sous cette angle pour la version jetpack hébergé par Mozilla. Mais tu as raison, cela risque de dérouter beaucoup trop d'utilisateurs. On se choisit un nom de code sympa pour cette version que je vais essayer de mettre en place avec la documentation qui va bien ?

Ma spécialité c'est plus les maths théoriques, on a assez peu de rapport avec les informaticiens (quand on en a c'est pour parler d'algorithmes du genre Dijkstra ou Reed-Solomon).

Pour le projet que penses-tu de TrollZilla ? ou CaveZilla ?

Ok, on va pouvoir se compléter alors car les maths c'est pas mon dada !

J'aime bien TrollZilla

Ah bah bravo. Comment ça donne trop envie d'être développeur ça...

Pour info, j'ai fini d'apprendre tout ce que je voulais en php/MySQL. Mon mountyhall local est devenu dynamique, géré via des BDD alimentés automatiquement par les diverses pages que je visite.

Rokü tu as avancé de ton côté avec JetPack et TrollZilla ?

Vu que le coeur de MZ est appelé à être réécrit, j'ai commencé à travailler en JetPack. À mon avis ce SDK est principalement une bibliothèque de gadgets pour interagir avec le chrome de FF. Sur le fond, niveau sécurisation de MZ (rappel: MZ est une plateforme pour développeurs puisqu'elle accepte des scripts externes, elle doit donc être convenablement sécurisée) et fonctionnalités In Game, ça m'a pas l'air d'être un gros gain.

En revanche niveau quantité de doc à jour disponible, c'est nettement mieux. À voir si JetPack est un environnement suffisant pour développer une unise à gaz comme MZ. (J'ai quelques doutes.)