Make chat dialog show up as fullscreen on iOS

[mcfnord]

Note

📡 STAND BY FOR AN LLM-AUTHORED MESSAGE.

Fixes #3383.

The chat dialog overflows the screen on iOS because it never sets Qt::WindowMaximized. #3343 (commit 40e5af1, "Make connect dialog show up as fullscreen on iOS") fixed the identical symptom by adding

#if defined( ANDROID ) || defined( Q_OS_IOS )
    setWindowState ( Qt::WindowMaximized );
#endif

to the connect dialog (connectdlg.cpp) and the about dialog (util.cpp) — but the chat dialog, the third dialog with the same problem, was never given the same treatment. This applies that same, already-merged pattern to CChatDlg, verbatim.

Scope: one hunk, iOS/Android only (the block preprocesses out on every other platform, so desktop builds are unaffected). No behavior change anywhere except making the chat window open maximized on mobile, exactly as the connect and about dialogs already do.

Testing note, stated plainly: I could not exercise the changed line myself — it lives inside #if defined( ANDROID ) || defined( Q_OS_IOS ), so it compiles out on the Linux/desktop toolchain I have. Its correctness rests on being identical to the two instances already shipping (connectdlg.cpp, util.cpp), and on setWindowState() being a QWidget method CChatDlg inherits just as CConnectDlg and CAboutDlg do. A confirmation on real iOS hardware would be welcome before merge.

[pljones]

@mcfnord,

Do you have no Android devices you can test the built APK on?

[mcfnord]

MY LLM WROTE:

No Android handset here... or maybe... I'll look.

What I do have is an x86 Mac Mini (Monterrey, Xcode 13.2.1), which can run either an iOS 15 Simulator or an Android emulator image. Both define the same preprocessor path this fix touches (ANDROID / Q_OS_IOS), so either would let me open the chat dialog and screenshot it filling the screen — the entire claim of this PR.

I haven't set that build up yet. If a Simulator/emulator screenshot would satisfy you as a stand-in for a real device, I'll go build one and post it here. If you'd want something a screenshot can't show (e.g. a specific device quirk, or you'd rather wait for someone with a physical Android/iOS device to confirm), let me know and I won't waste your time offering a substitute you don't want.

[ann0see]

Android would be good - iOS I'll be able to test in a few weeks (or days - not sure)

[ann0see]

I just remembered that Qt6 builds still result in a black screen so Qt6 is out of question. Might be related to OpenGL vs Metal builds - not sure.
Will test soon.

[ann0see]

Ok. Unfortunately, the chat dialog is still oversized on iOS. Tested with Qt 5.15.19

[mcfnord]

MY LLM WROTE: this comment. I asked it to root-cause @ann0see's "still oversized on iOS" report and fix it if it found something concrete.

Found it, and pushed a fix (4e7b2613): CClientDlg::ShowChatWindow() in src/clientdlg.cpp unconditionally calls ChatDlg.showNormal() to bring the dialog to front whenever bForceRaise is true (which is the default, so this fires on effectively every open). showNormal() clears any maximized/fullscreen window state — silently undoing the Qt::WindowMaximized this PR sets in CChatDlg's constructor for Android/iOS. connectdlg.cpp's equivalent maximize call (from #3343) has no showNormal() call anywhere, which is exactly why that one already worked and chat didn't.

Fix: guard the showNormal() call under the same #if defined( ANDROID ) || defined( Q_OS_IOS ) used for the maximize itself, so it only runs on desktop where it's needed (restoring from a minimized state) and never fires on mobile.

I don't have real iOS/Android hardware to re-confirm against, so this is a code-level fix grounded in your report rather than a re-tested one — happy to have you or ann0see re-check when convenient.

[mcfnord]

MY LLM WROTE:

@ann0see @pljones — Android tested on real hardware, as asked. The result is not what I predicted, and it contradicts my own root-cause comment above. Reporting it straight.

Hardware: Samsung Galaxy S22 Ultra (SM-S908U1), Android 16, arm64, Qt 5.15.2 (build + runtime, confirmed from the About dialog).

Three APKs, same handset, same session: mainline without this PR (3.12.3dev-1f9667ec), this PR before 4e7b2613 (3.12.2dev-03b85dee), and this PR with 4e7b2613 (3.12.2dev-818b5d73).

All three render the chat dialog full-bleed. Identically. I measured the fraction of the main window's left control panel (Mute/Settings/Chat/Connect) that the opened dialog covers: 17.8% on all three builds, and the screenshots are structurally identical. Including on mainline — which contains none of this PR's code.

Internal control, same binary. CClientDlg::ShowChatWindow(bForceRaise) calls showNormal() only when bForceRaise is true. I exercised both legs against the same build: the Chat button (true, showNormal() runs) and a server-pushed chat message without the welcome prefix (false, showNormal() skipped, per clientdlg.cpp:887). Both produce the same maximized dialog, 17.8%.

What that means, and the correction I owe you: on Android, showNormal() has no observable effect on dialog geometry, and neither does setWindowState(Qt::WindowMaximized) — mainline is already fullscreen without it. The mechanism I claimed on 2026-07-27 (showNormal() silently undoing the maximize) is not confirmed on Android, and I have no way to confirm it for iOS. Please don't spend iOS testing time on 4e7b2613 on my say-so. The most likely explanation for the Android behavior is that Qt's Android platform plugin clamps top-level dialogs to the Activity's client area regardless of window state — I have not verified that in Qt's source, so I am flagging it as a theory, not a finding.

One thing worth separating before more work goes in: you said "oversized," not "not maximized." Those are different failures with different fixes. If the iOS dialog is larger than the screen and clipped, that is a layout/sizeHint problem and no setWindowState() call will fix it — which would mean the #3343 pattern this PR copies is the wrong remedy for this dialog, however well it worked for connect/about. If you get a chance: is the iOS dialog exactly screen-sized but with content cut off, or is the dialog frame itself bigger than the screen? That one observation decides whether this PR's approach is viable at all.

Net for Android: no regression. This PR changes nothing observable there, in either direction. Any merge decision rests entirely on iOS.

The test rig is set up now, so I can run any candidate APK on this handset within the hour — just say what you want measured.

[ann0see]

It looks like this