Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2023-04-20T07:31:13Zhttps://invent.kde.org/plasma/kwin/-/issues/150kwin wayland screencapture buffer timestamps incorrect2023-04-20T07:31:13ZMarkus Ebnerkwin wayland screencapture buffer timestamps incorrectFor screencapturing under wayland, kwin opens a pipewire stream and pushes frames into it.
While working with it from the other side using GStreamer, I noticed that the buffer timestamps are borked (every buffer has the timestamp `0`).
...For screencapturing under wayland, kwin opens a pipewire stream and pushes frames into it.
While working with it from the other side using GStreamer, I noticed that the buffer timestamps are borked (every buffer has the timestamp `0`).
Apparently, this is because [pts](https://invent.kde.org/plasma/kwin/-/blob/master/src/plugins/screencast/screencaststream.cpp#L591) needs to be absolute, where absolute means the equivalent to: `clock_gettime(CLOCK_MONOTONIC, &ts)`. I think that's the clock counting nanoseconds since the computer was started. (Yeah, I also think that's weird...)
To test this, I patched kwin to not subtract the start timestamp and instead directly output the source's clock. That made it work :shrug_tone1:.
On the pipewire side:
- [Here](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3149) is the original issue of the problem
- [Here](https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/1593) is the discussion of kwin's "bug"https://invent.kde.org/plasma/plasma-mobile/-/issues/249Manual rotation via tiling menu2023-04-20T06:12:57ZSJ SJManual rotation via tiling menuCurrently, it is possible to manually rotate via dialog Display Configuration.
Because mobile devices may have the upper edge occupied by a(n ear) speaker, the best choice would be the orientation which id clockwise (right > bottom, bot...Currently, it is possible to manually rotate via dialog Display Configuration.
Because mobile devices may have the upper edge occupied by a(n ear) speaker, the best choice would be the orientation which id clockwise (right > bottom, bottom > left, left > top, top > right).
Phosh and SXMO offer this functionality.https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/9Portal architecture2024-02-28T08:36:48ZNicolas FellaPortal architectureCurrently the xdg-desktop-portal-kde process provides all the portal implementations on Plasma. It then often does DBus calls to other parts of Plasma, e.g. plasmashell (for notifications), KWin (screenshots/color picking), or kglobalacc...Currently the xdg-desktop-portal-kde process provides all the portal implementations on Plasma. It then often does DBus calls to other parts of Plasma, e.g. plasmashell (for notifications), KWin (screenshots/color picking), or kglobalacceld (global shortcuts).
My understanding is that it's possible to have different processes provides different parts of the portal interfaces. It might make sense for us to make use of that.
For example currently when receiving a notification on the `org.freedesktop.impl.portal.Notification` DBus interface we use KNotifications to create a notification, which internally makes a DBus call to `org.freedesktop.Notifications`, which ends up in plasmashell. plasmashell could directly implement the `org.freedesktop.impl.portal.Notification` API, cutting out the middle layer, which has caused trouble in the past (see e.g. https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/169)https://invent.kde.org/plasma/systemsettings/-/issues/27Add USB Tethering to dialog Hotspot2023-04-20T13:41:07ZSJ SJAdd USB Tethering to dialog HotspotAdd "Enabled" button for USB Tethering in dialog Hotspot.
Command:
```
nmcli connection add type ethernet ifname usb0 ipv4.method shared ipv6.method shared con-name "USB Tethering"
```
Please also see [SXMO patch](https://lists.sr.ht/~...Add "Enabled" button for USB Tethering in dialog Hotspot.
Command:
```
nmcli connection add type ethernet ifname usb0 ipv4.method shared ipv6.method shared con-name "USB Tethering"
```
Please also see [SXMO patch](https://lists.sr.ht/~mil/sxmo-devel/patches/37970#%3C20230104200811.153696-1-sjehuda@yandex.com%3E)
Unlike proprietary systems, on postmarketOS (and any Linux system), `nmcli` allows the following scenario.
Morris device > Mark's device > WiFi Router > Cables > ISP.
- Morris is connected to Mark's device.
- Mark is connected to WiFi and has executed `nmcli` as show above.
### Result
Morris is connected to the internet via Mark's device.
### Note
To Morris, Mark's device behaves like a WiFi dongle which appears to him as USB Ethernet.
This is very useful.
Reported also at https://invent.kde.org/plasma/plasma-mobile/-/issues/248https://invent.kde.org/plasma/plasma-mobile/-/issues/248Add USB Tethering to dialog Hotspot2023-04-20T13:36:22ZSJ SJAdd USB Tethering to dialog HotspotAdd "Enabled" button for USB Tethering in dialog Hotspot.
Command:
```
nmcli connection add type ethernet ifname usb0 ipv4.method shared ipv6.method shared con-name "USB Tethering"
```
Please also see [SXMO patch](https://lists.sr.ht/~...Add "Enabled" button for USB Tethering in dialog Hotspot.
Command:
```
nmcli connection add type ethernet ifname usb0 ipv4.method shared ipv6.method shared con-name "USB Tethering"
```
Please also see [SXMO patch](https://lists.sr.ht/~mil/sxmo-devel/patches/37970#%3C20230104200811.153696-1-sjehuda@yandex.com%3E)
Unlike proprietary systems, on postmarketOS (and any Linux system), `nmcli` allows the following scenario.
Morris device > Mark's device > WiFi Router > Cables > ISP.
- Morris is connected to Mark's device.
- Mark is connected to WiFi and has executed `nmcli` as show above.
### Result
Morris is connected to the internet via Mark's device.
### Note
To Morris, Mark's device behaves like a WiFi dongle which appears to him as USB Ethernet.
This is very useful.
Reported also at https://invent.kde.org/plasma/systemsettings/-/issues/27https://invent.kde.org/plasma/plasma-workspace/-/issues/66Unify cursor setting2023-04-19T15:04:41ZDavid RedondoUnify cursor settingCurrently we have multiple places to apply a cursor theme doing different things, all in all it's a mess.
- startplasma runs `kapplymousetheme` [[1]](https://invent.kde.org/plasma/plasma-workspace/-/blob/master/startkde/startplasma.cpp#...Currently we have multiple places to apply a cursor theme doing different things, all in all it's a mess.
- startplasma runs `kapplymousetheme` [[1]](https://invent.kde.org/plasma/plasma-workspace/-/blob/master/startkde/startplasma.cpp#L208) from the mouse kcm [[2]](https://invent.kde.org/plasma/plasma-desktop/-/blob/master/kcms/mouse/kapplymousetheme.cpp) which ends up calling [`X11Backend::applyCursorTheme`](https://invent.kde.org/plasma/plasma-desktop/-/blob/master/kcms/mouse/backends/x11/x11_backend.cpp#L85)
- the kcminit of the mouse kcm calls `X11Backend::applyCursorTheme` as well
- all of this runs only on X11
- Relevant calls it does
```c
XcursorSetTheme(m_dpy, QFile::encodeName(theme));
XcursorSetDefaultSize(m_dpy, size);
Cursor handle = XcursorLibraryLoadCursor(m_dpy, "left_ptr");
XDefineCursor(m_dpy, DefaultRootWindow(m_dpy), handle);
XFreeCursor(m_dpy, handle);
XFlush(m_dpy);
```
- at the same time we also have the cursortheme kcm and the tool `plasma-apply-cursortheme`, which boil down to [`applyTheme`](https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kcms/cursortheme/xcursor/themeapplicator.cpp#L25)
- What this does is running `krdb` and afterwards calling `XFixesChangeCursorByName` for a list of cursor names, the latter is only done on X11
- krdb in turn sets `"Xcursor.theme"`and `"Xcursor.size"` resources [[4]](https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kcms/krdb/krdb.cpp#L379)
- this is also run at kcminit time through the style kcm [[3]](https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kcms/style/kcmstyle.cpp#L50)
The end goal should be just one kcminit which does the relevant things and us only having one tool. In my opinion it makes most sense to drop the code from the mouse kcm.https://invent.kde.org/plasma/plasma-nm/-/issues/4Scope for plasma-nm2023-05-05T09:17:32ZNicolas FellaScope for plasma-nmplasma-nm is absolutely massive, both in terms of code size (about 40K LOC) and functionality it provides. Now being large is not a problem in itself, but it can become problematic if it leaks into the UX and affects maintainability of t...plasma-nm is absolutely massive, both in terms of code size (about 40K LOC) and functionality it provides. Now being large is not a problem in itself, but it can become problematic if it leaks into the UX and affects maintainability of the code.
In my non-scientific experience users expect a few things from a network management UI:
- Connect to a Wifi network, both simple password-protected networks and corporate/university networks (WPA Enterprise)
- Connect to their work/university/streaming/whatever VPN
- Make their laptop/USB modem work (e.g. enter then PIN)
- Turn Wifi/Airplane mode on/off
- Do basic troubleshooting when things don't work
However the KCM also provides a number of things on top of that:
- Creating a wide variety of connections types (e.g. Infiniband, Bond, Bridge, Team, VLAN)
- Fine-grained editing of existing connections with all kinds of technical details
The KCM more or less exposes the full capabilities of NetworkManager.
This raises the question: Is all of that even necessary? Is anyone going to use the KCM to configure a VLAN? Or a Team (I don't even know what that is)?
This wide scope of the KCM results in UX problems like the one described in https://invent.kde.org/plasma/plasma-nm/-/issues/3, where the useful connection options are drowned in a list of semi- or not-at-all useful options.
It also makes it very hard to evolve the codebase. Currently the KCM is a hybrid of Widgets and QML, and attempts to fully port it to QML are stalled because of the massive scope.
I propose that we think very hard about what we actually want to achieve with this KCM and whether our current conceptual approach is suitable for that.
In particular I'd argue that plasma-nm does not need to expose the full feature set and complexity of NetworkManager and we should instead leave that to projects like network-manager-applethttps://invent.kde.org/plasma/kwin/-/issues/149Is it really necessary to tint the entire background on overview and present ...2023-04-18T20:54:36ZSilas RennerIs it really necessary to tint the entire background on overview and present windows effects?I was experimenting with a few customization things involving a new fullscreen dashboard menu for Plasma that appeared on Pling, called Plasma Drawer. It gave this option to reduce or increase the background opacity and I decided to try ...I was experimenting with a few customization things involving a new fullscreen dashboard menu for Plasma that appeared on Pling, called Plasma Drawer. It gave this option to reduce or increase the background opacity and I decided to try setting it fully transparent. With no windows behind, it blurs everything but the wallpaper is still visible, as well as the widgets and desktop icons. It didn't look too shabby.
So I decided to try applying the same ideas to the Overview and Present Windows effects for KWin. The effects are... discussable, to say the least. Here are a few of my impressions:
Present Windows:
https://i.postimg.cc/CxhY65Q8/Spectacle-20230418-172711.png
Overview:
https://i.postimg.cc/2yDgbXpW/Spectacle-20230418-172643.png
Because there isn't a lot of text to read, only the title of each window, it isn't really necessary for there to be a full screen contrast against those, and even then, can be fixed with adding something like a translucid background for the text. In case of the Overview effect, it could also be applied for each of KRunner's results, separating each result category in its own "card".
Additionally, this helps with the screen being too bright with Light color schemes, since only the wallpaper would be visible behind the windows and, in case of the overview effect, only the desktop thumbnail bar would have a translucid background, which personally, improves the look quite a bit. Maybe this would look too much like Mac OS for some but I am not bothered by this. If not default, maybe an option in the configuration dialog for each effect would suffice. Hey, more customization, am I right?
Now, this was only me toying a bit with some of the properties in the QML files. I don't understand QML very well myself. Personally, I can get my way around CSS a bit better. I would have tried adding the said backgrounds I mentioned above to improve contrast for any remaining text but I'm not sure what to do here.https://invent.kde.org/plasma/kwin/-/issues/148Power saving with variable refresh rate2023-12-21T18:53:57ZXaver HuglPower saving with variable refresh rateIn many cases, driving a high resolution and/or high refresh rate display requires the GPU to keep VRAM clocks high, which uses a lot of power. With VRR, we can reduce the refresh rate when appropriate to reduce that power usage.
This i...In many cases, driving a high resolution and/or high refresh rate display requires the GPU to keep VRAM clocks high, which uses a lot of power. With VRR, we can reduce the refresh rate when appropriate to reduce that power usage.
This is a long term goal, as the kernel API isn't currently well suited for this purpose: We have one property that toggles whether or not the kernel changes the refresh rate to the rate at which KWin commits new frames, and that's it. This is problematic, as in normal desktop operations KWin submits buffers in irregular patterns, causing the refresh rate to change rapidly, and thus causing visible flicker on many displays.
Some possibilities of implementing this would be:
- (obviously) add a kernel API allowing us to set any refresh rate we want, or to otherwise limit the rate at which the refresh rate changes to eliminate flicker. With the rate at which the drm API evolves I'm not optimistic about this, but maybe worth a try
- we could enable VRR whenever we're not updating anything. This has the drawback that we're drastically changing the refresh rate, causing a moment of brightness change, but it's not that noticeable if it doesn't happen often
- recently amdgpu has added VRR modes. These are a few special modes that can be switched to without doing a modeset. Which modes can do this can be figured out by doing atomic tests, so it would be possible to switch to a lower refresh rate mode while KWin is committing fewer frames. As a downside, this is still rapidly changing the refresh rate, so the same caveat as with the option above applies
- with !3828 and some additional work, it may be possible to use the commit thread to do atomic commits at a very stable rate, allowing us to emulate any refresh rate + limited rate of change thereof we want. It may also require actually triggering page flips though, so we'd need at least two identical buffers to flip between... needs to be tested and evaluated if it's worth the complexity.https://invent.kde.org/plasma/plasma-workspace/-/issues/65Desktop file names for activation tokens when invoking notification actions2023-10-17T15:46:49ZNicolas FellaDesktop file names for activation tokens when invoking notification actionsWhen invoking a notification action (by clicking on an action button or the whole notification for the default action) on Wayland Plasma requests an XDG activation token and passes that to the application. This is done so that the applic...When invoking a notification action (by clicking on an action button or the whole notification for the default action) on Wayland Plasma requests an XDG activation token and passes that to the application. This is done so that the application can raise its own window in response. When requesting the token one can optionally pass a desktop file name. Passing a (valid) desktop file name triggers startup feedback (i.e. the bouncing cursor by default, but could be anything).
What desktop file name does Plasma use to request the token? Currently it reads a `x-kde-xdgTokenAppId` hint from the notification: https://invent.kde.org/plasma/plasma-workspace/-/blob/master/libnotificationmanager/notification.cpp#L357. KNotifications sets this hint to `QGuiApplication::desktopFileName()`: https://invent.kde.org/frameworks/knotifications/-/blob/master/src/knotification.cpp#L52
This has several problems:
1) It introduces an inconsistency between apps using KNotifications and other apps (e.g. using libnotify or DBus directly). The former always gets this hint and thus always a desktop file name in the token, the latter never (unless they manually set the x-kde- hint). This could be solved by also considering the `desktop-entry` notification hint.
2) xdg-desktop-portal-kde uses KNotifications to implement portal notification. This means all portal notification get "org.freedesktop.impl.portal.desktop.kde" as desktop file name in their activation token. This can be seen e.g. when clicking on a Telegram notification, where you will get a bouncing cursor with a generic KDE icon. This could be solved in xdg-desktop-portal-kde by overriding the `x-kde-xdgTokenAppId` hint with the proper value.
3) The desktop file name of the program that creates the notification does not necessarily match the one of the program getting opened when clicking the notification. For example the discover update notifier creates a notification about updates being available and when clicking the "Show updates" button discover is launched. The notifier and Discover itself have different desktop file names and icons, so when clicking "Show updates" you get a bouncing cursor with the notifier icon instead of the Discover icon. This could be fixed by overriding the hint in the notifier.
4) There are cases where we do not want any visible startup feedback. For example when the calendar reminder background program shows a notification like "Annoying Meeting in 5 Minutes [Dismiss] [Remind again in 5 Minutes]" then clicking dismiss doesn't result in any window getting activated and there should be no bouncing cursor. That would be achievable by overriding the hint to be empty. However, we would also need to ensure that Plasma doesn't fall back to "desktop-entry" as part of the solution to problem 1). There's a catch though. Assume the notification also has a "Open Meeting URL" button that opens the meeting URL in your browser. When clicking that you want to have startup feedback, but with the browser's icon, not the icon of the calendar system. This shows that we want some ability to customize the desktop file name on a per-action basis instead of only a per-notification basishttps://invent.kde.org/plasma/plasma-workspace/-/issues/64System misconfiguration detection hub2024-03-27T17:51:02ZNate GrahamSystem misconfiguration detection hubIn an ideal world, the user wouldn't have a misconfigured system. Distros would all follow https://community.kde.org/Distributions/Packaging_Recommendations and pre-install a complete set of support packages. Samba sharing would be set u...In an ideal world, the user wouldn't have a misconfigured system. Distros would all follow https://community.kde.org/Distributions/Packaging_Recommendations and pre-install a complete set of support packages. Samba sharing would be set up correctly out of the box. No one would manually mount network shares using `/etc/fstab` and cause system hangs. Etc.
Unfortunately we don't live in that world and we probably never will. Even in our own Neon distro, we can pre-configure stuff correctly to avoid one source of configuration problems, but we can't actively inhibit user errors made outside of KDE software. We can say, "meh, not my problem" but it kind of is since KDE gets blamed for the issues caused by these preventable errors.
We could have a system to detect known sources of misconfiguration, alert the user about them, and offer known remedies. For example:
- Detect that `qt5ct` is installed -> explain that this will break theming and file dialogs, show a button to remove it, and explain that supported configuration changes can be made in System Settings.
- Detect that `xdg-desktop-portal-gnome` is installed -> explain that this is unnecessary and will break various apps, and show a button to remove it.
- Detect that a network share has been manually added to `/etc/fstab` or manually mounted -> Explain that this will cause system hangs, show a button to set up an auto-mount for it using kio-fuse with an entry in the Places panel pointing to it for quick access.
- Detect when important KDE packages are missing; things like `kio-fuse`, `kio-extras`, `kdeplasma-addons`, `dolphin-plugins` (when Dolphin is installed), `baloo-widgets` (when Baloo is on), and so on -> show a button to install them, along with a "don't warn about this again" checkbox.https://invent.kde.org/plasma/plasma-sdk/-/issues/5duplicate man pages in po directory break the build2024-03-07T07:58:57Zivan tkachenkoduplicate man pages in po directory break the buildWhen trying to build plasma-sdk from Plasma/5.27 git branch (commit d953e867fa4e2deec3e2476f0bbcb1f53e488dbf at the time of writing), recently added duplicate translations break the build:
```
CMake Error at /usr/local/kde/lib/cmake/KF5...When trying to build plasma-sdk from Plasma/5.27 git branch (commit d953e867fa4e2deec3e2476f0bbcb1f53e488dbf at the time of writing), recently added duplicate translations break the build:
```
CMake Error at /usr/local/kde/lib/cmake/KF5DocTools/KF5DocToolsMacros.cmake:203 (add_custom_target):
add_custom_target cannot create target
"po-nl-docs-plasma-sdk-engineexplorer-plasmaengineexplorer-1" because
another target with the same name already exists. The existing target is a
custom target created in source directory
"/home/ratijas/kde/src/kde/workspace/plasma-sdk". See documentation for
policy CMP0002 for more details.
Call Stack (most recent call first):
/usr/local/kde/lib/cmake/KF5DocTools/KF5DocToolsMacros.cmake:234 (kdoctools_create_manpage)
CMakeLists.txt:92 (kdoctools_install)
CMake Error at /usr/local/kde/lib/cmake/KF5DocTools/KF5DocToolsMacros.cmake:203 (add_custom_target):
add_custom_target cannot create target
"po-nl-docs-plasma-sdk-plasmoidviewer-plasmoidviewer-1" because another
target with the same name already exists. The existing target is a custom
target created in source directory
"/home/ratijas/kde/src/kde/workspace/plasma-sdk". See documentation for
policy CMP0002 for more details.
Call Stack (most recent call first):
/usr/local/kde/lib/cmake/KF5DocTools/KF5DocToolsMacros.cmake:234 (kdoctools_create_manpage)
CMakeLists.txt:92 (kdoctools_install)
```
```
$ tree po/nl
po/nl
├── cuttlefish_editorplugin.po
├── cuttlefish.po
├── docs
│ ├── plasma-sdk
│ │ ├── engineexplorer
│ │ │ └── man-plasmaengineexplorer.1.docbook
│ │ └── plasmoidviewer
│ │ └── man-plasmoidviewer.1.docbook
│ ├── plasma-sdk_engineexplorer
│ │ └── man-plasmaengineexplorer.1.docbook
│ └── plasma-sdk_plasmoidviewer
│ └── man-plasmoidviewer.1.docbook
├── org.kde.plasma.lookandfeelexplorer.po
├── org.kde.plasma.themeexplorer.po
├── plasmaengineexplorer.po
├── plasma_shell_org.kde.plasmoidviewershell.po
└── plasmoidviewer.po
```5.27https://invent.kde.org/plasma/plasma-pass/-/issues/4Add, Remove and Edit password via Plasma Pass2023-04-09T01:24:31Zmed medinAdd, Remove and Edit password via Plasma PassTo Add, Remove or Edit a password entry, we are forced to open terminal and type some commands to achieve those basic operations. It would be great if it was done possible via Plasma Pass without any need to use terminal because many ave...To Add, Remove or Edit a password entry, we are forced to open terminal and type some commands to achieve those basic operations. It would be great if it was done possible via Plasma Pass without any need to use terminal because many average users have no knowledge how to interact with it.https://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.