Mudlet: Suporte telnet: // links

Muitos dos MUDs que estou vendo os usam. Vou compilar uma lista aqui, então temos um monte de links para verificar:

http://www.durismud.com/

Windows: parece que você precisa principalmente do instalador para inserir algo no registro. Consulte https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767914 (v = vs.85)
Linux:?
Mac OS: ?

Não tenho certeza do que acontece no Mudlet depois de clicar no link, em relação aos perfis do Mudlet.

Sim. Se alguém pudesse ajudar a projetar como isso deveria funcionar, seria de grande ajuda! Não precisa codificá-lo.

@Kebap Não tenho certeza se este é específico apenas para ubuntu / gnome e também pode ser usado pelo kde ..

Manipulador de URL para linux

Portanto, vamos supor por um segundo que realmente tenhamos sucesso em todos os sistemas operacionais, e Mudlet saberá quando um usuário clicar em um link telnet.

Agora, o que Mudlet deve fazer exatamente? Aqui está uma proposta de design:

Perguntas abertas:

• Você concorda em lidar com os diferentes casos quando um ou mais perfis forem encontrados?
• Existem casos ainda mais relevantes para verificar, que eu não incluí?
• Os links telnet também podem conter nome de usuário e senha, como links mailto ou ssh?
• Precisamos da opção de desativar o Mudlet que captura todos os links telnet, se os usuários quiserem abrir links via telnet sem Mudlet também?

Você pode editar e desenvolver esta proposta online aqui (sem necessidade de registro)

Que tal uma pergunta sobre a inicialização do Mudlet para plataformas suportadas, como "Você gostaria que o Mudlet fosse seu cliente telnet padrão? Telnet é o protocolo mais comum para se conectar a jogos através do Mudlet." Cancelar | Sim como opções. Pergunte apenas na primeira inicialização por versão, talvez? Adicionar alguma forma de pop-up nos menus? Idéias para moldar aqui.

-Tamarindo

Eu concordo com Tamarindo sobre deixar o aplicativo Mudlet principal definir o manipulador de esquema de URI por dois motivos:

• Temos versões sem instalador do Mudlet (Linux AppImage, macOS .dmg) e fazer com que o instalador do Windows execute etapas adicionais também pode ser doloroso.
• Se o usuário definir um programa diferente para lidar com links telnet, ele não terá uma maneira fácil de defini-lo de volta para Mudlet.

Precisamos renovar a manipulação de argumentos de linha de comando para fornecer um mecanismo para aceitar os seguintes argumentos para fazer este trabalho, eu acho - então, além dos argumentos limitados atuais (os do QT e -h / --help , -v / --version e -q / --quiet ) Acho que precisamos lidar com argumentos adicionais:

• um URL de servidor
• um número de porta (padrão para 23 se omitido)
• um nome de perfil (opcional) - que é de uso limitado na resolução de telnet:// URLS de esquema, mas ajudaria, talvez criando atalhos de desktop em vários sistemas operacionais.
• um nome de caractere (opcional) para usar - novamente, apenas realmente útil para criar um atalho na área de trabalho para um perfil favorito (lidar com uma senha na linha de comando é estranho, pois provavelmente será legível através de processos de visão geral do sistema - por exemplo, top em * nixes)
• um booleano ou algo assim para lidar com as conexões SSL recém-adicionadas
• um booleano ou algo para permitir a integração do Discord com o perfil novo / selecionado
• um Booleano para suprimir o carregamento automático de perfis que já estão marcados para carregamento automático - atualmente o carregamento automático acontece, bem automaticamente, mas pode haver ocasiões (como resolver um URL de esquema telnet:// ) em que isso não é desejado

Todos, exceto o último, devem ser permitidos várias vezes para permitir que vários perfis sejam iniciados - talvez usando o servidor como delimitador para todos os argumentos que o seguem até que outro servidor seja encontrado na linha de comando ...

O que é a seção 'revisar todos os perfis'? Isso encapsula a lógica que é mostrada depois ou é uma etapa prévia separada?

É suposto encapsular e significar: Faça esta lógica repetidamente uma vez para cada perfil listado

Gosto muito, aqui está a minha revisão:

Retirei o tratamento separado no caso de um usuário já ter um nome de usuário - acho que _devemos_ conectar com o perfil exclusivo. Se tiver um nome de usuário, significa apenas que a pessoa pode fazer o login imediatamente e está familiarizada com o jogo.

Quanto a alimentar as informações do sistema operacional na chamada para iniciar / conectar com Mudlet, acho que deve lidar com o host / porta ou um nome de perfil - o caso e não vai realmente ser útil porque se você tiver o último, o primeiro é redundante ...

Oh, como evitamos que o usuário tenha várias instâncias do Mudlet em execução ao mesmo tempo - de modo que não geremos uma segunda instância se já houver uma aberta - em um sistema operacional independente e outros usuários no mesmo sistema - de maneira?

Sinto como se estivéssemos prestes a ser atropelados por um: bus: possivelmente o QtDBus ...

: wave: voltando a isso, muitos outros trabalhos estão aguardando revisões.

@Kebap, qual é a sua opinião sobre meu https://github.com/Mudlet/Mudlet/issues/689#issuecomment -455272369 simplificado? Acho que será uma experiência de usuário mais perfeita, porque menos atrapalhará o seu jogo.

Você concorda em lidar com os diferentes casos quando um ou mais perfis forem encontrados?

Em geral, sim, consulte a revisão acima. Qual é a sua opinião sobre isso?

Existem casos ainda mais relevantes para verificar, que eu não incluí?

Acho que são todos eles: +1:

Os links telnet também podem conter nome de usuário e senha, como links mailto ou ssh?

Parece que sim! https://tools.ietf.org/html/rfc4248 Podemos oferecer suporte.

Precisamos da opção de desativar o Mudlet que captura todos os links telnet, se os usuários quiserem abrir links via telnet sem Mudlet também?

Sim...

https://github.com/Mudlet/Mudlet/issues/689#issuecomment -455171499: Vejo o que você está dizendo, mas olhando para o RFC, não acho que nenhuma das sugestões se aplique a _esta_ melhoria específica - ao invés de você mencionou, é muito mais adequado para atalhos de desktop e tal.

Existem casos ainda mais relevantes para verificar, que eu não incluí?

Atualize quando comecei a trabalhar nisso: isso não leva em consideração o que fazer quando um perfil é configurado para carregamento automático, onde, nesse caso, não há necessidade de incomodar o usuário com uma caixa de diálogo de conexão ...: pensando:

Sua revisão parece justa. Sempre podemos adicionar aquele portal que você removeu se surgir um desejo maior ...

Se o autoload estiver ativado, não acho que esperaria um resultado diferente ao clicar em um link específico. O carregamento automático provavelmente deve ser ignorado nesse caso. Somente se Mudlet for invocado sem clicar em telnet: // em qualquer lugar, o autoload deve ser respeitado.

Sim.

Fiz um bom progresso nisso, mas fiquei preso - se bem me lembro - realmente registrando Mudlet como um gerenciador de aplicativos. Não está muito claro como fazer isso no macOS e no Windows, então, se alguém tiver etapas concretas que funcionem, adoraria ajudar.

Achei esses resumos de 16 de novembro. Testar no Win 10 parece legítimo. Também há Mac e Linux:
https://support.shotgunsoftware.com/hc/en-us/articles/219031308-Launching-applications-using-custom-browser-protocols
Eles falam sobre como adicionar um novo manipulador, mas você precisaria inspecionar e atualizar o manipulador telnet existente.

Muito obrigado! Vou dar uma olhada.