Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2023-04-07T15:37:03Zhttps://invent.kde.org/plasma/breeze-gtk/-/issues/9Window decoration buttons getting bigger with 5.27.42023-04-07T15:37:03Zkkkk mpWindow decoration buttons getting bigger with 5.27.4Please check it out.
(There is not only flathub issue)
https://github.com/flathub/org.gtk.Gtk3theme.Breeze/issues/100
Probable it's fault of ~77 line 18px changed to 24px here
`src/gtk3/widgets/_window_decorations.scss`
![image](/up...Please check it out.
(There is not only flathub issue)
https://github.com/flathub/org.gtk.Gtk3theme.Breeze/issues/100
Probable it's fault of ~77 line 18px changed to 24px here
`src/gtk3/widgets/_window_decorations.scss`
![image](/uploads/5ce1765e3b9cecb8fd42cd55a60e1097/image.png)
Before
![image](/uploads/02e028044840d07afbc5da979a8d6797/image.png)
After
![image](/uploads/715fc2493b69122d49bbd5c8851a013b/image.png)https://invent.kde.org/plasma/powerdevil/-/issues/17Remove backend plugins2024-01-26T19:55:04ZNicolas FellaRemove backend pluginsTheoretically Powerdevil supports different backends via a plugin system. In practice there is only the upower backend.
That's not going to change any time soon, and if it does there is no guarantee that the existing backend interface i...Theoretically Powerdevil supports different backends via a plugin system. In practice there is only the upower backend.
That's not going to change any time soon, and if it does there is no guarantee that the existing backend interface is suitable or helpful.
By removing the plugin system code we could potentially clean up the internals a bithttps://invent.kde.org/plasma/powerdevil/-/issues/16How and when to use mobile power settings?2023-09-27T16:42:19ZNicolas FellaHow and when to use mobile power settings?https://invent.kde.org/plasma/powerdevil/-/commit/519dc0c442a85f2ef7f026728586b00cac712631 introduced some Plasma Mobile specific tweaks to the default powerdevil config, like different timeout values for screen lock and suspend, and loc...https://invent.kde.org/plasma/powerdevil/-/commit/519dc0c442a85f2ef7f026728586b00cac712631 introduced some Plasma Mobile specific tweaks to the default powerdevil config, like different timeout values for screen lock and suspend, and locking the screen when the power button is pressed instead of suspending.
On first start powerdevil generates a new profile with specific values for everything, depending on whether we are mobile or not. Whether or not we are mobile is checked using the `QT_QUICK_CONTROLS_MOBILE` environment variable.
https://invent.kde.org/plasma/powerdevil/-/merge_requests/68 changed this to use the tablet mode instead, with https://invent.kde.org/plasma/powerdevil/-/merge_requests/143 fixing it up. This is somewhat problematic. Tablet mode is not a static thing, it changes depending on the state of the hardware. However, the profile generation only happens once, and if the device was in tablet mode we will get mobile settings forever. For phones this is not a problem, but if you have a laptop in tablet mode during first boot you get the "wrong" set of settings.
Furthermore, the fact that we generate a profile config on first run is bad in itself. It goes against how KConfig generally works and makes it impossible for us to change defaults for users that haven't changed their settings, or distros/admins to provide their own defaults using config inheritance. By using KConfigXT (https://invent.kde.org/plasma/powerdevil/-/merge_requests/71) we are moving towards solving this, but that could cause a problem because then we would get different config values depending on whether or not we are *currently* in tablet mode, which is probably not what we want.
This raises the question: What is the proper way to detect "We are running Plasma Mobile on a phone" and use appropriate settings, without causing issues for convertible laptops?https://invent.kde.org/plasma/powerdevil/-/issues/15Are wireless power settings actually useful?2023-04-10T15:41:32ZNicolas FellaAre wireless power settings actually useful?The KCM allows to configure power management settings for various "wireless" controller hardware, namely Wifi, Mobile Broadband, and Bluetooth.
This allows to configure things like "Turn off bluetooth adapter when going from AC to batte...The KCM allows to configure power management settings for various "wireless" controller hardware, namely Wifi, Mobile Broadband, and Bluetooth.
This allows to configure things like "Turn off bluetooth adapter when going from AC to battery", presumably to reduce power consumption.
Is this actually a thing people do? Presumably not, because when I need to use Wifi/Bluetooth/Broadband I use them, regardless of whether I am on AC or Battery. Or when battery is low I (try to) get a cable, and don't start turning off pieces of my hardware.
This appears like a feature with little to no practical relevance. If that's true let's drop it6https://invent.kde.org/plasma/kwin/-/issues/147Improving parallelization of the blur effect2023-04-06T09:38:05ZXaver HuglImproving parallelization of the blur effectCurrently, the blur effect works like this:
1. copy part of the main framebuffer to an offscreen texture
2. do the blur steps
3. copy it back to the main framebuffer
Step 1 hides something though: It needs to make the GPU wait for rende...Currently, the blur effect works like this:
1. copy part of the main framebuffer to an offscreen texture
2. do the blur steps
3. copy it back to the main framebuffer
Step 1 hides something though: It needs to make the GPU wait for rendering to be complete before it can copy from the framebuffer. When multiple blur regions are involved, that waiting happens for each one of them, even if they don't overlap.
I propose that the blur effect should use a different approach, which avoids that serialization:
1. render everything below the window into an offscreen framebuffer
2. do the blur steps
3. render the blurred image to the main framebuffer
This would improve parallelization a bunch and thus reduce the time needed for rendering, as it allows the GPU to handle rendering of the main scene and of each blur region separately. It would also increase CPU and GPU usage a bit, as the scene renders the bits below blurred windows that afterwards just get painted over by the blur effect, but that should be possible to fix.
As another advantage, it would also fix the issues mentioned #115, as the effect can then render any unblurred parts below the window that it needs at any time.6https://invent.kde.org/plasma/plasma-systemmonitor/-/issues/25Not all disks appearing in list of sensors2023-04-05T13:56:24ZJohn VeitchNot all disks appearing in list of sensorsI have an issue that not all my disks are appearing in the drop-down menu when trying to add sensors for Read/Write (or any other disk properties). The devices are visible in KInfoCenter. I am not sure where plasma-system-monitor gets th...I have an issue that not all my disks are appearing in the drop-down menu when trying to add sensors for Read/Write (or any other disk properties). The devices are visible in KInfoCenter. I am not sure where plasma-system-monitor gets the information for the list of disks from?
I am a long-term Linux and KDE user and happy to help debug/solve this if you have any suggestions for investigation.https://invent.kde.org/plasma/kwin/-/issues/146Merge contents of effects/, scripts/ and plugins/2023-10-24T20:46:10ZVlad ZahorodniiMerge contents of effects/, scripts/ and plugins/Extensions are divided in three categories: effects, scripts, and binary plugins. This creates a separation, which is reflected in the associated APIs. For example, effects must use only the things available in libkwineffects, scripts ca...Extensions are divided in three categories: effects, scripts, and binary plugins. This creates a separation, which is reflected in the associated APIs. For example, effects must use only the things available in libkwineffects, scripts can only use whatever is exposed in the workspace wrapper + window, binary plugins have only a few restrictions. It gets worse when the line between them gets blurry, for example that's what we see in the declarative effects that use the things available in libkwineffects and also normal scripting APIs, there's `EffectScreen` and `Output`, `VirtualDesktop` and `uint`-based virtual desktop ids, etc.
It would be great to unify the extensions to simplify the plugin api. For example, the effects could use the existing infrastructure in scripting or binary plugins but with a couple of new classes or functions to start/register effects, e.g.
```js
class MyEffect extends Effect {
};
Compositor.registerEffect(MyEffect);
Workspace.windowAdded.connect(window => console.log(window.caption, "was added");
```
As the first step, it's worth merging effects/, plugins/ and scripts/ directories like what we did with the backends. We would need to be careful with translations. After that, it's worth exploring exposing effect specific APIs in the normal scripting API.https://invent.kde.org/plasma/kwayland/-/issues/3Qt6::WaylandClientPrivate not exist in qt62023-04-16T11:27:30ZHongfei ShangQt6::WaylandClientPrivate not exist in qt6```bash
[main] Building folder: kwayland
[main] Configuring project: kwayland
[proc] Executing command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FI...```bash
[main] Building folder: kwayland
[main] Configuring project: kwayland
[proc] Executing command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++ -S/home/kylin/projects/kde-upstream/kwayland -B/home/kylin/projects/kde-upstream/kwayland/build-cmake -G Ninja
[cmake] Not searching for unused variables given on the command line.
[cmake] -- The C compiler identification is GNU 12.2.0
[cmake] -- The CXX compiler identification is GNU 12.2.0
[cmake] -- Detecting C compiler ABI info
[cmake] -- Detecting C compiler ABI info - done
[cmake] -- Check for working C compiler: /usr/bin/gcc - skipped
[cmake] -- Detecting C compile features
[cmake] -- Detecting C compile features - done
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - done
[cmake] -- Check for working CXX compiler: /usr/bin/g++ - skipped
[cmake] -- Detecting CXX compile features
[cmake] -- Detecting CXX compile features - done
[cmake] --
[cmake]
[cmake] Installing in /usr/local. Run /home/kylin/projects/kde-upstream/kwayland/build-cmake/prefix.sh to set the environment for KWayland.
[cmake] -- Performing Test HAVE_STDATOMIC
[cmake] -- Performing Test HAVE_STDATOMIC - Success
[cmake] -- Found WrapAtomic: TRUE
[cmake] -- Looking for __GLIBC__
[cmake] -- Looking for __GLIBC__ - found
[cmake] -- Performing Test _OFFT_IS_64BIT
[cmake] -- Performing Test _OFFT_IS_64BIT - Success
[cmake] -- Performing Test HAVE_DATE_TIME
[cmake] -- Performing Test HAVE_DATE_TIME - Success
[cmake] -- Performing Test BSYMBOLICFUNCTIONS_AVAILABLE
[cmake] -- Performing Test BSYMBOLICFUNCTIONS_AVAILABLE - Success
[cmake] -- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so
[cmake] -- Found WrapOpenGL: TRUE
[cmake] -- Found XKB: /usr/lib/x86_64-linux-gnu/libxkbcommon.so (found suitable version "1.5.0", minimum required is "0.5.0")
[cmake] -- Found WrapVulkanHeaders: /usr/include
[cmake] -- Found Threads: TRUE
[cmake] -- Found Wayland_Client: /usr/lib/x86_64-linux-gnu/libwayland-client.so (found version "1.21.93")
[cmake] -- Found Wayland_Server: /usr/lib/x86_64-linux-gnu/libwayland-server.so (found version "1.21.93")
[cmake] -- Found Wayland_Cursor: /usr/lib/x86_64-linux-gnu/libwayland-cursor.so (found version "1.21.93")
[cmake] -- Found Wayland_Egl: /usr/lib/x86_64-linux-gnu/libwayland-egl.so (found version "18.1.0")
[cmake] -- Found Wayland: /usr/lib/x86_64-linux-gnu/libwayland-client.so;/usr/lib/x86_64-linux-gnu/libwayland-server.so;/usr/lib/x86_64-linux-gnu/libwayland-cursor.so;/usr/lib/x86_64-linux-gnu/libwayland-egl.so (found suitable version "1.21.93", minimum required is "1.15")
[cmake] -- Found Wayland: /usr/lib/x86_64-linux-gnu/libwayland-client.so;/usr/lib/x86_64-linux-gnu/libwayland-server.so;/usr/lib/x86_64-linux-gnu/libwayland-cursor.so;/usr/lib/x86_64-linux-gnu/libwayland-egl.so (found version "1.21.93")
[cmake] -- Found WaylandScanner: /usr/bin/wayland-scanner
[cmake] -- Found Wayland: /usr/lib/x86_64-linux-gnu/libwayland-client.so;/usr/lib/x86_64-linux-gnu/libwayland-server.so;/usr/lib/x86_64-linux-gnu/libwayland-cursor.so;/usr/lib/x86_64-linux-gnu/libwayland-egl.so (found suitable version "1.21.93", minimum required is "1.15") found components: Client
[cmake] -- Found WaylandProtocols: //usr/share/wayland-protocols (found suitable version "1.31", minimum required is "1.15")
[cmake] -- Performing Test HAVE_EGL
[cmake] -- Performing Test HAVE_EGL - Success
[cmake] -- Found EGL: /usr/include (found version "1.5")
[cmake] -- Performing Test HAVE_MEMFD
[cmake] -- Performing Test HAVE_MEMFD - Success
[cmake] -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
[cmake] -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
[cmake] -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
[cmake] -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
[cmake] -- Performing Test COMPILER_HAS_DEPRECATED_ATTR
[cmake] -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
[cmake] -- The weston executable was not found. Some autotests will not be executed.
[cmake] -- The following OPTIONAL packages have been found:
[cmake]
[cmake] * Qt6CoreTools (required version >= 6.4.2)
[cmake] * Qt6Core
[cmake] * OpenGL
[cmake] * XKB (required version >= 0.5.0), XKB API common to servers and clients., <http://xkbcommon.org>
[cmake] * WrapVulkanHeaders
[cmake] * Qt6GuiTools (required version >= 6.4.2)
[cmake] * Qt6DBusTools (required version >= 6.4.2)
[cmake] * Qt6Concurrent (required version >= 6.4.0)
[cmake] * Qt6WaylandScannerTools (required version >= 6.4.2)
[cmake] * WaylandScanner, Executable that converts XML protocol files to C code, <https://wayland.freedesktop.org/>
[cmake] * Qt6Test (required version >= 6.4.0)
[cmake]
[cmake] -- The following REQUIRED packages have been found:
[cmake]
[cmake] * ECM (required version >= 5.240.0), Extra CMake Modules., <https://commits.kde.org/extra-cmake-modules>
[cmake] * Qt6Gui (required version >= 6.4.0)
[cmake] * Qt6WaylandClient (required version >= 6.4.0)
[cmake] * Wayland (required version >= 1.15), C library implementation of the Wayland protocol: a protocol for a compositor to talk to its clients, <https://wayland.freedesktop.org/>
[cmake] * WaylandProtocols (required version >= 1.15), Specifications of extended Wayland protocols, <https://wayland.freedesktop.org/>
[cmake] * EGL, A platform-agnostic mechanism for creating rendering surfaces for use with other graphics libraries, such as OpenGL|ES and OpenVG., <https://www.khronos.org/egl/>
[cmake] * PlasmaWaylandProtocols (required version >= 1.9.0)
[cmake] * Qt6 (required version >= 6.4.0)
[cmake]
[cmake] -- The following features have been disabled:
[cmake]
[cmake] * QCH, API documentation in QCH format (for e.g. Qt Assistant, Qt Creator & KDevelop)
[cmake]
[cmake] CMake Warning at /usr/local/share/ECM/kde-modules/KDEGitCommitHooks.cmake:84 (message):
[cmake] No clang-format executable was found, skipping the formatting pre-commit
[cmake] hook
[cmake] Call Stack (most recent call first):
[cmake] CMakeLists.txt:131 (kde_configure_git_pre_commit_hook)
[cmake]
[cmake]
[cmake] -- Configuring done
[cmake] CMake Error in src/client/CMakeLists.txt:
[cmake] Imported target "Qt6::WaylandClientPrivate" includes non-existent path
[cmake]
[cmake] "/usr/include/x86_64-linux-gnu/qt6/QtWaylandClient/6.4.2"
[cmake]
[cmake] in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
[cmake]
[cmake] * The path was deleted, renamed, or moved to another location.
[cmake]
[cmake] * An install or uninstall procedure did not complete successfully.
[cmake]
[cmake] * The installation package was faulty and references files it does not
[cmake] provide.
[cmake]
[cmake]
[cmake]
[cmake] CMake Error in src/client/CMakeLists.txt:
[cmake] Imported target "Qt6::WaylandClientPrivate" includes non-existent path
[cmake]
[cmake] "/usr/include/x86_64-linux-gnu/qt6/QtWaylandClient/6.4.2"
[cmake]
[cmake] in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
[cmake]
[cmake] * The path was deleted, renamed, or moved to another location.
[cmake]
[cmake] * An install or uninstall procedure did not complete successfully.
[cmake]
[cmake] * The installation package was faulty and references files it does not
[cmake] provide.
[cmake]
[cmake]
[cmake]
[cmake] CMake Error in src/client/CMakeLists.txt:
[cmake] Imported target "Qt6::WaylandClientPrivate" includes non-existent path
[cmake]
[cmake] "/usr/include/x86_64-linux-gnu/qt6/QtWaylandClient/6.4.2"
[cmake]
[cmake] in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
[cmake]
[cmake] * The path was deleted, renamed, or moved to another location.
[cmake]
[cmake] * An install or uninstall procedure did not complete successfully.
[cmake]
[cmake] * The installation package was faulty and references files it does not
[cmake] provide.
[cmake]
[cmake]
[cmake]
[cmake] -- Generating done
[cmake] CMake Generate step failed. Build files cannot be regenerated correctly.
[proc] The command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++ -S/home/kylin/projects/kde-upstream/kwayland -B/home/kylin/projects/kde-upstream/kwayland/build-cmake -G Ninja exited with code: 1
```https://invent.kde.org/plasma/oxygen-sounds/-/issues/1Qt6 Build2023-10-31T13:16:07ZJustin ZobelQt6 BuildThis is one of the last few Plasma repositories to get a Qt6 build.This is one of the last few Plasma repositories to get a Qt6 build.https://invent.kde.org/plasma/plasma-mobile/-/issues/247Since porting to libkwineffects mobiletaskswitchereffect.h cannot find kwinqu...2023-04-12T20:06:07ZCarlos De MaineSince porting to libkwineffects mobiletaskswitchereffect.h cannot find kwinquickeffect.h on neon unstable buildsfull build details at:
https://build.neon.kde.org/job/jammy_unstable_mobile_plasma-mobile_bin_amd64/260/consoleFull
kwin-dev installs all source includes into /usr/kf6/include/libkwineffects/
cmake finds kwineffects:
-- The following R...full build details at:
https://build.neon.kde.org/job/jammy_unstable_mobile_plasma-mobile_bin_amd64/260/consoleFull
kwin-dev installs all source includes into /usr/kf6/include/libkwineffects/
cmake finds kwineffects:
-- The following REQUIRED packages have been found:
* KWinEffects (required version >= 5.27.80)
but compilation bombs out with:
workspace/build/kwin/mobiletaskswitcher/mobiletaskswitchereffect.h:7:10: fatal error: libkwineffects/kwinquickeffect.h: No such file or directoryDevin LinDevin Linhttps://invent.kde.org/plasma/systemsettings/-/issues/26Port ExternalAppModule to QML2024-03-26T20:04:22ZOliver BeardPort ExternalAppModule to QMLAs part of the transition to QML KCMs over Qt Widgets, this would need to be replaced with QML. Ideally, I would imagine this using a PlaceholderMessage.
It seems the only uses are System Monitor in KInfoCenter (and YaST in System Setti...As part of the transition to QML KCMs over Qt Widgets, this would need to be replaced with QML. Ideally, I would imagine this using a PlaceholderMessage.
It seems the only uses are System Monitor in KInfoCenter (and YaST in System Settings? `kcmutils/autotests/YaST-systemsettings.desktop`).
An alternative approach to creating a QML UI might be to remove this feature entirely and create shallow KCMs for when we want to link to an external application. It could even be a Kirigami KCM type. It seems like we only really want to do this for System Monitor, and maybe we don't want links to non-Plasma/KDE applications at all. If the end goal is to replace System Settings with Plasma Mobile's plasma-settings, then this might be easiest.
@sitterOliver BeardOliver Beardhttps://invent.kde.org/plasma/plasma-mobile/-/issues/246[homescreens/folio] Configuration panel does not open when holding on the screen2023-10-23T05:52:48ZDevin Lin[homescreens/folio] Configuration panel does not open when holding on the screen(This is a git master issue for Plasma 6)
The wallpaper/containment selector does not open when holding on the screen.(This is a git master issue for Plasma 6)
The wallpaper/containment selector does not open when holding on the screen.6https://invent.kde.org/plasma/plasma-mobile/-/issues/245[homescreens/folio] Crashes when pinning an app to homescreen2023-10-23T05:52:58ZDevin Lin[homescreens/folio] Crashes when pinning an app to homescreen(This is a git master issue for Plasma 6)
Pinning an app to the homescreen crashes it.(This is a git master issue for Plasma 6)
Pinning an app to the homescreen crashes it.6https://invent.kde.org/plasma/plasma-welcome/-/issues/14Naming consistency2023-04-24T15:20:54ZOliver BeardNaming consistency`Welcome Center` is the name of the application. The repository's name should reflect that (bugzilla already does). ~~The URL should probably be `.../plasma/welcomecenter` for consistency with `systemsettings`.~~ At any rate, including P...`Welcome Center` is the name of the application. The repository's name should reflect that (bugzilla already does). ~~The URL should probably be `.../plasma/welcomecenter` for consistency with `systemsettings`.~~ At any rate, including Plasma in the ~~URL or~~ name is redundant as it belongs to the Plasma group.https://invent.kde.org/plasma/plasma-systemmonitor/-/issues/24Repository name redundancy2023-03-31T14:36:10ZOliver BeardRepository name redundancyThe repository's name, Plasma System Monitor is redundant. It belongs to the Plasma group, and should be called 'System Monitor'. Also, the URL should be changed to `.../plasma/systemmonitor/`. This would be consistent with System Settin...The repository's name, Plasma System Monitor is redundant. It belongs to the Plasma group, and should be called 'System Monitor'. Also, the URL should be changed to `.../plasma/systemmonitor/`. This would be consistent with System Settings, making the kdesrc-build name more obvious as `systemmonitor`.
I expect this would be slightly breaking but I think it makes things nicer.https://invent.kde.org/plasma/breeze-gtk/-/issues/8Prepare for breaking changes in GTK52023-03-30T13:05:30ZFushan WenPrepare for breaking changes in GTK5In GTK5, gtk.css and settings.ini are no longer supported. To support accent color, Breeze GTK will have to generate theme variants for different accent colors.
Example:
- https://github.com/ubuntu/yaru/commit/dd8e24239d2f80ca65e238a9b4...In GTK5, gtk.css and settings.ini are no longer supported. To support accent color, Breeze GTK will have to generate theme variants for different accent colors.
Example:
- https://github.com/ubuntu/yaru/commit/dd8e24239d2f80ca65e238a9b460a9def0d3cc6c6Fushan WenFushan Wenhttps://invent.kde.org/plasma/kde-gtk-config/-/issues/9Implement `org.gtk.Settings` interface2023-03-30T04:50:38ZFushan WenImplement `org.gtk.Settings` interfaceTo fix https://bugs.kde.org/show_bug.cgi?id=421745
```c
static const gchar introspection_xml[] =
"<node name='/org/gtk/Settings'>"
" <interface name='org.gtk.Settings'>"
" <property name='FontconfigTimestamp' type='x' access='read'/...To fix https://bugs.kde.org/show_bug.cgi?id=421745
```c
static const gchar introspection_xml[] =
"<node name='/org/gtk/Settings'>"
" <interface name='org.gtk.Settings'>"
" <property name='FontconfigTimestamp' type='x' access='read'/>"
" <property name='Modules' type='s' access='read'/>"
" <property name='EnableAnimations' type='b' access='read'/>"
" </interface>"
"</node>";
```5.27Fushan WenFushan Wenhttps://invent.kde.org/plasma/layer-shell-qt/-/issues/2if is possible to make qt5 layershell qt version coexist with qt6 version2023-10-31T13:17:52ZShooting Starif is possible to make qt5 layershell qt version coexist with qt6 versionI have install the qt5 version layershell on archlinux, and it cannot link to qt6 program.. I think if there can be a package to package both qt5 version and qt6 version.. but I have view the source, and seems it is difficult..I have install the qt5 version layershell on archlinux, and it cannot link to qt6 program.. I think if there can be a package to package both qt5 version and qt6 version.. but I have view the source, and seems it is difficult..https://invent.kde.org/plasma/kwin/-/issues/145libkwineffects header install location2023-04-02T01:30:00ZNicolas Fellalibkwineffects header install locationCurrently the headers for libkwineffects are installed directly to /usr/include, which is a bit "not nice". They should go to a subdirectory instead (and the relevant include dir set up for the CMake target)Currently the headers for libkwineffects are installed directly to /usr/include, which is a bit "not nice". They should go to a subdirectory instead (and the relevant include dir set up for the CMake target)https://invent.kde.org/plasma/kwin/-/issues/144Remove fake screen modes that don't work2023-04-10T09:09:34ZHector MartinRemove fake screen modes that don't workPrior to 9130b947e02, KWin generated common modes if there was only a single driver mode. It made no attempt to test that those modes are actually possible with the DRM KMS API, so users are presented with a list of fake modes that don't...Prior to 9130b947e02, KWin generated common modes if there was only a single driver mode. It made no attempt to test that those modes are actually possible with the DRM KMS API, so users are presented with a list of fake modes that don't work on platforms that can't support them (like Apple systems).
That commit extended the generation to systems with more than one driver mode, further regressing things and now affecting even more systems (e.g. those with a single resolution but multiple refresh rates).
KWin can't just make up modes out of thin air. If the monitor claims it doesn't support certain modes, you can't just assume it does. Even if KMS allowed the commit through, the unsupported mode might not work with the actual monitor. This whole idea of injecting "common" modes by default seems deeply flawed. If anything, this should be a quirk limited to specific monitors/systems, or only enabled via a hidden config option.
I'm happy to send a patch for this, but I need to know what the original intent was here because this makes no sense to me on the face of it.