Re: [Development] Rationalizing qApp and qGuiApp

[Thiago Macieira]

On sábado, 18 de janeiro de 2020 02:03:33 PST Sze Howe Koh wrote:
> * There is no equivalent of qGuiApp for QCoreApplication and QApplication.

QCoreApplication::instance(), with suitable static_cast when you know what you 
have.

> 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)

I prefer (A), possibly also deprecating the macro entirely.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] RHI & KDAB's advanced dock widgets wonders

[maxzor]

Hello,

I follow closely and contribute to the development of a 
Qt-Graphics-View-based application, https://pgmodeler.io.


1. What is the expected overhaul work to do to adapt a CPU-based 
QPainter application to the coming Qt6 Rendering Hardware Interface,

so as to benefit from GPU acceleration for the QGraphicsView ?
OpenGL work was never tackled for this app, and probably considered a 
bit too low-level.


2. Will the UI/UX work done in KDAB's KDDockWidgets 
 make it into mainline in a 
foreseeable future?


Best regards, Maxime

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Rationalizing qApp and qGuiApp

[Elvis Stansvik]

Den lör 18 jan. 2020 kl 11:05 skrev Sze Howe Koh :
>
> Currently,
>
> * The qApp macro changes type depending on which headers are included,
> and in what order. (If you #include  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

>
>
> Regards,
> Sze-Howe
>
> [1] https://codereview.qt-project.org/c/qt/qtbase/+/174414
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Rationalizing qApp and qGuiApp

[Sze Howe Koh]

Currently,

* The qApp macro changes type depending on which headers are included,
and in what order. (If you #include  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?


Regards,
Sze-Howe

[1] https://codereview.qt-project.org/c/qt/qtbase/+/174414
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development