Re: Determining KDE Version for Script Compatibility
Justin, thanks a lot, this really helped, I hope the field naming when running kinfo doesn't change in future versions. Best regards, Daniel Кому: kde-devel@kde.org (kde-devel@kde.org);Тема: Determining KDE Version for Script Compatibility;05.03.2025, 05:57, "Justin Zobel" :The 'kinfo' command which is part of the 'kinfocenter' package *should* be pre-installed on any Plasma install can give you the following info. This includes 'KDE Plasma Version: 6.3.80' which you can use to determine what version of Plasma they are running. Alternatively, if the OS is all the same, look at the package info. For example "dnf list --installed | grep ^plasma-desktop.x86_64"kinfoOperating System: KDE Linux 202503040256KDE Plasma Version: 6.3.80KDE Frameworks Version: 6.12.0Qt Version: 6.8.2Kernel Version: 6.13.5-arch1-1 (64-bit)Graphics Platform: WaylandProcessors: 16 x AMD Ryzen 7 PRO 4750U with Radeon GraphicsMemory: 32 GiB of RAM (29.1 GiB usable)Graphics Processor: AMD Radeon GraphicsJustinOn 3/5/25 00:15, Данила Скачедубов wrote:Dear KDE Community,I hope this message finds you well. I am writing to seek advice on determining the KDE version programmatically in my Python scripts.In my scripts, I have been using the kwriteconfig5 command to configure KDE settings. However, with the release of KDE 6, the binary name has changed to kwriteconfig6. Since my scripts run on various versions of KDE, I need a reliable way to determine the installed KDE version without relying on session environment variables.I am wondering if there is a method using D-Bus or a configuration file that stores this information. Any guidance or suggestions on how to achieve this would be greatly appreciated.Thank you for your time and assistance.Best regards,Daniel
[ANNOUNCE] CMake 4.0.0-rc3 is ready for testing
I am proud to announce the third 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 supports
Incubation Request for QXmpp
Hi everyone, I'd like to incubate QXmpp to KDE. I created a repo and issue on invent: https://invent.kde.org/lnj/qxmpp-incubation/-/issues/1 **I'm looking for a sponsor to do the incubation process with me! :)** Details about the project: QXmpp (https://qxmpp.org) is an XMPP chat library for creating XMPP clients and servers. It is used by https://invent.kde.org/network/kaidan for example. Active maintainers: Only me currently (previously others, since 2020 I took over the project from https://github.com/jlaine (and also the domain qxmpp.org). In the past two years there were 498 commits by me, 91 commits by @melvo, 24 by @fazevedo and 13 commits by 7 other contributors. I'd like to move the project to invent to benefit from the CI and to ensure development can continue even if I am absent. Ben Cooksley also suggested incubating QXmpp since Kaidan usually needs the latest QXmpp version and having QXmpp on invent would simplify the process. Thanks in advance! Cheers, Linus Hi everyone,I'd like to incubate QXmpp to KDE. I created a repo and issue on invent:https://invent.kde.org/lnj/qxmpp-incubation/-/issues/1**I'm looking for a sponsor to do the incubation process with me! :)**Details about the project:QXmpp (https://qxmpp.org) is an XMPP chat library for creating XMPPclients and servers.It is used by https://invent.kde.org/network/kaidan for example.Active maintainers: Only me currently (previously others, since 2020 I took over the project from https://github.com/jlaine (and also the domain qxmpp.org).In the past two years there were 498 commits by me, 91 commits by@melvo, 24 by @fazevedo and 13 commits by 7 other contributors. I'dlike to move the project to invent to benefit from the CI and to ensuredevelopment can continue even if I am absent.Ben Cooksley also suggested incubating QXmpp since Kaidan usually needsthe latest QXmpp version and having QXmpp on invent would simplify theprocess.Thanks in advance!Cheers,Linus
Re: Determining KDE Version for Script Compatibility
On Tuesday, 4 March 2025 05:45:58 Pacific Standard Time Данила Скачедубов wrote: > In my scripts, I have been using the kwriteconfig5 command to configure KDE > settings. However, with the release of KDE 6, the binary name has changed > to kwriteconfig6. And why can't you try to run both, and settle for the one that works? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
