Add `telnet://` URI scheme support for one-click MUD connections by Excellencedev · Pull Request #8601 · Mudlet/Mudlet

Excellencedev · 2025-11-30T06:01:22Z

Brief overview of PR changes/additions

Summary

Implements full support for telnet:// links in Mudlet, allowing users to connect to MUD servers with a single click from browsers or other applications.

Usage Example

Users can now click links like:

<a href="telnet://aardmud.org:4000">Play Aardwolf MUD</a>
<a href="telnet://batmud.bat.org">Connect to BatMUD</a>

Or run from command line:

mudlet "telnet://testserver.com:2000"

Mudlet will:

Parse the URI
Find or create a matching profile
Auto-connect to the MUD server

TESTING

I ran it on WEB and it worked fine. I ran it from command line, it worked fine

HERE IS A DEMO VIDEO : https://github.com/user-attachments/assets/143cc98a-3453-4bd9-bbe8-5b48c58db490

Motivation for adding to Mudlet

The bounty and to improve myself and contribute

Other info (issues closed, discussion etc)

/closes #689
/claim #689

CHECKLIST:

[x] Windows
[x] Linux
[x] macOS

add-deployment-links · 2025-11-30T06:01:25Z

Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

linux: https://make.mudlet.org/snapshots/a5a1cb/Mudlet-4.20.1-testing-pr8601-cebdad19-linux-x64.AppImage.tar (commit cebdad1)
osx intel: https://make.mudlet.org/snapshots/17df45/Mudlet-4.20.1-testing-pr8601-cebdad19-x86_64.dmg (commit cebdad1)
osx arm: https://make.mudlet.org/snapshots/a15b0b/Mudlet-4.20.1-testing-pr8601-cebdad19-arm64.dmg (commit cebdad1)
windows 64 bit: https://make.mudlet.org/snapshots/594ee5/Mudlet-4.20.1-testing-pr8601-20d71458-windows-64.zip (commit 20d7145)

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

Excellencedev · 2025-11-30T06:47:05Z

@coderabbitai full review

coderabbitai · 2025-11-30T06:47:11Z

✅ Actions performed

Full review triggered.

coderabbitai · 2025-11-30T06:54:48Z

📝 Walkthrough

Walkthrough

The changes implement telnet URI protocol handling for the Mudlet application. This includes updating the desktop file MIME type associations to include telnet scheme handling, adding macOS bundle configuration with telnet protocol support, and implementing URI parsing and profile matching logic. The system queues and forwards telnet URIs between application instances, registers the protocol handler on Windows, and supports profile auto-loading when launched with a telnet:// URI. Supporting infrastructure includes instance coordination, URI validation, profile creation, and unit tests for URI parsing functionality.

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/MudletInstanceCoordinator.cpp (1)

94-127: Potential loss of Telnet URIs when multiple arrive in quick succession

The Telnet path in handleReadyRead() stores a single mQueuedTelnetUri and then schedules a QTimer::singleShot that later reads and clears it. If two or more Telnet URIs arrive before the first timer fires:

Each handleReadyRead() overwrites mQueuedTelnetUri.

The first timer processes the last URI.

The subsequent timer(s) see an empty string and do nothing.

Net effect: all but the last URI are silently dropped.

If you expect only one URI at a time this may be acceptable, but if multiple telnet:// arguments or fast successive clicks are possible you likely want a queue, e.g.:

Replace QString mQueuedTelnetUri with QStringList mQueuedTelnetUris.

Push each new URI and have the timer process and pop them in FIFO order.

Alternatively, use QTimer::singleShot with a lambda capturing a copy of the current URI rather than reading from shared state.

🧹 Nitpick comments (10)

src/MudletInstanceCoordinator.h (1)

39-43: Consider consistent synchronization for Telnet URI queue

mQueuedTelnetUri is now exposed via queueTelnetUri, forwardTelnetUriToRunningInstance, and readTelnetUriQueue, but it isn’t obviously covered by the same mutex used for mQueuedPackagePaths. If these APIs can ever be called off the same thread as handleReadyRead(), you may want to guard all accesses to mQueuedTelnetUri with mMutex for consistency and to avoid subtle races. If everything is guaranteed to run on the GUI thread, please document that assumption.

test/CMakeLists.txt (1)

122-128: Plan for re‑enabling TelnetUriTest or extracting testable unit

Right now the Telnet URI tests are fully commented out, so the new parsing logic isn’t exercised in CI. The comment explains why, but it’d be good to:

Either extract parseTelnetUri into a small, non‑GUI utility that this test can link against, or

Re‑enable TelnetUriTest once you have a sane way to link against the main library.

As‑is, the test file can easily fall out of sync with the implementation without anyone noticing.

src/mudlet.h (1)

768-789: Align parseTelnetUri visibility with unit‑test strategy

TelnetUriData and the helper methods (especially parseTelnetUri) are private, but test/TelnetUriTest.cpp calls mudlet::parseTelnetUri(...) directly. As soon as you re‑enable that test, it will fail to compile.

Options:

Move parseTelnetUri into a small utility (e.g. a free function or helper class) that’s public/visible to tests but still internal to Mudlet, or

Keep it as a private member and make the test a friend (less ideal, but consistent with current design), or

Switch the tests to exercise Telnet handling via the public handleTelnetUri path instead of the parser directly.

Choosing one of these now will avoid friction when you eventually wire the tests back into CMake.

test/TelnetUriTest.cpp (1)

76-97: Strengthen profile naming and collision tests

testProfileNameGeneration and testProfileNameCollision only compare hard‑coded QString values against themselves. They don’t touch any production code, so they can never fail unless the literals are edited.

When you hook up the real profile‑generation logic (e.g. createProfileForUri or similar), it’d be better to:

Call that function with representative URIs, and

Assert on the resulting profile names and suffixing behavior.

Until then, these tests are effectively placeholders.
src/MudletInstanceCoordinator.cpp (2)
102-119: Defensive check around mudlet::self() in Telnet handler lambda

In the Telnet branch, the lambda passed to QTimer::singleShot does:
mudlet::self()->handleTelnetUri(mQueuedTelnetUri);
without checking that mudlet::self() is non‑null, unlike installPackagesLocally(), which asserts the pointer. If this code can ever run before the main mudlet instance has been constructed, it could crash.

Consider mirroring the package code:
mudlet* app = mudlet::self();
Q_ASSERT(app);
if (!app) {
    return;
}
app->handleTelnetUri(uri);
This keeps behavior safe in release builds and debuggable in debug builds.

159-188: Telnet forwarding logic is straightforward; consider clearing state after send

The queueTelnetUri / forwardTelnetUriToRunningInstance / readTelnetUriQueue trio is simple and readable. One small improvement: after a successful forward, you might want to clear mQueuedTelnetUri so a subsequent call doesn’t accidentally resend the same URI if queueTelnetUri wasn’t invoked again.
if (socket.waitForConnected(WAIT_FOR_RESPONSE_MS)) {
    const QString message = qsl("TELNET_URI:") + mQueuedTelnetUri;
    socket.write(message.toUtf8());
    socket.waitForBytesWritten(WAIT_FOR_RESPONSE_MS);
    socket.disconnectFromServer();
+   mQueuedTelnetUri.clear();
    return true;
}
Not critical, but it makes the state machine a bit tighter.
src/mudlet.cpp (2)
4365-4399: Optional: clarify whether predefined games should be matched here

findMatchingProfile currently:

Builds profileNames from profiles/ directory plus TGameDetails::keys().

But only matches based on host_url and port_number files:
QString profileHost = readProfileData(profileName, qsl("host_url"));
QString profilePort = readProfileData(profileName, qsl("port_number"));
// ...
if (profileHost.toLower() == host.toLower() && profilePort.toInt() == port) { ... }
For predefined games that don’t yet have an on‑disk profile (only entries in TGameDetails), this will never match, even though TGameDetails already knows their host and port.

If your intent is strictly “match existing saved profiles only”, this is fine. If instead you want “also treat predefined games as candidates even before the user has saved them”, you likely need to:

Detect when profileName is only in TGameDetails (no profile dir/data).

Compare (host,port) against TGameDetails::findGame(profileName)->hostUrl/port as well.

Otherwise, this implementation only ever considers persisted profiles, not bare predefined games.

4408-4419: Optional: profile naming with host:port may cause filesystem issues on Windows

For non‑default ports, you build profile names as hostname:port:
QString profileName = uriData.host;
if (uriData.port != 23) {
    profileName += qsl(":%1").arg(uriData.port);
}
These profile names are later used in filesystem paths under profiles/. On Windows, : inside a path component is problematic (reserved / alternate data stream syntax), and even if Qt allows it, it can make manual inspection and backup tooling harder.

If you want to be conservative across platforms, consider a filesystem‑safe separator, e.g.:

hostname_port, hostname (port 4000), or hostname@4000.

This is cosmetic but can save portability headaches later.
src/main.cpp (2)

395-427: CLI telnet:// detection and multi-instance forwarding look sound; consider a couple of edge cases

The flow of detecting a telnet:// positional argument, queuing it via MudletInstanceCoordinator, forwarding to an existing instance for non‑first runs, and falling back to starting a new instance if forwarding fails all looks coherent and aligns with the existing package-handling pattern.

Two small follow-ups to consider:

Ensure MudletInstanceCoordinator::forwardTelnetUriToRunningInstance() only returns false when the URI definitely was not processed by another instance; otherwise you could end up with both this process and the running instance using the same queued URI.

If you ever need to accept broader telnet URL variants, you might want to switch the startsWith("telnet://", Qt::CaseInsensitive) check to something like QUrl url(firstArg); if (url.scheme().compare("telnet", Qt::CaseInsensitive) == 0) so any valid telnet: URL form is picked up without relying on a specific prefix string.

663-671: Windows telnet:// registry registration will unconditionally take over the global handler

This block correctly builds a quoted command string ("<mudletExe>" "%1") and writes the expected URL Protocol registration keys, so the mechanics look right. However, writing directly under HKEY_CLASSES_ROOT\telnet means Mudlet will become the system-wide handler for telnet:// links every time it starts, overriding any existing client or prior user choice.

If that’s not explicitly desired, consider a more conservative approach, e.g.:

Only writing these keys when there is no existing telnet registration, or

Gating this behind a user-visible preference / first-run prompt so users can opt in to Mudlet taking over telnet:// handling.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 057c8b9 and 581295f.

📒 Files selected for processing (10)

mudlet.desktop (1 hunks)
src/CMakeLists.txt (1 hunks)
src/MacOSXBundleInfo.plist.in (1 hunks)
src/MudletInstanceCoordinator.cpp (3 hunks)
src/MudletInstanceCoordinator.h (2 hunks)
src/main.cpp (3 hunks)
src/mudlet.cpp (1 hunks)
src/mudlet.h (2 hunks)
test/CMakeLists.txt (1 hunks)
test/TelnetUriTest.cpp (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (3)

src/MudletInstanceCoordinator.cpp (1)

src/mudlet.cpp (2)

self (138-141)

self (138-138)

src/MudletInstanceCoordinator.h (1)

src/MudletInstanceCoordinator.cpp (6)

queueTelnetUri (159-162)

queueTelnetUri (159-159)

forwardTelnetUriToRunningInstance (166-184)

forwardTelnetUriToRunningInstance (166-166)

readTelnetUriQueue (186-189)

readTelnetUriQueue (186-186)

src/main.cpp (1)

src/mudlet.cpp (2)

self (138-141)

self (138-138)

🔇 Additional comments (6)

src/CMakeLists.txt (1)

719-725: MACOSX_BUNDLE_INFO_PLIST wiring looks correct

Using MACOSX_BUNDLE_INFO_PLIST to point at MacOSXBundleInfo.plist.in is the right way to hook the new Info.plist template into the macOS bundle; no issues from the CMake side.

src/MacOSXBundleInfo.plist.in (1)

1-42: Info.plist template correctly declares Telnet URL handler

The plist template looks well‑formed, and the CFBundleURLTypes block for the telnet scheme (role Viewer) should be enough for macOS to register Mudlet as a Telnet URL handler. The CMake placeholders line up with the properties set in src/CMakeLists.txt.

src/mudlet.h (1)

352-354: Public Telnet URI entry point is a good abstraction

Exposing a single handleTelnetUri(const QString& uri) on mudlet is a clean way to keep Telnet handling behind the main window API and aligns with the instance coordinator calling pattern.

test/TelnetUriTest.cpp (1)

25-47: parseTelnetUri tests depend on private API

These tests call mudletInstance.parseTelnetUri(...), but parseTelnetUri is currently private in mudlet. That's consistent with why TelnetUriTest is commented out in CMake; as soon as you re‑enable it, compilation will fail.

Once you decide how to expose or refactor the parsing logic (utility function, friend, or public API), please update these tests accordingly so they compile and exercise the real implementation.

src/mudlet.cpp (1)

4327-4350: Strengthen telnet URI validation (URL validity and port range)

The review's technical concerns about parseTelnetUri are sound. Web search confirms:

QUrl::port(23) returns 23 both when no port is explicitly specified AND when a port is present—making the distinction unclear.

QUrl::isValid() checks only generic RFC syntax, not telnet-specific semantics; however, it will catch some malformed URIs.

The suggested approach using url.port(-1) to explicitly distinguish "no port" from "port present" is the correct pattern.

Valid port range in Qt is 0–65535.

The suggested refinement is valid:

Add url.isValid() for syntax validation

Use url.port(-1) to distinguish absent ports from present ones

Explicitly reject ports outside 1–65535

This approach makes failures explicit rather than silently defaulting to port 23.

Unable to verify the actual code implementation in src/mudlet.cpp due to repository access limitations; however, the technical foundation of the review is correct based on Qt's documented behavior.

src/main.cpp (1)

713-721: Deferred startup handling cleanly prioritises telnet URIs over normal auto-login

Deferring startup behaviour with QTimer::singleShot(0, qApp, ...) and branching on telnetUri.isEmpty() nicely ensures mudlet::self() is initialised before you either call handleTelnetUri() or startAutoLogin(cliProfiles). Capturing cliProfiles and telnetUri by value keeps the lambda safe and self-contained. This integration looks good.

mudlet.desktop

src/mudlet.cpp

src/MudletInstanceCoordinator.h

src/MudletInstanceCoordinator.cpp

src/main.cpp

src/mudlet.cpp

src/mudlet.pro

vadi2 · 2025-12-05T13:56:07Z

Using an actual webpage on the web (https://store.chipkin.com/articles/telnet-list-of-telnet-servers for example), the link doesn't seem to work:

Screencast.from.2025-12-05.14-55-20.mp4

Excellencedev · 2025-12-05T13:59:47Z

Using an actual webpage on the web (https://store.chipkin.com/articles/telnet-list-of-telnet-servers for example), the link doesn't seem to work:

Screencast.from.2025-12-05.14-55-20.mp4

@vadi2 What OS ?

vadi2 · 2025-12-05T14:04:23Z

That's on Windows

Excellencedev · 2025-12-05T14:08:35Z

@vadi2 It seems to work for me perfectly even with your links. Maybe you may have permissions blocking this. Did you run Mudlet normally first ?

SEE VIDEO OF IT WORKING:

2025-12-05.15-02-17.mp4

vadi2 · 2025-12-05T14:18:20Z

As you can see in the video, I run Mudlet first in 0:05

Excellencedev · 2025-12-05T14:20:31Z

@vadi2 what do you suspect may be happening ?

Excellencedev · 2025-12-05T14:23:47Z

maybe you should restart your machine or change some setings or maybe some antivirus software or that it just dosen't work first try

vadi2 · 2025-12-05T14:39:55Z

The idea behind the feature is that it just works for the players, without changing AV settings.

ZookaOnGit · 2025-12-11T03:20:07Z

Doesn't seem to work well on command invocation on Debian 13.

mudlet "telnet://rainmaker.wunderground.com" without a port saw it sitting at the initial opening screen without a profile screen. Recommend defaulting to port 23 if undefined.

tried mudlet "telnet://rainmaker.wunderground.com:23"

tried a different URL mudlet "telnet://india.colorado.edu:13 with port, still sits at the connection screen. closed, retried, same error as above. Noted connection details aren't properly automatically filled out.

Clicking on telnet link doesn't open Mudlet. No known file associations with telnet.

Excellencedev · 2025-12-12T16:23:52Z

/refresh links

Excellencedev · 2025-12-20T14:16:45Z

@vadi2 @ZookaOnGit I've verified that clicking on telnet links now works on Linux

2025-12-20.15-11-09.mp4

ZookaOnGit · 2025-12-20T23:44:11Z

The connection information is now properly populated.

I am able to click on telnet links on the command line to open them in Mudlet so that part does seem to work. I am not a fan of installing the desktop icon and associating the protocol with Mudlet during run time. I think this should be part of the installation process or the user should get queried if they want the association (only once). Reasoning; if Mudlet is removed the handler is still associated and the icon will still show in the menu but the system is now broken for the user with all fingers pointing at Mudlet. I also do not like the protocol handler being overwritten without warning by Mudlet (which isn't a full telnet compatible program), some users will likely prefer to use a different program for actual telnetting. All other respectable programs ask for associations, we should do the same.

Problems;

when opening a new telnet connection from the command line I cannot use the 'Close Profile' option from the top menu. Only closing down Mudlet entirely allows me to close this stuck profile. It's like something isn't completing as when subsequently opened the default packages are installed (should happen on first open) and 'Close Profile' works again.

Screencast_20251221_101907.webm

the mudlet.desktop file doesn't populate the icon correctly

Firefox still did not work, I had to add a protocol handler to it. (This is likely out of scope for this PR).

Now I can open telnet links in Firefox noting the above issue of not being able to close new profiles.

Screencast_20251221_104028.webm

SlySven · 2026-03-20T20:34:25Z

Testing the PR build in a Windows OS environment is producing TWO problems - one being due to the operating conditions and one which seems to be a defect - possibly introduced by other changes.

To test this one has to associate telnet scheme URLs with the executable in the (extracted) .zip file - i.e. the Mudlet.exe in the base of the extracted files. However the location of the application itself is not being considered - note how appPath is currently underlined in Qt Creator in my current Windows OS - which is a signal that it is unused:
- and the following seems to be missing from the region of around 5666-5679 in ./src/TLuaInterpreter.cpp:

#elif defined(Q_OS_WINDOWS)
    // Running from an extracted .zip archive requires the C search path
    // to also be set to the directory of the executable:
    additionalCPaths << qsl("%1/?.dll").arg(appPath);

this is what I deduced from the following:

the RED lines are for a preloaded version - not applicable; and "Lua" script module forms but lfs is a C (binary) module so these aren't applicable.
the BLUE line is for a binary module in the profile's location so not applicable.
the PURPLE boxed line is odd but suggests that the "current directory" isn't the one that the executable is running from.
the GREEN lines are almost right - they are basis on the correct directory - in this case \\HUNT\Public\Downloads\Mudlet-4.20.1-testing-pr8601-632544f6-windows-64 which is where the executable is located - but the ..\lib\lua\5.1\lfs.dll and ..\lib\lua\5.1\loadall.dll are associated with empty LUA_PATH and LUA_CPATH variables - which are not set to anything in this situation.
I believe this needs a separate fix which I will run up as a simple one chunk PR which can be merged into the development branch and then used to update this PR.

Opening the telnet scheme link DID start up Mudlet and automatically connect to the given URL. However it ALSO overlaid it with the "Select a profile to connect to" dialogue - which isn't right in this situation

- although I note that a new icon for this new profile was correctly added after closing and reopening the dialogue - which IS correct.

I think @Excellencedev will need to address 2.

…into telnet-links

Excellencedev · 2026-03-21T03:23:28Z

@SlySven Your second point has been addressed in 3861cb4

2026-03-21.04-20-20.mp4

src/main.cpp

Co-authored-by: Stephen Lyons <slysven@virginmedia.com>

SlySven · 2026-03-21T03:38:40Z

Humm, after trying another PR's Windows .zip PR test build that started up fine without errors - by double clicking on the mudlet.exe file extracted from that zip file. So it seems to me that in this context - when the Mudlet executable is started by a browser (in my case the PaleMoon one) which has been told to associate the telnet scheme links with the executable in the extracted test PR build the "current working directory" is not the one that contains the Mudlet executable so that the path beginning with . - for the ./lfs.dll file is not correct in this usage. So the above 1. item/change may need to be included to be able to test this PR even if not needed in other situation.

🤔

Excellencedev · 2026-03-21T04:38:18Z

@SlySven Your 1st point has been addressed in 95ff228

https://github.com/user-attachments/assets/5076d77c-61d6-4d7e-aeb7-138dcb1921e3. OBS ruined my video

SlySven · 2026-03-22T00:10:08Z

/refresh links

SlySven · 2026-03-22T01:46:16Z

@SlySven Your 1st point has been addressed in 95ff228

https://github.com/user-attachments/assets/5076d77c-61d6-4d7e-aeb7-138dcb1921e3. OBS ruined my video

After telling my web-browser (PaleMoon) that I wanted to use the Mudlet.exe in the unzipped archive that is in https://make.mudlet.org/snapshots/de8fae/Mudlet-4.20.1-testing-pr8601-983b342e-windows-64.zip (i.e. the current test build for WINDOWS) it successfully started Mudlet and opened the link I had clicked on (which wasn't a stored profile the first time I tried it) which was telnet://ancientempires.net:5011 {not something that my browser spotted as a URL so doesn't mark it as a link here!) This is merely a MUD I had never visited before before testing out this PR - but which I found via https://www.mudconnect.com/ specifically from https://www.mudconnect.com/cgi-bin/search.cgi?mode=mud_listing&mud=Ancient+Empires and clicking on the "connect by telnet" link ...

Putting the link telnet://ancientempires.net:5011 into my text editor (NotePad++) also made a usable link that also started Mudlet and opened the MUD concerned.

👍 As far as I can tell this PR is functionally complete for the Windows OS.

The only "missing-link" might be making the Mudlet application being the application to open such telnet: scheme links but I am not sure how that would happen automatically unless it was something that the installer would do. OTOH I can accept that it might be something that has to be manually done the first time the end-user clicks on such a link and the OS or a web-browser asks how the user wants it opened.

Excellencedev · 2026-03-22T03:34:07Z

Alright, thanks for testing

Excellencedev · 2026-03-25T01:18:18Z

Fixed conflicts

vadi2 · 2026-04-03T16:49:30Z

Code review notes:

Duplicate migratePasswordsToSecureStorage call

src/main.cpp:978 and src/main.cpp:1038-1042

The comment at line 974 explains why migration was moved from a 2-second timer to an immediate call ("which created a race: the connection dialog could open and attempt to load passwords before migration had a chance to run"). But the PR re-adds the 2-second timer version at line 1038. This is redundant and reintroduces the race the immediate call was designed to fix.

Dead code: takeOwnershipOfFileOpenHandler and mFileOpenHandler

src/mudlet.h:203,402 and src/mudlet.cpp:6941-6944

The method and member are declared and implemented but never called. FileOpenHandler is a stack variable in main() (line 933). Either use the ownership transfer pattern or remove the dead code.

Dead code: readTelnetUriQueue()

src/MudletInstanceCoordinator.h:44 and src/MudletInstanceCoordinator.cpp:197-201

Declared, implemented, never called anywhere.

installPackagesRemotely ignores write errors but reports success

src/MudletInstanceCoordinator.cpp:47-50

Neither socket.write() nor waitForBytesWritten() return values are checked, but the function returns true regardless. The caller in main.cpp:486 uses this to decide whether to exit the second instance (return 0). If the write silently fails, the second instance exits and the packages are never installed. Contrast with forwardTelnetUriToRunningInstance() which correctly checks both.

Linux xdg-mime not-found silently registers Mudlet as handler

src/main.cpp:796-801

If xdg-mime isn't installed (minimal systems, containers, some Wayland setups), start() fails, readAllStandardOutput() returns empty, existingHandlerFound becomes false, and Mudlet silently registers itself without asking the user. "Tool not found" is conflated with "no handler registered." Should check xdgQuery.error() after start() to distinguish the two cases.

macOS path resolution failure silently skips handler check

src/main.cpp:748-765

If CFURLGetFileSystemRepresentation fails, the code falls through with forceAsk still false. We know a handler exists (got a valid appUrl) but can't resolve its path. Mudlet then assumes it IS the registered handler and doesn't ask. Should set forceAsk = true in the else branch.

UI promises nonexistent setting

src/main.cpp:828

"You can change this later in Settings > General." - no such toggle exists in the preferences dialog. Please implement the toggle so users can change their choice.

Missing blank line between functions

src/mudlet.cpp:6944-6945 - no blank line between takeOwnershipOfFileOpenHandler() and setGlobalStyleSheet().

No-op double-split in handleReadyRead

src/MudletInstanceCoordinator.cpp:117-120

The outer loop already splits on '\n' at line 104. QChar::LineFeed is '\n'. The inner split will always produce a single-element list. Should just do mQueuedPackagePaths << message.

Excellencedev · 2026-04-04T03:10:27Z

Code review notes:

@vadi2 Addressed all the feedback in cebdad1

vadi2

Good work with this! Appreciate your persistent effort in getting it across the line, and @mpconley's assistance in helping test and resolve issues as well.

Excellencedev · 2026-04-04T06:44:55Z

@vadi2 Thank you for reviewing and looking forward to future contributions to this project

Excellencedev marked this pull request as ready for review November 30, 2025 06:43

Excellencedev requested a review from a team as a code owner November 30, 2025 06:43

Excellencedev marked this pull request as draft November 30, 2025 06:44

coderabbitai bot reviewed Nov 30, 2025

View reviewed changes

mudlet.desktop Outdated Show resolved Hide resolved

src/mudlet.cpp Outdated Show resolved Hide resolved

src/MudletInstanceCoordinator.h Outdated Show resolved Hide resolved

Excellencedev marked this pull request as ready for review December 1, 2025 00:14

algora-pbc bot added the 🙋 Bounty claim label Dec 1, 2025

SlySven reviewed Dec 4, 2025

View reviewed changes

Excellencedev requested a review from SlySven December 5, 2025 04:07

Excellencedev requested a review from Kebap December 9, 2025 03:19

Excellencedev marked this pull request as draft December 11, 2025 03:21

Excellencedev marked this pull request as ready for review December 13, 2025 05:13

Excellencedev marked this pull request as draft December 19, 2025 14:54

Excellencedev marked this pull request as ready for review December 20, 2025 14:16

Excellencedev closed this Dec 21, 2025

Merge branch 'development' into telnet-links

8b434d5

Excellencedev added 2 commits March 21, 2026 03:44

Fix Connection Dialog Overlay for Telnet URIs

3861cb4

Merge branch 'telnet-links' of https://github.com/Excellencedev/Mudlet …

983b342

…into telnet-links

SlySven reviewed Mar 21, 2026

View reviewed changes

src/main.cpp Outdated Show resolved Hide resolved

Update src/main.cpp

39b98c3

Co-authored-by: Stephen Lyons <slysven@virginmedia.com>

Excellencedev added 2 commits March 21, 2026 04:42

.

1336c64

fix

95ff228

Excellencedev requested a review from SlySven March 21, 2026 05:47

SlySven mentioned this pull request Mar 22, 2026

Infrastructure: add comprehensive resetProfile() test suite #9082

Merged

Excellencedev added 2 commits March 22, 2026 15:42

Merge branch 'development' into telnet-links

5b0c8e8

Merge branch 'development' into telnet-links

b8b6cce

ZookaOnGit added this to the future release milestone Mar 25, 2026

Excellencedev added 2 commits March 27, 2026 15:03

Merge branch 'development' into telnet-links

bd80332

Merge branch 'development' into telnet-links

bb840d3

Excellencedev added 2 commits April 3, 2026 17:59

Merge branch 'development' into telnet-links

20d7145

Address fedback from vadi

cebdad1

vadi2 approved these changes Apr 4, 2026

View reviewed changes

vadi2 merged commit 30e6531 into Mudlet:development Apr 4, 2026
12 checks passed

vadi2 mentioned this pull request Apr 5, 2026

add: telnets:// link support for secure TLS connections #9153

Open

Uh oh!

Conversation

Excellencedev commented Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Brief overview of PR changes/additions

Summary

Usage Example

TESTING

Motivation for adding to Mudlet

Other info (issues closed, discussion etc)

CHECKLIST:

Uh oh!

add-deployment-links bot commented Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test versions

Uh oh!

Excellencedev commented Nov 30, 2025

Uh oh!

coderabbitai bot commented Nov 30, 2025

Uh oh!

coderabbitai bot commented Nov 30, 2025

Walkthrough

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

vadi2 commented Dec 5, 2025

Uh oh!

Excellencedev commented Dec 5, 2025

Uh oh!

vadi2 commented Dec 5, 2025

Uh oh!

Excellencedev commented Dec 5, 2025

Uh oh!

vadi2 commented Dec 5, 2025

Uh oh!

Excellencedev commented Dec 5, 2025

Uh oh!

Excellencedev commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vadi2 commented Dec 5, 2025

Uh oh!

ZookaOnGit commented Dec 11, 2025

Uh oh!

Excellencedev commented Dec 12, 2025

Uh oh!

Excellencedev commented Dec 20, 2025

Uh oh!

ZookaOnGit commented Dec 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SlySven commented Mar 20, 2026

Uh oh!

Excellencedev commented Mar 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

SlySven commented Mar 21, 2026

Uh oh!

Excellencedev commented Mar 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SlySven commented Mar 22, 2026

Uh oh!

SlySven commented Mar 22, 2026

Uh oh!

Excellencedev commented Mar 22, 2026

Uh oh!

Excellencedev commented Nov 30, 2025 •

edited

Loading

add-deployment-links bot commented Nov 30, 2025 •

edited

Loading

Excellencedev commented Dec 5, 2025 •

edited

Loading

ZookaOnGit commented Dec 20, 2025 •

edited

Loading

Excellencedev commented Mar 21, 2026 •

edited

Loading

Excellencedev commented Mar 21, 2026 •

edited

Loading