Re: Re: Re: Programmatic color scheme change in QKdeTheme
Am Dienstag, 11. März 2025, 10:10 schrieb Axel Spoerl: > Hi David, > thanks for the insight! > The program would be ideal. However, it depends on KDE libraries. If an application links to KDE anyway, it can simply use the KDE platform theme. > Users of QKdeTheme are e.g. applications that don't link to KDE, because they need to run on Gnome environments as well. > If we wanted to propagate palettes to QKdeTheme, we would have to read them directly from settings without having to link to KDE. > Cheers > Axel Heh I did not expect that Qt would start to link KColorScheme library :D. But the output could be used to make default palettes for QKDETheme. Another option would be to just read the files during runtime. I see that QKdeThemePrivate::readKdeSystemPalette already can read colors from .config/kdeglobals which contain the colors of the currently active color scheme. The color scheme files in $GenericDataLocation/color-schemes/ have the same format. David
Re: Re: Re: Programmatic color scheme change in QKdeTheme
Just thinking out loud:
How about adding an
extern "C" MAYBE_SOME_EXPORT QGenericUnixTheme *createTheme() { return new
KdePlatformtheme(); }
to KdePlatformTheme?
We could then try to load the KDE library at runtine in
QKdeTheme::createKdeTheme(). If we can resolve the symbol, an application that
doesn't even know from KDE could benefit from KdePlatformTheme.
...and while at it, requestColorScheme() could also be re-implemented
From: kde-devel on behalf of David Redondo
Sent: Tuesday, 11 March 2025 10:37
To: kde-devel@kde.org
Subject: Re: Re: Re: Programmatic color scheme change in QKdeTheme
[You don't often get email from k...@david-redondo.de. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
Am Dienstag, 11. März 2025, 10:10 schrieb Axel Spoerl:
> Hi David,
> thanks for the insight!
> The program would be ideal. However, it depends on KDE libraries. If an
application links to KDE anyway, it can simply use the KDE platform theme.
> Users of QKdeTheme are e.g. applications that don't link to KDE, because
they need to run on Gnome environments as well.
> If we wanted to propagate palettes to QKdeTheme, we would have to read them
directly from settings without having to link to KDE.
> Cheers
> Axel
Heh I did not expect that Qt would start to link KColorScheme library :D. But
the output could be used to make default palettes for QKDETheme.
Another option would be to just read the files during runtime. I see that
QKdeThemePrivate::readKdeSystemPalette already can read colors from
.config/kdeglobals which contain the colors of the currently active color
scheme. The color scheme files in $GenericDataLocation/color-schemes/
have the same format.
David
Re: Re: Programmatic color scheme change in QKdeTheme
Am Montag, 10. März 2025, 19:24 schrieb Axel Spoerl:
> Hi David,
>
> I just did some debugging to find out, how KDE Palettes are promoted to the
> QKdeTheme.
> The blunt answer is: They don't, and they have never been.
>
> They were probably meant to be promoted at some point, because QKdeTheme
> implements an array of QPalette pointers (size == NPalettes == 17).
> So for each palette type, a new QPalette could be constructed from a KDE
> Palette. But that's not happening. The first record of the array is populated
> with default constructed QPalette, which is a fusion palette.
> All other records are initialized with nullptr and they remain like that
> throughout the life time of the QGuiApplication.
>
> QKdeTheme just implements font handling. Color wise, QGuiApplications won't
> blend in with KDE palettes. They just stick with a default fusion palette.
>
> That said: I think there's nothing needed right now. But we may want to pimp
> up QKdeTheme.
> The patch I mentioned factors it out from qgenericunixthemes.cpp. So
> enhancing the class will become a little easier.
>
Maybe a reason that it doesn't do that much was that Plasma has its own QPT,
so there was never enough pressure to make it better since in the most cases an
application would not use QKDETheme except if it shipped its own Qt or
something similar.
I've written very small program that prints the resulting QPalette from color
schemes. The output for BreezeLight and BreezeDark is as follows:
/usr/share/color-schemes/BreezeLight.colors
QPalette(resolve=0x7ffdef7f,"WindowText:[Active:#ff232629,Disabled:#ffa0a1a3,Inactive:#ff232629],Button:[Active:#fffcfcfc,Disabled:#fff0f0f0,Inactive:#fffcfcfc],Light:[Active:#,Disabled:#,Inactive:#],Midlight:[Active:#fff6f7f7,Disabled:#ffebedee,Inactive:#fff6f7f7],Dark:[Active:#ff888e93,Disabled:#ff82878c,Inactive:#ff888e93],Mid:[Active:#ffc4c8cc,Disabled:#ffbbc0c5,Inactive:#ffc4c8cc],Text:[Active:#ff232629,Disabled:#ffaaabac,Inactive:#ff232629],ButtonText:[Active:#ff232629,Disabled:#ffa8a9aa,Inactive:#ff232629],Base:[Active:#,Disabled:#fff3f3f3,Inactive:#],Window:[Active:#ffeff0f1,Disabled:#ffe3e5e7,Inactive:#ffeff0f1],Shadow:[Active:#ff474a4c,Disabled:#ff474a4c,Inactive:#ff474a4c],Highlight:[Active:#ff3daee9,Disabled:#ffe3e5e7,Inactive:#ffc2e0f5],HighlightedText:[Active:#,Disabled:#ffa0a1a3,Inactive:#ff232629],Link:[Active:#ff2980b9,Disabled:#ffa3cae2,Inactive:#ff2980b9],LinkVisited:[Active:#ff9b59b6,Disabled:#ffd6bae1,Inactive:#ff9b59b6],AlternateBase:[Active:#fff7f7f7,Disabled:#ffebebeb,Inactive:#fff7f7f7],ToolTipBase:[Active:#fff7f7f7,Disabled:#fff7f7f7,Inactive:#fff7f7f7],ToolTipText:[Active:#ff232629,Disabled:#ff232629,Inactive:#ff232629],PlaceholderText:[Active:#ff707d8a,Disabled:#ffc2c8ce,Inactive:#ff707d8a],Accent:[Active:#ff3daee9,Disabled:#ffe3e5e7,Inactive:#ffc2e0f5]")
/usr/share/color-schemes/BreezeDark.colors
QPalette(resolve=0x7ffdef7f,"WindowText:[Active:#fffcfcfc,Disabled:#ff686a6c,Inactive:#fffcfcfc],Button:[Active:#ff292c30,Disabled:#ff272a2e,Inactive:#ff292c30],Light:[Active:#ff393e43,Disabled:#ff383d42,Inactive:#ff393e43],Midlight:[Active:#ff2e3337,Disabled:#ff2d3136,Inactive:#ff2e3337],Dark:[Active:#ff131516,Disabled:#ff121415,Inactive:#ff131516],Mid:[Active:#ff1c1f21,Disabled:#ff1b1d20,Inactive:#ff1c1f21],Text:[Active:#fffcfcfc,Disabled:#ff606263,Inactive:#fffcfcfc],ButtonText:[Active:#fffcfcfc,Disabled:#ff6d6f72,Inactive:#fffcfcfc],Base:[Active:#ff141618,Disabled:#ff131517,Inactive:#ff141618],Window:[Active:#ff202326,Disabled:#ff1f2124,Inactive:#ff202326],Shadow:[Active:#ff0e0f10,Disabled:#ff0d0e0f,Inactive:#ff0e0f10],Highlight:[Active:#ff3daee9,Disabled:#ff1f2124,Inactive:#ff1b4155],HighlightedText:[Active:#fffcfcfc,Disabled:#ff686a6c,Inactive:#fffcfcfc],Link:[Active:#ff1d99f3,Disabled:#ff164160,Inactive:#ff1d99f3],LinkVisited:[Active:#ff9b59b6,Disabled:#ff402b4c,Inactive:#ff9b59b6],AlternateBase:[Active:#ff1d1f22,Disabled:#ff1c1e20,Inactive:#ff1d1f22],ToolTipBase:[Active:#ff292c30,Disabled:#ff292c30,Inactive:#ff292c30],ToolTipText:[Active:#fffcfcfc,Disabled:#fffcfcfc,Inactive:#fffcfcfc],PlaceholderText:[Active:#ffa1a9b1,Disabled:#ff42464a,Inactive:#ffa1a9b1],Accent:[Active:#ff3daee9,Disabled:#ff1f2124,Inactive:#ff1b4155]")
The code that turns those color schemes into QPalettes is here:
https://invent.kde.org/frameworks/kcolorscheme/-/blob/master/src/kcolorscheme.cpp#L580
David
#include
#include
#include
int main(int argc, char **argv) {
if (argc < 1)
return 1;
qDebug() << argv[1];
auto palette = KColorScheme::createApplicationPalette(KSharedConfig::openConfig(argv[1]));
qDebug() << palette;
}
Re: Breeze style problem since Qt 6.8.2
On Saturday, March 8, 2025 7:06:18 PM Central European Standard Time Tobias Leupold wrote: > Hi all! > > There's a style problem with Breeze that emerged with Qt 6.8.2: QSpinBoxes > take too much vertical space if an application-wide style sheet is set. Even > setting a single space as the style sheet already triggers this, it has > nothing to do with a spinbox-specific style. Hi! For what it's worth, I am also seeing this problem in Kdenlive. Didn't have time to investigate, but I can confirm that setting any non empty style sheet on a widget that contains a QSpinBox makes it use 1.5 - 2 times the vertical space with Qt 6.8.2 anf KF 6.11 using Breeze style. Regards, Jean-Baptiste > This does not show up with Fusion. And also not in Breeze, as long as no > application-wide style sheet is set. I suppose most KDE apps don't use > application-wide styles, so not many devs may have already noticed this. > However e.g. KPhotoAlbum is affected. > > I first thought this was a Breeze bug. Along with some hints from the Qt > forum, I opened a respective bug report: > > https://bugs.kde.org/show_bug.cgi?id=499906 > > However David Redondo said this should be an upstream Qt bug. So I filed one > there: > > https://bugreports.qt.io/browse/QTBUG-133845 > > ... where Christian Ehrlicher said he thinks it's a Breeze issue. > > So ... now the cat is biting its own tail. I have never worked on style > stuff before, so I don't know anything about this. Is anybody with more > insight of this willing to have a look at that issue? So that we can either > get this fixed in Breeze or in Qt or maybe in both? > > Thanks in advance for all help on tracking this annoying issue down! > > Cheers, Tobias
Re: Re: Re: Programmatic color scheme change in QKdeTheme
Asking differently: How can a Qt application make sure, that KdePlatformTheme
is used?
From: kde-devel on behalf of Axel Spoerl
Sent: Tuesday, 11 March 2025 11:46
To: kde-devel@kde.org
Subject: Re: Re: Re: Programmatic color scheme change in QKdeTheme
Just thinking out loud:
How about adding an
extern "C" MAYBE_SOME_EXPORT QGenericUnixTheme *createTheme() { return new
KdePlatformtheme(); }
to KdePlatformTheme?
We could then try to load the KDE library at runtine in
QKdeTheme::createKdeTheme(). If we can resolve the symbol, an application that
doesn't even know from KDE could benefit from KdePlatformTheme.
...and while at it, requestColorScheme() could also be re-implemented
From: kde-devel on behalf of David Redondo
Sent: Tuesday, 11 March 2025 10:37
To: kde-devel@kde.org
Subject: Re: Re: Re: Programmatic color scheme change in QKdeTheme
[You don't often get email from k...@david-redondo.de. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
Am Dienstag, 11. März 2025, 10:10 schrieb Axel Spoerl:
> Hi David,
> thanks for the insight!
> The program would be ideal. However, it depends on KDE libraries. If an
application links to KDE anyway, it can simply use the KDE platform theme.
> Users of QKdeTheme are e.g. applications that don't link to KDE, because
they need to run on Gnome environments as well.
> If we wanted to propagate palettes to QKdeTheme, we would have to read them
directly from settings without having to link to KDE.
> Cheers
> Axel
Heh I did not expect that Qt would start to link KColorScheme library :D. But
the output could be used to make default palettes for QKDETheme.
Another option would be to just read the files during runtime. I see that
QKdeThemePrivate::readKdeSystemPalette already can read colors from
.config/kdeglobals which contain the colors of the currently active color
scheme. The color scheme files in $GenericDataLocation/color-schemes/
have the same format.
David
Re: Re: Re: Re: Programmatic color scheme change in QKdeTheme
Am Dienstag, 11. März 2025, 14:44 schrieb Axel Spoerl: > Asking differently: How can a Qt application make sure, that KdePlatformTheme > is used? Nothing, it happens automatically. Our Theme has key: "kde" matching to XDG_CURRENT_DESKTOP https://invent.kde.org/plasma/plasma-integration/-/blob/master/qt6/src/platformtheme/kdeplatformtheme.json?ref_type=heads QGuiApplication will first try to load a matching plugin directly only afterwards via QPlatformIntegration::createPlatformTheme which calls QGenericUnixTheme::createUnixTheme https://invent.kde.org/qt/qt/qtbase/-/blob/dev/src/gui/kernel/qguiapplication.cpp#L1369 David
Re: Programmatic color scheme change in QKdeTheme
Hi Alex, Am Montag, 10. März 2025, 16:49 schrieb Axel Spoerl: > Hi KDE folks, > > Qt 6.8 has implemented QPlatformTheme::requestColorScheme() as a virtual > function. It is meant to allow a programmatic color scheme change within a > QGuiApplication. If the system's theme is dark, the application can still be > light and vice versa. > https://codereview.qt-project.org/c/qt/qtbase/+/628010 re-implements this > function in QKdeTheme. In case of a deviation (requested color scheme != > system color scheme), it falls back to a fusion palette (of which a dark and > a light version exist). > Do you think it would be helpful if we would give you the palettes that result when using Breeze and Breeze Dark colors that you could use instead of fusion? Also thanks for the heads up, maybe it's something we need to implement in our own QPlatformTheme. David
Re: Re: Programmatic color scheme change in QKdeTheme
Hi David, thanks for the insight! The program would be ideal. However, it depends on KDE libraries. If an application links to KDE anyway, it can simply use the KDE platform theme. Users of QKdeTheme are e.g. applications that don't link to KDE, because they need to run on Gnome environments as well. If we wanted to propagate palettes to QKdeTheme, we would have to read them directly from settings without having to link to KDE. Cheers Axel From: David Redondo Sent: Tuesday, 11 March 2025 09:39 To: kde-devel@kde.org Cc: Axel Spoerl Subject: Re: Re: Programmatic color scheme change in QKdeTheme [You don't often get email from da...@david-redondo.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Am Montag, 10. März 2025, 19:24 schrieb Axel Spoerl: > Hi David, > > I just did some debugging to find out, how KDE Palettes are promoted to the > QKdeTheme. > The blunt answer is: They don't, and they have never been. > > They were probably meant to be promoted at some point, because QKdeTheme > implements an array of QPalette pointers (size == NPalettes == 17). > So for each palette type, a new QPalette could be constructed from a KDE > Palette. But that's not happening. The first record of the array is populated > with default constructed QPalette, which is a fusion palette. > All other records are initialized with nullptr and they remain like that > throughout the life time of the QGuiApplication. > > QKdeTheme just implements font handling. Color wise, QGuiApplications won't > blend in with KDE palettes. They just stick with a default fusion palette. > > That said: I think there's nothing needed right now. But we may want to pimp > up QKdeTheme. > The patch I mentioned factors it out from qgenericunixthemes.cpp. So > enhancing the class will become a little easier. > Maybe a reason that it doesn't do that much was that Plasma has its own QPT, so there was never enough pressure to make it better since in the most cases an application would not use QKDETheme except if it shipped its own Qt or something similar. I've written very small program that prints the resulting QPalette from color schemes. The output for BreezeLight and BreezeDark is as follows: /usr/share/color-schemes/BreezeLight.colors QPalette(resolve=0x7ffdef7f,"WindowText:[Active:#ff232629,Disabled:#ffa0a1a3,Inactive:#ff232629],Button:[Active:#fffcfcfc,Disabled:#fff0f0f0,Inactive:#fffcfcfc],Light:[Active:#,Disabled:#,Inactive:#],Midlight:[Active:#fff6f7f7,Disabled:#ffebedee,Inactive:#fff6f7f7],Dark:[Active:#ff888e93,Disabled:#ff82878c,Inactive:#ff888e93],Mid:[Active:#ffc4c8cc,Disabled:#ffbbc0c5,Inactive:#ffc4c8cc],Text:[Active:#ff232629,Disabled:#ffaaabac,Inactive:#ff232629],ButtonText:[Active:#ff232629,Disabled:#ffa8a9aa,Inactive:#ff232629],Base:[Active:#,Disabled:#fff3f3f3,Inactive:#],Window:[Active:#ffeff0f1,Disabled:#ffe3e5e7,Inactive:#ffeff0f1],Shadow:[Active:#ff474a4c,Disabled:#ff474a4c,Inactive:#ff474a4c],Highlight:[Active:#ff3daee9,Disabled:#ffe3e5e7,Inactive:#ffc2e0f5],HighlightedText:[Active:#,Disabled:#ffa0a1a3,Inactive:#ff232629],Link:[Active:#ff2980b9,Disabled:#ffa3cae2,Inactive:#ff2980b9],LinkVisited:[Active:#ff9b59b6,Disabled:#ffd6bae1,Inactive:#ff9b59b6],AlternateBase:[Active:#fff7f7f7,Disabled:#ffebebeb,Inactive:#fff7f7f7],ToolTipBase:[Active:#fff7f7f7,Disabled:#fff7f7f7,Inactive:#fff7f7f7],ToolTipText:[Active:#ff232629,Disabled:#ff232629,Inactive:#ff232629],PlaceholderText:[Active:#ff707d8a,Disabled:#ffc2c8ce,Inactive:#ff707d8a],Accent:[Active:#ff3daee9,Disabled:#ffe3e5e7,Inactive:#ffc2e0f5]") /usr/share/color-schemes/BreezeDark.colors QPalette(resolve=0x7ffdef7f,"WindowText:[Active:#fffcfcfc,Disabled:#ff686a6c,Inactive:#fffcfcfc],Button:[Active:#ff292c30,Disabled:#ff272a2e,Inactive:#ff292c30],Light:[Active:#ff393e43,Disabled:#ff383d42,Inactive:#ff393e43],Midlight:[Active:#ff2e3337,Disabled:#ff2d3136,Inactive:#ff2e3337],Dark:[Active:#ff131516,Disabled:#ff121415,Inactive:#ff131516],Mid:[Active:#ff1c1f21,Disabled:#ff1b1d20,Inactive:#ff1c1f21],Text:[Active:#fffcfcfc,Disabled:#ff606263,Inactive:#fffcfcfc],ButtonText:[Active:#fffcfcfc,Disabled:#ff6d6f72,Inactive:#fffcfcfc],Base:[Active:#ff141618,Disabled:#ff131517,Inactive:#ff141618],Window:[Active:#ff202326,Disabled:#ff1f2124,Inactive:#ff202326],Shadow:[Active:#ff0e0f10,Disabled:#ff0d0e0f,Inactive:#ff0e0f10],Highlight:[Active:#ff3daee9,Disabled:#ff1f2124,Inactive:#ff1b4155],HighlightedText:[Active:#fffcfcfc,Disabled:#ff686a6c,Inactive:#fffcfcfc],Link:[Active:#ff1d99f3,Disabled:#ff164160,Inactive:#ff1d99f3],LinkVisited:[Active:#ff9b59b6,Disabled:#ff402b4c,Inactive:#ff9b59b6],AlternateBase:[Active:#ff1d1f22,Disabled:#ff1c1e20,Inactive:#ff1d1f22],ToolTipBase:[Active:#ff292c30,Disabled:#ff292c30,Inactive:#ff292c30],ToolTipText:[Active:#fffcfcfc,Disabled:#fffcfcfc,Inactive:#fffcfcfc],PlaceholderText:[Active:#ffa1a9b1,Disabled:#ff42464a,Inactive
Programmatic color scheme change in QKdeTheme
Hi KDE folks, Qt 6.8 has implemented QPlatformTheme::requestColorScheme() as a virtual function. It is meant to allow a programmatic color scheme change within a QGuiApplication. If the system's theme is dark, the application can still be light and vice versa. https://codereview.qt-project.org/c/qt/qtbase/+/628010 re-implements this function in QKdeTheme. In case of a deviation (requested color scheme != system color scheme), it falls back to a fusion palette (of which a dark and a light version exist). The patch is tested, but not yet approved. I'd highly appreciate your reviews. Cheers Axel
[ANNOUNCE] CMake 4.0.0-rc4 is ready for testing
I am proud to announce the fourth CMake 4.0 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v4.0 Release notes appear below and are also published at https://cmake.org/cmake/help/v4.0/release/4.0.html Release milestone is available at: https://gitlab.kitware.com/cmake/cmake/-/milestones/160 Some of the most significant changes in CMake 4.0 are: * The "CMAKE_POLICY_VERSION_MINIMUM" variable was added to help packagers and end users try to configure existing projects that have not been updated to work with supported CMake versions. The "CMAKE_POLICY_VERSION_MINIMUM" environment variable was added to initialize it. * The "$" generator expression gained the "NATIVE_PATH" operation to convert a CMake path into a native one. * Compatibility with versions of CMake older than 3.5 has been removed. Calls to "cmake_minimum_required()" or "cmake_policy()" that set the policy version to an older value now issue an error. Note that calls to those commands can still support older versions of CMake by using their "VERSION" arguments' "..." syntax. This requires only the "" version of CMake, but when running a newer version, sets policies up to the "" version. * On macOS with Ninja Generators and Makefile Generators, when a compiler is found in "/usr/bin", it is now used as-is and is no longer mapped to the corresponding compiler inside Xcode. * Builds targeting macOS no longer choose any SDK or pass an "-isysroot" flag to the compiler by default. Instead, compilers are expected to choose a default macOS SDK on their own. In order to use a compiler that does not do this, users must now specify "-DCMAKE_OSX_SYSROOT=macosx" when configuring their build. * Precompiled SunOS sparc64 and x86_64 binaries are now provided on cmake.org. CMake 4.0 Release Notes *** Changes made since CMake 3.31 include the following. New Features File-Based API -- * The "cmake-file-api(7)" "codemodel" version 2 "version" field has been updated to 2.8. * The "cmake-file-api(7)" "codemodel" version 2 "target" object gained a new "debugger" field. Command-Line * The "cmake --link-no-warning-as-error" option was added to suppress the effects of the "LINK_WARNING_AS_ERROR" target property and "CMAKE_LINK_WARNING_AS_ERROR" variable. * The "cmake --project-file" option was added to specify an alternate filename for "CMakeLists.txt" files. This is intended for temporary use by developers during an incremental transition and not for publication of a final product. CMake will always emit a warning when the project file is anything other than "CMakeLists.txt". Commands * The "target_link_libraries()" command now supports the "LINKER:" prefix. Variables - * The "AIX" and "CMAKE_HOST_AIX" variables are now set to true when the target or host system is AIX, respectively. * Linker flag variables learned to support the "LINKER:" prefix: * "CMAKE_EXE_LINKER_FLAGS" * "CMAKE_EXE_LINKER_FLAGS_" * "CMAKE_SHARED_LINKER_FLAGS" * "CMAKE_SHARED_LINKER_FLAGS_" * "CMAKE_MODULE_LINKER_FLAGS" * "CMAKE_MODULE_LINKER_FLAGS_" See policy "CMP0181". * The "CMAKE_EXECUTE_PROCESS_COMMAND_ERROR_IS_FATAL" variable was added to specify the "execute_process()" command's default "COMMAND_ERROR_IS_FATAL" behavior. * The "CMAKE__LINK_MODE" and "CMAKE__DEVICE_LINK_MODE" variables were added to provide information on how the link step is done. * The "CMAKE_LINK_WARNING_AS_ERROR" variable and corresponding "LINK_WARNING_AS_ERROR" target property were added to link using a linker-specific flag to treat warnings as errors. * The "CMAKE_MSVC_RUNTIME_CHECKS" variable and "MSVC_RUNTIME_CHECKS" target property were introduced to select runtime checks for compilers targeting the MSVC ABI. See policy "CMP0184". * The "CMAKE_POLICY_VERSION_MINIMUM" variable was added to help packagers and end users try to configure existing projects that have not been updated to work with supported CMake versions. The "CMAKE_POLICY_VERSION_MINIMUM" environment variable was added to initialize it. * The "CMAKE_XCODE_SCHEME_LLDB_INIT_FILE" variable and corresponding "XCODE_SCHEME_LLDB_INIT_FILE" target property were added to tell the "Xcode" generator what to put in the scheme's "LLDB Init File" setting. * The "CMAKE_XCODE_SCHEME_TEST_CONFIGURATION" variable and corresponding "XCODE_SCHEME_TEST_CONFIGURATION" target property were added to tell the "Xcode" generator what to put in the scheme's "Build Configuration" setting for the test action. Properties -- * The "DEBUGGER_WORKING_DIRECTORY" target property and corresponding "CMAKE_DEBUGGER_WORKING_DIRECTORY" variable were added to tell generators what debugger working directory should be set for targets. * The "STATIC_LIBRARY_OPTIONS" target property now support
KDE Gear projects with failing CI (master) (11 March 2025)
Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Bad news: 2 repostories have started failing korganizer - NEW * https://invent.kde.org/pim/korganizer/-/pipelines/908511 * Windows tests fail kdevelop - NEW * https://invent.kde.org/kdevelop/kdevelop/-/pipelines/907992 * freebsd dependencies missing? Cheers, Albert
