Greasemonkey: L'utilisateur doit pouvoir contrôler l'ordre d'exécution du script

Créé le 15 nov. 2017 · 10Commentaires · Source: greasemonkey/greasemonkey

Le tri "Ordre d'exécution" est la fonctionnalité qui me manque le plus dans la boîte de dialogue "Gérer" de l'ancien onglet complet.
Actuellement (dans GM 4.0), comme il semble, les scripts sont exécutés tels qu'ils sont répertoriés dans la fenêtre contextuelle, c'est-à-dire par ordre alphabétique.
Ce tri n'étant plus disponible, il n'y a plus de moyen rapide de résoudre les conflits de script utilisateur.

Pour référence, je cite la page wiki (maintenant supprimée)

_Ordre de script_
_Les scripts peuvent être affichés dans l'ordre par :_
_Status - Les scripts sont classés par statut d'activation : activé ou désactivé, puis nom._
_Nom - Les scripts sont classés par ordre alphabétique par nom, quel que soit leur statut._
_ Ordre d'exécution - Les scripts sont classés par index d'exécution._
_Ce dernier ordre est important pour les scripts utilisateurs qui entrent en conflit les uns avec les autres. En changeant l'ordre des scripts, le conflit peut être résolu. Vous pouvez modifier l'ordre en cliquant avec le bouton droit sur un script utilisateur et en choisissant l'une des actions : Execute first , Execute sooner , Execute later ou Execute last ._

Source

darkred

Commentaire le plus utile

C'est en effet une fonctionnalité de 3.x absente de 4.x.

Je ne vais certainement pas promettre de fonctionnalité/interface utilisateur particulière, mais pouvoir installer deux scripts devant s'exécuter dans un ordre particulier serait une bonne chose.

arantius le 15 nov. 2017

👍3

Tous les 10 commentaires

C'est en effet une fonctionnalité de 3.x absente de 4.x.

Je ne vais certainement pas promettre de fonctionnalité/interface utilisateur particulière, mais pouvoir installer deux scripts devant s'exécuter dans un ordre particulier serait une bonne chose.

arantius le 15 nov. 2017

👍3

Et si dans la source du script nous avions une fonctionnalité // <strong i="5">@priority</strong> (int) , ou peut-être devrions-nous l'appeler un niveau d'
chaque déchirure peut être démarrée à/presque en même temps via des fonctions asynchrones
nous devrions probablement aussi soutenir les valeurs négatives

GM-Script-Writer-62850 le 20 nov. 2017

Contrairement aux niveaux d'exécution UNIX, pour lesquels il existe une sorte d'ordre naturel, l'ordre d'exécution des scripts semble plus arbitraire. Je pense que cela devrait dépendre de l'utilisateur. Une priorité par défaut qui vient d'une balise dans le script n'est pas une mauvaise idée, mais il doit y avoir une possibilité de remplacer l'ordre, comme cela a été le cas dans les versions précédentes de GM.

tonycpsu le 20 nov. 2017

Je suis d'accord avec cela, mais nous pourrions modifier le niveau d'exécution/la priorité des scripts à partir de la source si besoin est ; je suppose que ce serait plus facile à mettre en œuvre, à quel point une interface utilisateur pourrait être construite autour de cela

GM-Script-Writer-62850 le 20 nov. 2017

Votez pour cela aussi. Certains de mes scripts doivent être exécutés dans un ordre particulier et s'interrompre s'ils ne sont pas exécutés à leur heure.
Je pense aussi que cela devrait être à l'utilisateur de décider de cette commande. L'interface utilisateur peut faire référence à une sorte de directive "order"/"runlevel" du script mais le dernier mot doit être celui de l'utilisateur. Je peux même imaginer une paire de scripts qui se comportent intentionnellement différemment lorsqu'ils sont exécutés 1st-2nd ou 2nd-1st, car les deux font référence au DOM de la page qui est modifié par eux.

Unchqua le 24 nov. 2017

À mon humble avis, un niveau d'exécution n'est pas ce dont nous avons besoin ici.
Je pense que, dans la plupart des cas, il s'agit simplement d'exécuter le script A avant le script B.
Il s'agit d'une restriction (relative). Le niveau d'exécution est une mesure absolue. Pas adéquat.
De plus, la restriction est assez clairsemée. Tout ce dont vous avez besoin, c'est du "plus tôt"/"plus tard",
et peut-être, juste pour le confort, "premier"/"dernier"...

Eselce le 24 nov. 2017

Ce n'est pas (strictement) une propriété du script lui-même, il ne devrait donc pas s'agir d'un en-tête @tag intégré dans la source. C'est un symptôme d'une combinaison de scripts dans laquelle les modifications de l'une interrompent l'autre (mais pas l'inverse), donc l'autre doit s'exécuter en premier.

arantius le 28 nov. 2017

Cette fonctionnalité sera-t-elle toujours d'actualité un jour ? Cela me manquait depuis la sortie de 4.x, et j'ai dû faire de mauvaises solutions de contournement dans mes scripts pour être exécutés dans le bon ordre pour le moment.

StrikeAgainst le 14 mai 2019

... quelques solutions de contournement médiocres ...

Quelle était la solution de contournement et pourquoi était-elle médiocre ?

arantius le 14 mai 2019

Je me souviens d'avoir créé un div invisible avec un script et d'avoir réglé une minuterie dans l'autre, pour vérifier si le div existait déjà. Ou était-ce stupide ?

Je ne pense pas que l'on puisse définir des variables globales avec Greasemonkey et les rendre accessibles par d'autres scripts ? Et même cela nécessiterait de régler une minuterie, n'est-ce pas ?