Mudlet: Prise en charge des liens telnet://

Un bon nombre des MUD que je vois les utilisent. Nous allons compiler une liste ici, nous avons donc un tas de liens à vérifier:

http://www.durismud.com/

Windows : il semble que vous ayez surtout besoin du programme d'installation pour insérer quelque chose dans le registre. Voir https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767914 (v = vs.85)
Linux:?
MacOS:?

Je ne sais pas ce qui se passe dans Mudlet après avoir cliqué sur le lien, en ce qui concerne les profils Mudlet.

Ouais. Si quelqu'un pouvait aider à concevoir comment cela devrait fonctionner, ce serait d'une grande aide ! Pas besoin de le coder.

@Kebap Je ne sais pas si celui-ci est particulier uniquement pour ubuntu / gnome et peut également être utilisé par kde ..

Gestionnaire d'URL pour Linux

Alors, supposons juste une seconde, nous réussissons effectivement sur tous les systèmes d'exploitation, et Mudlet saura quand un utilisateur cliquera sur un lien telnet.

Maintenant, que doit faire exactement Mudlet? Voici une proposition de design:

Questions ouvertes:

• Êtes-vous d'accord pour gérer les différents cas lorsqu'un ou plusieurs profils sont trouvés?
• Y a-t-il peut-être des cas encore plus pertinents à vérifier, que je n'ai pas inclus?
• Les liens telnet peuvent-ils également contenir un nom d'utilisateur et un mot de passe comme des liens mailto ou ssh ?
• Avons-nous besoin d'une option pour désactiver la capture de tous les liens telnet par Mudlet, si les utilisateurs souhaitent également ouvrir des liens via telnet sans Mudlet?

Vous pouvez modifier et développer cette proposition en ligne ici (aucune inscription nécessaire)

Que diriez-vous d'une question sur le démarrage de Mudlet pour les plates-formes prises en charge comme « Voulez-vous que Mudlet soit votre client telnet par défaut ? Telnet est le protocole le plus courant pour se connecter aux jeux via Mudlet ». Annuler | Oui en option. Ne demandez peut-être qu'au premier démarrage par version? Ajouter un moyen de pop-up dans les menus? Des idées à mouler ici.

-Tamarindo

Je suis d'accord avec Tamarindo sur le fait de laisser l'application Mudlet principale définir le gestionnaire de schéma d'URI pour deux raisons:

• Nous avons des versions sans programme d'installation de Mudlet (Linux AppImage, macOS .dmg) et demander à notre programme d'installation de Windows d'effectuer des étapes supplémentaires peut également être pénible.
• Si l'utilisateur définit un programme différent pour gérer les liens telnet, il n'a aucun moyen simple de le remettre à Mudlet.

Nous devons réorganiser la gestion des arguments de ligne de commande pour fournir un mécanisme permettant d'accepter les arguments suivants pour que cela fonctionne, je pense - donc, en plus des arguments limités actuels (ceux de QT et -h / --help , -v / --version et -q / --quiet ) Je pense que nous devons gérer des arguments supplémentaires:

• une URL de serveur
• un numéro de port (par défaut à 23 si omis)
• un nom de profil (facultatif) - qui est d'une utilité limitée dans la résolution des URL de schéma telnet:// mais qui aiderait, peut-être à créer des raccourcis Bureau sur plusieurs OS.
• un nom de caractère (facultatif) à utiliser - encore une fois, seulement vraiment utile pour créer un raccourci sur le bureau vers un profil favori (la gestion d'un mot de passe sur la ligne de commande est cependant difficile, car il sera probablement lisible via les processus de présentation du système - par exemple top sur * nixes)
• un booléen ou quelque chose pour gérer les connexions SSL nouvellement ajoutées
• un booléen ou quelque chose pour activer l'intégration Discord avec le profil nouveau/sélectionné
• un booléen pour supprimer le chargement automatique des profils qui sont déjà marqués pour le chargement automatique - actuellement, le chargement automatique se produit, bien automatiquement, mais il peut y avoir des occasions (comme la résolution d'une URL de schéma telnet:// ) où cela n'est pas souhaité

Tous sauf le dernier devraient être autorisés plusieurs fois pour permettre le démarrage de plusieurs profils - peut-être en utilisant le serveur comme délimiteur pour tous les arguments qui le suivent jusqu'à ce qu'un autre serveur soit rencontré sur la ligne de commande ...

Qu'est-ce que la section «Examiner tous les profils»? Est-ce que cela résume la logique qui est montrée après, ou est-ce une étape préparatoire distincte?

Il est censé encapsuler et signifier: faites cette logique à plusieurs reprises une fois pour chaque profil répertorié

J'aime beaucoup, voici ma révision :

J'ai supprimé la gestion séparée au cas où un utilisateur aurait déjà un nom d'utilisateur - je pense que nous devrions nous connecter avec le profil unique. S'il a un nom d'utilisateur, cela signifie simplement que la personne peut se connecter immédiatement et se familiariser avec le jeu.

En ce qui concerne l'alimentation des informations du système d'exploitation dans l'appel pour démarrer / se connecter avec Mudlet, je suppose qu'il devrait gérer soit l'hôte / port, soit un nom de profil - le cas et ne sera pas vraiment utile car si vous avez le dernier, le premier est redondant ...

Oh, comment pouvons-nous empêcher l'utilisateur de faire fonctionner plusieurs instances de Mudlet en même temps - afin de ne pas générer une deuxième instance s'il y en a déjà une ouverte - dans un système d'exploitation indépendant et d'autres utilisateurs sur le même système?

J'ai l'impression que nous sommes sur le point d'être écrasés par un: bus: peut-être le

:wave: y revenir car beaucoup d'autres travaux attendent des critiques.

@Kebap quel est votre avis sur mon simplifié https://github.com/Mudlet/Mudlet/issues/689#issuecomment -455272369 ? Je pense que ce sera une expérience utilisateur plus transparente, car moins vous empêchera de jouer réellement.

Êtes-vous d'accord pour gérer les différents cas lorsqu'un ou plusieurs profils sont trouvés?

En général oui, voir la révision ci-dessus. Quelle est votre opinion là-dessus?

Y a-t-il peut-être des cas encore plus pertinents à vérifier, que je n'ai pas inclus?

Je pense que c'est tout :+1:

Les liens telnet peuvent-ils également contenir un nom d'utilisateur et un mot de passe comme des liens mailto ou ssh ?

Il semblerait que oui! https://tools.ietf.org/html/rfc4248 Nous pouvons le soutenir.

Avons-nous besoin d'une option pour désactiver la capture de tous les liens telnet par Mudlet, si les utilisateurs souhaitent également ouvrir des liens via telnet sans Mudlet?

Oui...

https://github.com/Mudlet/Mudlet/issues/689#issuecomment -455171499 : je vois ce que vous dites, mais en regardant la RFC, je ne pense pas qu'aucune des suggestions ne s'applique à _cette_ amélioration spécifique - plutôt que vous mentionnez, il est beaucoup plus adapté aux raccourcis de bureau et autres.

Y a-t-il peut-être des cas encore plus pertinents à vérifier, que je n'ai pas inclus?

Mettez à jour au fur et à mesure que j'ai commencé à travailler dessus : cela ne tient pas compte de ce qu'il faut faire lorsqu'un profil est configuré pour le chargement automatique, où dans ce cas il n'est pas nécessaire de déranger l'utilisateur avec une boîte de dialogue de connexion...

Votre révision semble juste. Nous pouvons toujours ajouter cette passerelle que vous avez supprimée si un désir accru se fait sentir...

Si le chargement automatique est activé, je ne pense pas que j'attendrais un résultat différent en cliquant sur un lien spécifique. Le chargement automatique devrait probablement être ignoré dans ce cas. Ce n'est que si Mudlet est invoqué sans cliquer sur telnet:// n'importe où, alors le chargement automatique doit être respecté.

Oui.

J'ai bien progressé sur ce point, mais je suis resté bloqué - si je me souviens bien - en enregistrant Mudlet en tant que gestionnaire d'application. On ne sait pas très bien comment faire cela sous macOS et Windows, donc si quelqu'un a des étapes concrètes qui fonctionnent, j'aimerais beaucoup d'aide à ce sujet.

J'ai trouvé ces résumés du 16 novembre. Les tests sur Win 10 semblent légitimes. Il y a aussi Mac et Linux:
https://support.shotgunsoftware.com/hc/en-us/articles/219031308-Launching-applications-using-custom-browser-protocols
Ils parlent d'ajouter un nouveau gestionnaire, mais vous devrez plutôt inspecter et mettre à jour le gestionnaire telnet existant.

Merci beaucoup! Je vais regarder.