Mudlet: Поддержка ссылок telnet: //

Многие из MUD, которые я вижу, используют их. Здесь мы собираемся составить список, чтобы у нас было несколько ссылок для проверки:

http://www.durismud.com/

Windows: Похоже, вам в основном нужен установщик, чтобы что-то вставить в реестр. См. Https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767914 (v = vs.85)
Linux:?
MacOS:?

Не уверены, что происходит в Mudlet после нажатия на ссылку в отношении профилей Mudlet.

Ага. Если бы кто-то мог помочь спроектировать, как это должно работать, это было бы большим подспорьем! Не нужно его кодировать.

@Kebap Я не уверен, подходит ли он только для ubuntu / gnome и может быть использован kde ..

Обработчик URL для Linux

Итак, давайте просто предположим на секунду, что мы действительно преуспеваем во всех операционных системах, и Mudlet будет знать, когда пользователь щелкает ссылку telnet.

Что именно должен делать Мадлет? Вот проектное предложение:

Открытые вопросы:

• Согласны ли вы обрабатывать различные случаи, когда обнаруживаются один или несколько профилей?
• Может быть, нужно проверить еще более важные дела, которые я не включил?
• Могут ли ссылки telnet также содержать имя пользователя и пароль, например ссылки mailto или ssh?
• Нужна ли нам опция, чтобы запретить Mudlet захватывать все ссылки telnet, если пользователи хотят открывать ссылки через telnet без Mudlet?

Вы можете редактировать и дополнять это предложение онлайн здесь (регистрация не требуется)

Как насчет вопроса о запуске Mudlet для поддерживаемых платформ, например: «Хотите, чтобы Mudlet был вашим клиентом Telnet по умолчанию? Telnet - это наиболее распространенный протокол для подключения к играм через Mudlet». Отмена | Да как варианты. Возможно, спрашивать только при первом запуске для каждой версии? Добавить способ отображения всплывающих окон в меню? Идеи лепить здесь.

-Тамариндо

Я согласен с Тамариндо в том, чтобы разрешить основному приложению Mudlet устанавливать обработчик схемы URI по двум причинам:

• У нас есть версии Mudlet без установщика (Linux AppImage, macOS .dmg), и заставить наш установщик Windows выполнять дополнительные действия также может быть болезненно.
• Если пользователь установил другую программу для обработки ссылок Telnet, у него не будет простого способа вернуть ее в Mudlet.

Нам действительно необходимо переделать обработку аргументов командной строки, чтобы обеспечить механизм для принятия следующих аргументов, чтобы заставить эту работу работать, я думаю - так что, в дополнение к текущим ограниченным аргументам (аргументам QT и -h / --help , -v / --version и -q / --quiet ) Думаю, нам нужно обработать дополнительные аргументы:

• URL-адрес сервера
• номер порта (по умолчанию 23, если не указан)
• (необязательно) имя профиля - которое имеет ограниченное применение при разрешении URL-адресов схемы telnet:// , но может помочь, возможно, при создании ярлыков на рабочем столе в нескольких ОС.
• (необязательное) имя символа для использования - опять же, действительно полезно только для создания ярлыка на рабочем столе для избранного профиля (однако обработка пароля в командной строке неудобна, поскольку его, вероятно, можно будет прочитать через процессы обзора системы - например, top на * nixes)
• логическое значение или что-то в этом роде для обработки недавно добавленных SSL-соединений
• логическое значение или что-то еще, чтобы включить интеграцию Discord с новым / выбранным профилем
• логическое значение для подавления автоматической загрузки профилей, которые уже помечены для автозагрузки - в настоящее время автозагрузка происходит, хорошо автоматически, но могут быть случаи (например, разрешение URL-адреса схемы telnet:// ), когда это не требуется

Все, кроме последнего, должны быть разрешены несколько раз, чтобы разрешить запуск нескольких профилей - возможно, используя один сервер в качестве разделителя для всех аргументов, следующих за ним, пока другой сервер не встретится в командной строке ...

Что такое раздел "просмотреть все профили"? Инкапсулирует ли это логику, показанную после, или это отдельный предварительный шаг?

Предполагается, что он инкапсулирует и означает: повторяйте эту логику один раз для каждого перечисленного профиля.

Очень нравится, вот моя доработка:

Я убрал отдельную обработку на случай, если у пользователя уже есть имя пользователя - я думаю, что мы _должны_ подключаться к уникальному профилю. Если у него есть имя пользователя, это просто означает, что человек может сразу войти в систему и знаком с игрой.

Что касается подачи информации от операционной системы в вызов , чтобы начать / соединиться с Mudlet я думаю , он должен обрабатывать либо хост / порт или имя профиля - и дело на самом деле не будет полезно , потому что если у вас есть последние бывшие избыточно ...

О, как мы можем предотвратить одновременное выполнение пользователем нескольких экземпляров Mudlet - чтобы мы не создавали второй экземпляр, если он уже открыт - независимо от ОС и других пользователей в той же системе?

Я чувствую, что нас вот-вот сбьет : bus: возможно,

: wave: возвращаясь к этому, так как многие другие работы ждут обзоров.

@Kebap, как вы относитесь к моему упрощенному https://github.com/Mudlet/Mudlet/issues/689#issuecomment -455272369? Я думаю, что это будет более плавный пользовательский интерфейс, потому что меньше будет мешать вам на самом деле играть.

Согласны ли вы обрабатывать различные случаи, когда обнаруживаются один или несколько профилей?

В общем да, см. Ревизию выше. Что ты думаешь об этом?

Может быть, нужно проверить еще более важные дела, которые я не включил?

Думаю, это все: +1:

Могут ли ссылки telnet также содержать имя пользователя и пароль, например ссылки mailto или ssh?

Казалось бы, да! https://tools.ietf.org/html/rfc4248 Мы можем это поддержать.

Нужна ли нам опция, чтобы запретить Mudlet захватывать все ссылки telnet, если пользователи хотят открывать ссылки через telnet без Mudlet?

Ага...

https://github.com/Mudlet/Mudlet/issues/689#issuecomment -455171499: Я понимаю, что вы говорите, но, глядя на RFC, я не думаю, что какие-либо из предложений относятся к этому конкретному улучшению - скорее, как Вы упомянули, что он больше подходит для ярлыков на рабочем столе и тому подобного.

Может быть, нужно проверить еще более важные дела, которые я не включил?

Обновите, когда я начал работать над этим: здесь не учитывается, что делать, когда профиль настроен для автоматической загрузки, где в этом случае нет необходимости беспокоить пользователя диалоговым окном подключения ...

Ваша доработка кажется справедливой. Мы всегда можем добавить этот шлюз, который вы удалили, если возникнет повышенное желание ...

Если автозагрузка активирована, не думаю, что я ожидал бы другого результата от нажатия на конкретную ссылку. В этом случае автозагрузку, вероятно, следует игнорировать. Только если Mudlet вызывается без щелчка по telnet: // в любом месте, тогда автозагрузка должна выполняться.

Ага.

Я добился хороших успехов в этом, но я застрял - если я правильно помню - на самом деле зарегистрировал Mudlet как обработчик приложения. Совершенно неясно, как это сделать в macOS и Windows, поэтому, если у кого-то есть конкретные шаги, которые работают, мне бы очень хотелось помочь в этом.

Я нашел эти сводки от 16 ноября. Тестирование на Win 10 кажется законным. Также есть Mac и Linux:
https://support.shotgunsoftware.com/hc/en-us/articles/219031308-Launching-applications-using-custom-browser-protocols
Они говорят о добавлении нового обработчика, но вместо этого вам нужно будет проверить и обновить существующий обработчик telnet.

Большое спасибо! Я посмотрю.