dialogregistry.h File Reference

App-wide register of open modeless dialogs, in most-recently-used order, plus the dialog stacking strategy. More...

#include <QList>
#include <QObject>
#include <QPointer>
#include <QDialog>

Include dependency graph for dialogregistry.h:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes
class	openswmmvis::ui::DialogRegistry

Namespaces
namespace	openswmmvis
namespace	openswmmvis::ui

Detailed Description

App-wide register of open modeless dialogs, in most-recently-used order, plus the dialog stacking strategy.

Author

Caleb Buahin caleb.nosp@m..bua.nosp@m.hin@g.nosp@m.mail.nosp@m..com

Date

2026

License\n GPL-3.0-or-later

Two jobs, both of which need the same list:

1. RECOVERY (Phase A5). Modeless dialogs are ordinary top-level windows that the user can drag anywhere, including onto a monitor that is later disconnected. On macOS a natively-attached child window does not even appear in Mission Control, so a lost dialog was unreachable. The Window menu lists everything in here, and "Reset Window Positions" walks it.

2. STACKING (Phase B). Keeping dialogs above the main window is done one of two ways, selected by StackingMode:

   • NativeChildWindow (default, macOS): AppKit -addChildWindow:. Reliable ordering, but child windows move rigidly with their host and are invisible to the window server's recovery affordances.
   • QtRaiseOnActivate: pure Qt. When the application (or the main window) is activated, every registered dialog is raise()d in MRU order. No native gluing at all, so dialogs are fully independent windows.

   The mode is read once at startup from the OPENSWMM_DIALOG_STACKING environment variable ("qt" / "native"), else the "Window/DialogStacking" QSettings key, else the platform default. The environment override exists so a tester can flip strategies without touching preferences.

ORDERING is most-recently-USED, not open order: a dialog moves to the end of the list when it is activated. Re-raising on MRU order preserves the z-order the user arranged by clicking, whereas strict open order would shuffle their arrangement back every time the app was re-activated. A freshly shown dialog is activated as part of being shown, so "newest on top" still falls out naturally.

Entries are QPointer, so a dialog destroyed without a Hide/Close event (WA_DeleteOnClose teardown) simply drops out on the next read.