PARSEC-5572 - Support additional character sets on macOS

[mtrang1263]

Update our text event handler to allow user to supply other unicode characters that are beyond the ascii character set.

QA Notes

Summary of changes

Update our handling of IMGUI text input to support additional characters. The method that sends the keypress events to the host is not affected (window_keyboard_event)

Platforms Affected

• macOS

Test cases performed

• macOS 26.2 / macOS 15.3.1
  • Able to type additional characters like æ (Option + ') Æ (Option + Shift + ') in the login screen (email and password) as well as the host search field.
  • Control characters, like backspace, are ignored and processed correctly by IMGUI
  • Able to pass additional characters when connected to macOS host (both 26.2 and 15.3.1) [This was working previously]
  • Connected to Windows host and keyboard inputs are working as expected.

Test cases untested

• More thorough ASCII control codes and other Unicode control / odd characters.
  • I went through some of them, like Forward Delete on macOS but we are allowing additional unicode characters through that was previously dropped.

[Copilot]

Pull request overview

Updates the macOS text event path to allow non-ASCII input by only filtering ASCII control characters (instead of restricting to “visible ASCII”).

Changes:

• Replaces the “visible ASCII” gate with an early-return guard that only rejects ASCII control characters.
• Allows multi-byte UTF-8 text to flow through to MTY_EVENT_TEXT.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

strlen(text) == 1 scans the full string when you only need to know whether it’s a single byte/char. Prefer a constant-time check like text[1] == '\\0' to avoid unnecessary work in a hot text-input path (and to avoid reliance on potentially long/unterminated buffers).

Suggested change

	if (!text || !text[0] || (strlen(text) == 1 && (text[0] < 0x20 || text[0] == 0x7F)))
	if (!text || !text[0] || (text[1] == '\0' && (text[0] < 0x20 || text[0] == 0x7F)))

[Copilot]

The guard condition is fairly dense and mixes three concerns (null/empty, single-byte check, control-character check). Consider splitting into a couple of straightforward if statements (or a small helper predicate) and adding braces for clarity to reduce the chance of future mistakes when this logic is modified.

Suggested change

	if (!text || !text[0] || (strlen(text) == 1 && (text[0] < 0x20 || text[0] == 0x7F)))
	// Ignore ASCII control characters
	return;
	if (!text || !text[0]) {
	return;
	}
	if (strlen(text) == 1) {
	unsigned char c = (unsigned char) text[0];
	// Ignore ASCII control characters
	if (c < 0x20 || c == 0x7F) {
	return;
	}
	}

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mtrang1263]

Adding this function so we can still ignore function keys that were previously ignored by the strict ASCII value check.

[mtrang1263]

Moving back to coding to see if we can get the dead key support for additional accents.

[mtrang1263]

Spent the day exploring dead keys. The complexity is a bit high for an edge case that's resolved by the webview. Marking as ready for review. Since no changes since I've last run it, we should be good for code review and then QA.