Modify GUI to use system (theme) icons when available. This may only
affect builds on Linux platforms when using the system-provided Qt, but
will improve visual consistency with e.g. okay/cancel buttons which are
also using the system/theme icons. This also means that the GUI will
look slightly more "native" on Linux.
Replace QToolButton instances with QPushButton. QToolButton is only
meant to be used on tool bars and some other special situations. Worse,
we had a mix of QToolButton and QPushButton for things that clearly
should be using the same widget. This will improve visual consistency
and may fix some rendering issues.
Don't use subclasses to connect to QAbstractButton::clicked. This is
slightly dodgy, but of more immediate importance, tweaking it will allow
us to change the widget type of some QToolButton instances that should
be QPushButton.
Refactoring in commit 41e223deb3 (CMake GUI: Split up into libraries,
add test shim, 2020-09-14, v3.19.0-rc1~116^2~2) broke linking of Qt
resources, such as the Add/Remove Entry button icons.
Fixes: #21682
According to https://bugreports.qt.io/browse/QTBUG-59428, Qt 5.10 and
above moved macOS style handling into a separate `qmacstyle` plugin.
Install the plugin in our `CMake.app` package on macOS.
Issue: #21606
According to https://bugreports.qt.io/browse/QTBUG-59428, Qt 5.10 and
above moved macOS style handling into a separate `qmacstyle` plugin.
Install the plugin in our `CMake.app` package on macOS.
Issue: #21606
Since commit f1de6f6682 (cmake-gui: Support building against Qt6,
2020-12-17) all available plugins for each Qt component are installed.
This installs more than we need for CMake, so restore Qt5-specific logic
to install only the plugins did before.
Fix logic from commit f1de6f6682 (cmake-gui: Support building against
Qt6, 2020-12-17) to restore population of the `QT_PLUGINS` variable used
in our `fixup_bundle` call.
Fix the string comparison added by commit 2e4cbaa521 (cmake-gui: Add a
Qt version control variable, 2020-12-28). The version-based comparison
is not meant for arbitrary strings.
Revert commit 0fc1818831 (QCMakeWidgets: replace QDirModel, 2020-06-15,
v3.19.0-rc1~696^2). `QFileSystemModel` is not a drop-in replacement for
`QDirModel`. Additional changes are needed to make it work fully.
Revert the change and suppress the `QDirModel` deprecation warning
pending further investigation.
Fixes: #21589
In commit ce9dbceb42 (QtDialog: remove Qt4-only code, 2020-06-02,
v3.19.0-rc1~712^2~1) we removed an event filter that was thought to be
necessary only as a workaround for a bug in Qt. However, that bug was
fixed in Qt 4.5, and the file dialog still crashes as of Qt 5.14 without
the filter. Restore the workaround pending further investigation.
Fixes: #21400
If a path argument with no -S or -B leads to a cache directory,
use that directory as the binary directory. Otherwise, use the
binary directory from the preset.
Fixes: #21311
Make this field separate for both architecture and toolset. Allow
architecture and toolset to be either strings or objects with value
and strategy fields.
Fixes: #21317
Make a distinction between strings which simply use the
$vendor{<...>} macro, which is valid but makes it unusable by CMake,
and strings which actually contain invalid macro expansions.
Fixes: #21308
In commit efe48189bf (cmake-gui: Restore application icon on macOS,
2020-10-13, v3.19.0-rc1~2^2) and commit f7ae4f572b (cmake-gui: Restore
application icon on Windows, 2020-10-13, v3.19.0-rc1~1^2) we attached
the icon source files to all consumers of `CMakeGUILib`, but that
includes other libraries like `CMakeGUIMainLib`. The latter library is
meant only for direct consumption by a GUI executable, so use that to
propagate the icons instead.
In commit 41e223deb3 (CMake GUI: Split up into libraries, add test shim,
2020-09-14) the Windows resource source file that references the icon
was moved to CMakeGUILib, but it needs to be directly in the main
application in order to be attached properly.
In commit 41e223deb3 (CMake GUI: Split up into libraries, add test shim,
2020-09-14) the macOS icon source file was moved to CMakeGUILib, but it
needs to be directly in the main application in order to be attached to
the `.app` in the right place.
Qt5 supports passing function pointers to QObject::connect(), and
prefers this over SIGNAL() and SLOT(). Modernize the connections,
stop using a deprecated signal from QComboBox, and modernize a few
QKeySequence's.
#pragma once is a widely supported compiler pragma, even though it is
not part of the C++ standard. Many of the issues keeping #pragma once
from being standardized (distributed filesystems, build farms, hard
links, etc.) do not apply to CMake - it is easy to build CMake on a
single machine. CMake also does not install any header files which can
be consumed by other projects (though cmCPluginAPI.h has been
deliberately omitted from this conversion in case anyone is still using
it.) Finally, #pragma once has been required to build CMake since at
least August 2017 (7f29bbe6 enabled server mode unconditionally, which
had been using #pragma once since September 2016 (b13d3e0d)). The fact
that we now require C++11 filters out old compilers, and it is unlikely
that there is a compiler which supports C++11 but does not support
#pragma once.
In commit d7679f6427 (QCMakeCacheView: use non-deprecated List and Set
constructions, 2020-06-10, v3.18.0-rc2~13^2) the conversion of the
`this->properties()` value to QSet is incorrect for Qt 5.14+. The
problem is that `this->properties()` returns by value, so the range
`this->properties().begin(), this->properties().end()` provides
iterators to two different instances. Use an intermediate temporary
copy of the value to get a consistent iterator range.
Fixes: #20981
Fix code added by commit d7679f6427 (QCMakeCacheView: use non-deprecated
List and Set constructions, 2020-06-10, v3.18.0-rc2~13^2), used
conditionally on Qt 5.14 or above, to compile as C++14.
This option has been broken since commit b9f9915516 (cmMakefile: Remove
VarUsageStack., 2015-05-17, v3.3.0-rc1~52^2). That commit removed the
check that an initialized variable has actually been used and caused the
option to warn on every variable ever set. This was not caught by the
test suite because the test for the feature only checked that warnings
appear when needed and not that they do not appear when not needed.
The option was never very practical to use. Remove it to avoid the
runtime cost of usage tracking and checks for every variable (which we
were doing even when the option was not used).
