Quite a few of the MUDs I'm seeing use them. Going to compile a list here so we've got a bunch of links to check against:

http://www.durismud.com/

Windows: Looks like you mostly need the installer to insert something into the registry. See https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767914(v=vs.85)
Linux: ?
MacOS: ?

Unsure what happens in Mudlet after clicking the link, in regards to Mudlet profiles.

Yep. If someone could help design how this should work, that'd be a big help! Don't have to code it.

@Kebap I'm not sure if this one is particular only for ubuntu/gnome and can be used by kde as well..

URL handler for linux

So, let's just assume for a second, we do indeed succeed on all operating systems, and Mudlet will know when a user clicks a telnet link.

Now what should Mudlet do exactly? Here is a design proposal:

Open questions:

• Do you agree on handling the different cases when one or more profiles are found?
• Are there maybe even more relevant cases to check for, which I did not include?
• Can telnet links also contain user name and password like mailto or ssh links?
• Do we need option to disable Mudlet grabbing all telnet links, if users want to open links via telnet without Mudlet as well?

You can edit and build on top of this proposal online here (no registration needed)

How about a question on startup of Mudlet for supported platforms like "Would you like Mudlet to be your default telnet client? Telnet is the most common protocol to connect to games through Mudlet." Cancel | Yes as options. Only ask on the first startup per version perhaps? Add some way to pop-up in the menus? Ideas to mold here.

-Tamarindo

I agree with Tamarindo about letting the main Mudlet application set the URI scheme handler for two reasons:

• We have installer-less versions of Mudlet (Linux AppImage, macOS .dmg) and making our windows installer do additional steps might be painful as well.
• If the user set a different program to handle telnet links, they have no easy way to set it back to Mudlet.

We do need to revamp the command line argument handling to provide a mechanism to accept the following arguments to make this work I think - so, in addition to the current limited arguments (the QT ones and -h/--help, -v/--version and -q/--quiet) I think we need to handle additional arguments:

• a server URL
• a port number (default to 23 if omitted)
• an (optional) profile name - which is of limited use in resolving telnet:// scheme URLS but would help in, perhaps creating Desktop shortcuts on several OSes.
• an (optional) character name to use - again, only really useful for creating a Desktop shortcut to a favourite profile (handling a password on the command line is awkward though, as it will likely be readable via system overview processes - e.g. top on *nixes)
• a Boolean or something to handled the newly added SSL connections
• a Boolean or something to enabled the Discord integration with the new/selected profile
• a Boolean to suppress the automatic loading of profiles that are already marked to auto-load - currently autoloading happens, well automatically but there may be occasions (like resolving a telnet:// scheme URL) where this is not wanted

All but the last one ought to be allow multiple times to allow multiple profiles to be started - perhaps using the Server one as the delimiter for all the arguments following it until another Server one is encounter on the command line...

What is the 'review all profiles' section? Does that encapsulate the logic that's shown after, or is it a separe pre-step?

It is supposed to encapsulate and mean: Do this logic repeatedly once for every profile listed

I like it a lot, here's my revision:

I took out the separate handling in case a user already has a username - I think we should connect with the unique profile. If it has a username, it just means the person can login right away and are familiar with the game.

As for feeding the information from the OS into the call to start/connect with Mudlet I guess it should handle either the host/port or a profile name - the and case is not actually going to be helpful because if you have the latter the former is redundant...

Oh, how do we prevent the user from having multiple instances of Mudlet running at the same time - so that we do not spawn a second instance if there is one already open - in an OS independent and other users on same system - manner?

I feel as though we are about to be run down by a 🚌 possibly the QtDBus...

👋 getting back to this as a lot of other work is waiting reviews.

@Kebap what is your take on my simplified #689 (comment) ? I think it'll be a more seamless user experience because less will get in the way of you actually playing.

Do you agree on handling the different cases when one or more profiles are found?

In general yes, see revision above. What's your take on it?

Are there maybe even more relevant cases to check for, which I did not include?

I think that is all of them 👍

Can telnet links also contain user name and password like mailto or ssh links?

It would seem yes! https://tools.ietf.org/html/rfc4248 We can support it.

Do we need option to disable Mudlet grabbing all telnet links, if users want to open links via telnet without Mudlet as well?

Yeah...

#689 (comment): I see what you're saying but looking at the RFC, I don't think any of the suggestions apply to this specific improvement - rather as you mention, it's much more suited for desktop shortcuts and such.

Are there maybe even more relevant cases to check for, which I did not include?

Update as I started working on this: this doesn't consider what to do when a profile is setup for auto-load, where in that case there's no need to bother the user with a connection dialog... 🤔

Your revision seems fair. We can always add that gateway you removed if an increased desire arises...

If autoload is activated, I don't think I would expect a different result from clicking on a specific link. Autoload should probably be ignored in that case. Only if Mudlet is invoked without clicking telnet:// anywhere, then autoload should be honored.

Yeah.

I've made good progress on this, but I got stuck on - if I remember right - actually registering Mudlet as an application handler. It's super unclear on how to do that in macOS and Windows, so if anyone has concrete steps that work, I'd love help in this.

I found these summaries from Nov 16. Testing on Win 10 seems legit. There's also Mac and Linux:
https://support.shotgunsoftware.com/hc/en-us/articles/219031308-Launching-applications-using-custom-browser-protocols
They talk about adding a new handler, but you would need to inspect and update the existing telnet handler instead.

Thanks a lot! I'll have a look.

/bounty $200

💎 $200 bounty • Mudlet

🔨 See instructions for compiling Mudlet

Steps to solve:

1. Start working: Comment /attempt #689 with your implementation plan
2. Submit work: Create a pull request including /claim #689 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to Mudlet/Mudlet!

Add a bounty • Share on socials

Have a look at #3131 for some prior art / inspiration for this.

/attempt #689

💡 @guhitb submitted a pull request that claims the bounty. You can visit your bounty board to reward.