[Development] Rationalizing qApp and qGuiApp

[Scott Bloom]

From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Elvis Stansvik
Sent: Saturday, January 18, 2020 4:33 AM
To: Sze Howe Koh <szehowe.koh at gmail.com>
Cc: Qt development mailing list <development at qt-project.org>
Subject: Re: [Development] Rationalizing qApp and qGuiApp

Den lör 18 jan. 2020 kl 11:05 skrev Sze Howe Koh <szehowe.koh at gmail.com>:
>
> Currently,
>
> * The qApp macro changes type depending on which headers are included, 
> and in what order. (If you #include <QGuiApplication> but instantiate 
> a QCoreApplication, qApp returns a QGuiApplication pointer)
> * The documentation says that the qApp macro is only valid if a 
> QApplication was instantiated. [1]
> * The qGuiApp macro doesn't change types like qApp; it is always a 
> QGuiApplication pointer.
> * There is no equivalent of qGuiApp for QCoreApplication and QApplication.
>
> To resolve this inconsistency, I propose that we do one of the 
> following for Qt 6:
>
> A) Update the documentation to say that qApp can change types. Leave 
> the qApp macro as-is.
>
> B) Leave the documentation as-is. Make the qApp macro disappear from 
> qcoreapplication.h and qguiapplication.h unless compatibility mode is 
> enabled.
>
> C) Rename "QApplication" -> "QWidgetApplication", keeping the former 
> as a typedef. Leave the qApp macro as-is but deprecated. Add the 
> qCoreApp and qWidgetApp macros (analogous to qGuiApp)
>
> Thoughts?

How about deprecating the q*App variables altogether, and recommend using e.g. QCoreApplication::, QGuiApplication:: et.c. instead? Static analysis will warn when calling static functions through an instance anyway [1].

Though now I realize there are also non-static functions on these classes, so probably not reasonable to do that *facepalm*.

As a user I think your suggestion sounds good.

Elvis

[1] https://clang.llvm.org/extra/clang-tidy/checks/readability-static-accessed-through-instance.html

=====
From a user's perspective (much more than "what is the best development course of action"), I would prefer the following

D) Get rid of qApp altogether, use static QCoreApplication::app() methods (or QGuiAPplication etc etc), where if you are NOT running it as the called for ::app from the correct class, it returns nullptr.  Otherwise it returns the correct type.

Unless in compatibility mode, qApp is gone, but if in compatibility mode, the documentation is updated to show the possibility of different types

Scott