Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2022-10-03T13:41:01Zhttps://invent.kde.org/plasma/discover/-/issues/15How can we get users to actually update their systems?2022-10-03T13:41:01ZNate GrahamHow can we get users to actually update their systems?See https://invent.kde.org/plasma/discover/-/merge_requests/316#note_483682
This discussion evolved into a question of how we get users' attention so that they update, and how do we make sure the update experience is pleasant enough tha...See https://invent.kde.org/plasma/discover/-/merge_requests/316#note_483682
This discussion evolved into a question of how we get users' attention so that they update, and how do we make sure the update experience is pleasant enough that they don't give up in the middle or nope out next time.
@teams/usabilityhttps://invent.kde.org/plasma/systemsettings/-/issues/32How should we handle KCM-specific search fields?2023-09-28T01:23:30ZNate GrahamHow should we handle KCM-specific search fields?System Settings itself has a search field above the header. It searches for KCMs in the view below it.
Many KCMs have their own search fields. They search through page content below them.
The result often looks like this:
![image](/up...System Settings itself has a search field above the header. It searches for KCMs in the view below it.
Many KCMs have their own search fields. They search through page content below them.
The result often looks like this:
![image](/uploads/6c8edd5eb0bea21ec6ee50919d49e039/image.png)
There are a few issues stemming from this:
- With two search fields both bound to Ctrl+F, they shadow each other's shortcuts. Even if they didn't, it would be unclear which one would or should be activated by that shortcut
- The page search field is generally much wider than the sidebar search field, and at a lower Y level in the window too. The result often looks kind of ugly
- Showing two search fields in the same window in general is kind of inherently awkward
Let's brainstorm ideas to improve this situation.
@teams/vdg @teams/usabilityhttps://invent.kde.org/plasma/plasma-desktop/-/issues/116How to deal with margins around applets2024-03-26T07:57:50ZNiccolò VenerandiHow to deal with margins around appletsHere's a fun choice: should applets themselves have the responsibility to draw margins around them, or should their container do that?
There are a couple of places where this issue arises. Firstly, we have the panel; if we draw the back...Here's a fun choice: should applets themselves have the responsibility to draw margins around them, or should their container do that?
There are a couple of places where this issue arises. Firstly, we have the panel; if we draw the background of all applets "lightcoral", we can easily see that _most_ applets draw _some_ margin around them, though we still have the panel draw some margin between the applets themselves:
![Screenshot_20240127_192614](/uploads/89a5ce57cbdd2239ae6f1bf3adab22da/Screenshot_20240127_192614.png)
This can, IMO, create some issues. As an example, a nice idea would be for icons-only applets to have exactly a 1:1 aspect ratio (they currently don't); however, if we do that, the additional margin provided by the panel will be quite unnecessary (and, actually, might even feel excessive). However, if we allow applets to define the external margin themselves with little to no help from the panel, there's no way for themes to actually customize the density of the elements.
We have a similar problem with applets in dialogs. The theme will define an external margin to be used between the border of the dialog and the inner items. Usually, that amount is very small, and as a result, all applets will add some extra margin themselves. This causes some inconsistencies between applets (applying different amounts of margins) and makes it impossible for themes to have dialogs with no margins whatsoever (should they even be allowed to? I say yes, because why not).
---
My personal take, after a bit of time and thought, is that we should always explicitly ask applets (both compact and full representations) to _always_ touch the external borders; if they set a certain size, they should always use all of it. This gives complete control of the external margin to the containment, which I feel is the easiest way to get both consistency and customization. This will require a bit of work on our own applets (I can do that) and asking for compliance from third-party applets (now is the best time to do that).
There are some scenarios where the applet reasonably can't actually touch the borders. As an example, all icons (for some reason which I'll never accept!) come with a margin built in directly in the SVG. _In a utopia_ I would make all SVGs touch the external borders, but we can't feasibly implement this. _Ideally_ we could read the actual size of the SVG element inside the file and base the size of the applet on that. Worst case scenario, we allow that SVG-icon margin to mess a bit with our design (as it does now, really). Buttons and other elements also come with built-in margin, but I'd say that's fine, since it actually gets used to e.g. display highlights and such.Niccolò VenerandiNiccolò Venerandihttps://invent.kde.org/plasma/powerdevil/-/issues/24How to deal with "Suspend, then hibernate"2023-12-03T04:30:21ZJakob PetsovitsHow to deal with "Suspend, then hibernate"There's this option in per-profile power management settings labeled as "While asleep, hibernate after a period of inactivity". Internally, it's called `SuspendThenHibernate`. It's weird and I wonder if we can represent it in a better wa...There's this option in per-profile power management settings labeled as "While asleep, hibernate after a period of inactivity". Internally, it's called `SuspendThenHibernate`. It's weird and I wonder if we can represent it in a better way. What's wrong with it, you ask?
### The scope is misleading
This checkbox is indented to look like a visual part/child of the "Suspend session" checkable section. However, if the "Suspend session" checkbox/section is not enabled, the checkbox for `SuspendThenHibernate` is still checkable. Now is this setting only respected for regular auto-suspend, or also when I close my lid or press the power button?
* Answer: It's respected for all top-level sections of a power management profile. Everything that wants to suspend will go through `SuspendSession::triggerImpl()` and there we check for it anytime the daemon wants to `SuspendToRam`.
* It's not, however, respected for `SuspendHybrid`, i.e. simultaneous `SuspendToRam` (i.e. Sleep) and `SuspendToDisk` (i.e. Hibernate). Too bad for you, hybrid suspenders. Maybe it would have been nice to turn off the computer after a while if we've already suspended to disk?
### The representation is misleading
We have enum entries for `SuspendToRam`, `SuspendToDisk` and `SuspendHybrid`. All of those are represented to the user as distinct options in a drop-down, but `SuspendThenHibernate` is somehow a checkbox and a separately stored boolean. And even so, it only affects the behavior of `SuspendToRam`. That doesn't sit right with me.
If `SuspendHybrid` is "suspend as well as hibernate", then why is `SuspendThenHibernate` not also an option in the same drop-down? What's the conceptual difference between both? Why would it not be another value in the same enum that represents all the other power button actions?
Side note: Variable/enum naming is also poor. Hibernate is called `SuspendToDisk` elsewhere in the code. Something like `SuspendToRamFirstAndDiskLater` would be more consistent than `SuspendThenHibernate`.
## Some considerations
You might have thoughts on this, such as:
**We already have lots of different suspend options in our power action drop-downs. Won't it be super confusing if we add another option?**
* Possibly, yeah. If I weren't using KDE, I probably wouldn't even *know* that there are so many different ways to suspend my system.
* However, it's already confusing, and in ways that doesn't represent the behavior accurately. At least we'd lose the misleading checkbox.
**If we make `SuspendThenHibernate` another option in the same drop-down, the user will have to select it for each action, instead of just once for the whole power management profile.**
* That's true, yeah. It's more manual work in return for a clearer mental model.
* I wonder what use cases there are for selecting different kinds of suspend options for auto-suspend, lid close and explicit power button.
**Maybe it should be a global setting?**
* No, I don't think so.
* Low battery has a use case for selecting `SuspendToDisk` (or `SuspendHybrid`) when other profiles choose `SuspendToRAM`. So whichever way we deal with it _within_ the profile, `SuspendThenHibernate` should remain a per-profile setting.
**The user will still wonder what the difference is between "Hybrid Suspend" and "Suspend, then Hibernate".**
* If we're going to expose these options, we need to add some inline documentation to explain what they actually do. It's not immediately clear how they differ from each other without looking up the Arch Linux wiki.
## Proposal
I'm thinking we should revamp both our GUI and our internal variables/config in the following way:
* Remove the confusing checkbox ("While asleep, hibernate after a period of inactivity").
* In all the drop-downs (auto-suspend, lid close, power button), have only a single "Suspend" option instead of three to four.
* That's next to other options such as "Do Nothing", "Lock Screen" and others depending on context.
* On the top-level hierarchy of per-profile power management settings, add a new drop-down to select which kind of suspend action to use.
* Options: "Sleep (Suspend to RAM)", "Hibernate (Suspend to Disk)", "Hybrid (Suspend to both RAM and Disk)", "Sleep, then Hibernate after a period of inactivity".
* All of auto-suspend, lid close, power button will always use the same kind of suspend in this power profile.
* Placing this new drop-down will be easier after the flat-hierarchy redesign that comes with the QML port.
I'm still learning when it comes to UX though. Maybe I'm missing something and there are good reasons to do something else. Discuss!6https://invent.kde.org/plasma/kscreen/-/issues/11How to deal with the increasing amount of display settings2024-03-01T16:40:54ZXaver HuglHow to deal with the increasing amount of display settingsThe KCM is slowly getting crowded as we support more display capabilities and workarounds, and I think it's worth looking into how to manage this better design wise. This is how things look on my system with !289, HDR enabled and RGB ran...The KCM is slowly getting crowded as we support more display capabilities and workarounds, and I think it's worth looking into how to manage this better design wise. This is how things look on my system with !289, HDR enabled and RGB range forcefully shown (because amdgpu doesn't support it yet):
![Screenshot_20240226_063903](/uploads/135d6d585efd540ccc914c99b2a5487f/Screenshot_20240226_063903.png)
We currently have these options, already grouped because they're a lot:
- the usual basic output stuff: enable/disable, position, mode (resolution + refresh rate), scale, rotation, mirroring
- output "priority" ("primary" screen setting in 2-monitor setups)
- variable refresh rate
- overscan (workaround for horrible displays, usually old TVs)
- rgb range (workaround for horrible displays and/or drivers, sadly not *that* uncommon)
- HDR + some settings for it, *or* color management based on ICC profiles, *or* color management based on the EDID
And the global settings
- scaling for X11 apps
- allow / disallow screen tearing
I also want to still add:
- maximum bits per color (workaround for horrible displays/cables/drivers that can make a screen randomly flicker to black or not work at all)
- a setting to reduce brightness flicker for VRR displays (also a workaround for displays)
- a page for HDR calibration / color adjustments / profiling
- a setting to make outputs "audio only" (workaround for HDMI being used for audio transfer, when it's a video cable. Check https://bugs.kde.org/show_bug.cgi?id=473685 for details)
- a setting to reduce power usage by reducing color accuracy on laptop displays
- maybe a setting for automatic brightness
- a setting for automatic whitepoint adjustment (based on ambient color sensors some laptops and phones have)
- a setting for manual whitepoint adjustment
- not a setting but still: information about how the display is connected: the actually used bpc, the physical connector type, the GPU it's connected to
One of the options for how to deal with this would be to split this into three pages:
1. the main page, with the options that a lot of people will know and be interested in: the basic stuff like position, mode, scale etc, probably variable refresh rate, and the global settings
2. a "workarounds" page, which users should only need to open if they have some problem with their display. This would contain overscan, rgb range, maximum bits per color, maybe the brightness flicker thing for VRR, the "audio only" thing. The information about the display would also be useful in here, with a button to copy it for bug reports perhaps
3. a "HDR and color management" page, for all the color related stuff (minus the "rgb range" thing)
To make the more esoteric options understandable, I'd like to have always-visible explanations directly on the page - at least for the workarounds. Something in the direction of
```
RGB Range: [automatic]
Determines whether or not the range of possible color values should be limited for this display, which is often needed with old TVs. Try changing it if colors look washed out
```
would imo be a lot better than `ContextualHelpButton`s next to every option.
What do you think? Do you have any alternatives in mind? @teams/vdghttps://invent.kde.org/plasma/plasma-bigscreen/-/issues/7Ideas for other ways Bigscreen could be used2024-03-08T22:02:37ZNoah DavisIdeas for other ways Bigscreen could be usedThis is for brainstorming, not necessarily things we must do.
- As a UI for speakers giving talks on a stage
- May need an app for browsing documents with a remote.This is for brainstorming, not necessarily things we must do.
- As a UI for speakers giving talks on a stage
- May need an app for browsing documents with a remote.https://invent.kde.org/plasma/krdp/-/issues/8I get a black screen when I connect to my remote desktop2024-02-14T05:01:18ZIbrahim KaikaaI get a black screen when I connect to my remote desktopWhen I start the kRDP server and select my monitor, I get this
```console
➜ ~ flatpak run org.kde.krdp -u mrunix -p test
qt.qpa.qgnomeplatform: Could not find color scheme ""
Could not find certificate and certificate key, generating ...When I start the kRDP server and select my monitor, I get this
```console
➜ ~ flatpak run org.kde.krdp -u mrunix -p test
qt.qpa.qgnomeplatform: Could not find color scheme ""
Could not find certificate and certificate key, generating temporary certificate...
Temporary certificate generated; ready to accept connections.
org.kde.krdp: Initializing Freedesktop Portal Session
org.kde.krdp: Listening for connections on QHostAddress(QHostAddress::Any) 3389
org.kde.krdp: Started Freedesktop Portal session
```
And when I connect to kRDP with remmina I get a black screen on it, and that's the output of the terminal after that:
```console
➜ ~ flatpak run org.kde.krdp -u mrunix -p test
qt.qpa.qgnomeplatform: Could not find color scheme ""
Could not find certificate and certificate key, generating temporary certificate...
Temporary certificate generated; ready to accept connections.
org.kde.krdp: Initializing Freedesktop Portal Session
org.kde.krdp: Listening for connections on QHostAddress(QHostAddress::Any) 3389
org.kde.krdp: Started Freedesktop Portal session
** (krdpserver:2): WARNING **: 21:58:38.104: atk-bridge: get_device_events_reply: unknown signature
org.kde.krdp: Session setup completed, start processing...
[21:59:39:351] [2:9] [INFO][com.freerdp.core.connection] - Client Security: NLA:1 TLS:1 RDP:0
[21:59:39:351] [2:9] [INFO][com.freerdp.core.connection] - Server Security: NLA:1 TLS:0 RDP:0
[21:59:39:351] [2:9] [INFO][com.freerdp.core.connection] - Negotiated Security: NLA:1 TLS:0 RDP:0
[21:59:49:598] [2:9] [WARN][com.winpr.negotiate] - AcceptSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[21:59:49:699] [2:9] [WARN][com.winpr.negotiate] - AcceptSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[21:59:49:800] [2:9] [INFO][com.freerdp.core.connection] - Accepted client: fedora
[21:59:49:800] [2:9] [INFO][com.freerdp.core.connection] - Accepted channels:
[21:59:49:800] [2:9] [INFO][com.freerdp.core.connection] - rdpdr
[21:59:49:800] [2:9] [INFO][com.freerdp.core.connection] - rdpsnd
[21:59:49:800] [2:9] [INFO][com.freerdp.core.connection] - cliprdr
[21:59:49:800] [2:9] [INFO][com.freerdp.core.connection] - drdynvc
[21:59:49:800] [2:9] [INFO][com.freerdp.core.gcc] - Active rdp encryption level: NONE
[21:59:49:800] [2:9] [INFO][com.freerdp.core.gcc] - Selected rdp encryption method: NONE
org.kde.krdp: New client connected: UNIX platform Unspecified version
org.kde.krdp: Video stream initialized
org.kde.krdp: Received caps:
org.kde.krdp: RDPGFX_CAPVERSION_8 AVC: false YUV420: false
org.kde.krdp: RDPGFX_CAPVERSION_81 AVC: true YUV420: true
org.kde.krdp: RDPGFX_CAPVERSION_10 AVC: true YUV420: false
org.kde.krdp: RDPGFX_CAPVERSION_101 AVC: true YUV420: false
org.kde.krdp: RDPGFX_CAPVERSION_102 AVC: true YUV420: false
org.kde.krdp: RDPGFX_CAPVERSION_103 AVC: true YUV420: false
org.kde.krdp: RDPGFX_CAPVERSION_104 AVC: true YUV420: true
org.kde.krdp: RDPGFX_CAPVERSION_105 AVC: true YUV420: true
org.kde.krdp: RDPGFX_CAPVERSION_106 AVC: true YUV420: true
org.kde.krdp: UNKNOWN_VERSION AVC: false YUV420: false
org.kde.krdp: RDPGFX_CAPVERSION_107 AVC: true YUV420: true
org.kde.krdp: Selected caps: RDPGFX_CAPVERSION_107
libva info: VA-API version 1.18.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_18
libva error: /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_18
libva info: va_openDriver() returns 0
kpipewire_record_logging: VAAPI: Display initialized
kpipewire_record_logging: VAAPI: API version 1 . 18
kpipewire_record_logging: VAAPI: Intel i965 driver for Intel(R) Sandybridge Mobile - 2.4.1 in use for device "/dev/dri/renderD128"
[AVHWDeviceContext @ 0x7ff7f00ec140] libva: /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/iHD_drv_video.so init failed
[AVHWFramesContext @ 0x7ff7f00ee040] Failed to create surface from DRM object: 18 (invalid parameter).
[Parsed_hwmap_0 @ 0x7ff7f00e8c00] Failed to map frame: -5.
kpipewire_record_logging: Failed receiving filtered frame: Input/output error
QObject: Cannot create children for a parent that is in a different thread.
(Parent is QGuiApplication(0x7fffc1e05950), parent's thread is QThread(0x555fdff18850), current thread is QThread(0x7ff7fc043260)
[AVHWFramesContext @ 0x7ff7f00ee040] Failed to create surface from DRM object: 18 (invalid parameter).
[Parsed_hwmap_0 @ 0x7ff7f00e8c00] Failed to map frame: -5.
kpipewire_record_logging: Failed receiving filtered frame: Input/output error
[AVHWFramesContext @ 0x7ff7f00ee040] Failed to create surface from DRM object: 18 (invalid parameter).
[Parsed_hwmap_0 @ 0x7ff7f00e8c00] Failed to map frame: -5.
kpipewire_record_logging: Failed receiving filtered frame: Input/output error
[AVHWFramesContext @ 0x7ff7f00ee040] Failed to create surface from DRM object: 18 (invalid parameter).
[Parsed_hwmap_0 @ 0x7ff7f00e8c00] Failed to map frame: -5.
kpipewire_record_logging: Failed receiving filtered frame: Input/output error
[AVHWFramesContext @ 0x7ff7f00ee040] Failed to create surface from DRM object: 18 (invalid parameter).
[Parsed_hwmap_0 @ 0x7ff7f00e8c00] Failed to map frame: -5.
kpipewire_record_logging: Failed receiving filtered frame: Input/output error
```
I installed kRDP using flatpak and I downloaded it from this URL:
https://download.kde.org/unstable/krdp/krdp-alpha-20230808.flatpak
These are some of my system info:
**OS**: Fedora 38
**DE**: Gnome 44.3
**Windowing System**: Wayland
**Kernel Version**: Linux 6.4.7-200.fc38.x86_64
**Laptop**: Dell Latitude E6220
**CPU**: Intel Core i5-2520M
**GPU**: Intel HD Graphics 3000 (SNB GT2)https://invent.kde.org/plasma/discover/-/issues/26Implement flatpak uri scheme2024-02-04T21:08:07ZKolja LampeImplement flatpak uri schemeWhile `snap://tv.kodi.Kodi` is a thing `flatpak://tv.kodi.Kodi` does nothing
So I would hope for something like `flatpak://tv.kodi.Kodi?repo=https://dl.flathub.org/repo/` to work after this is implemented.
1. Check if the repo is insta...While `snap://tv.kodi.Kodi` is a thing `flatpak://tv.kodi.Kodi` does nothing
So I would hope for something like `flatpak://tv.kodi.Kodi?repo=https://dl.flathub.org/repo/` to work after this is implemented.
1. Check if the repo is installed, offer to install if not
2. Show the app inside of the software center and pre-select the correct remote
There has been some (not very significant discussion) here https://github.com/flathub/website/issues/919
I would like to use this to allow websites to link to apps, in particular flathub.org and replacing `.flatpakref`s which are not giving as good user experiance. You first need to download them and then open them with the correct app.
While using a uri like this would allow to be almost seamless.
Sorry, if this works slightly differently in KDE, I don't have the means of double check it right now.https://invent.kde.org/plasma/flatpak-kcm/-/issues/13Implement support for "highlight changed settings" feature2022-08-23T15:03:20ZNate GrahamImplement support for "highlight changed settings" featureYou can use `KCM.SettingStateBinding` objects to determine when an item is different from its default setting and highlight the control in orange (if there is a control) or add an orange dot (if there is not).
Copy other KCMs for inspir...You can use `KCM.SettingStateBinding` objects to determine when an item is different from its default setting and highlight the control in orange (if there is a control) or add an orange dot (if there is not).
Copy other KCMs for inspiration and code.https://invent.kde.org/plasma/kwin/-/issues/177Implicit grabs & closed windows2023-08-24T10:45:14ZVlad ZahorodniiImplicit grabs & closed windowsAn implicit grab is started if you press and hold a pointer button or a keyboard key. After that, only the client will receive the subsequent events until the last button or key is released.
It works okay if the window is not closed. Ho...An implicit grab is started if you press and hold a pointer button or a keyboard key. After that, only the client will receive the subsequent events until the last button or key is released.
It works okay if the window is not closed. However, if the window is closed, it's possible to leak release events to the next client. As an example,
- open mpv and firefox(reddit)
- focus mpv and press "q"
- mpv will be closed and the keyboard focus will move to firefox
- however, you'll also see reddit's community search field focused (this should not happen)
Another problem with implicit grabs is that we have to keep it valid even if the associated window or decoration is destroyed. See https://invent.kde.org/plasma/kwin/-/merge_requests/4315#note_746018https://invent.kde.org/plasma/plasma-mobile/-/issues/30Improve behaviour of the StartupFeedback2022-10-23T20:25:13ZJonah BrüchertImprove behaviour of the StartupFeedbackThis is not strictly a bug report, but rather a documentation of the various usability improvements the StartupFeedback should get:
- [x] The top and bottom bar of the shell should get opaque already when the StartupFeedback is open, no...This is not strictly a bug report, but rather a documentation of the various usability improvements the StartupFeedback should get:
- [x] The top and bottom bar of the shell should get opaque already when the StartupFeedback is open, not only when the app has started.
- [x] If the StartupFeedback gets killed by the user, the app the loading of which it indicates should be killed as well
- [x] The StartupFeedback should also be opened if an app starts another app (not only if the shell does it), see !66
- [ ] The StartupFeedback should not close when it's inactive (plasma/plasma-nano!4):
- if the user opens the quick settings while an app is starting, the StartupFeedback is gone.
- the user of the API in plasma-nano (plasma-phone-components) should handle what happens on activeChanged. We don't need it since we close the feedback using KStartupFeedback with !66.
- [x] The StartupFeedback should not have a timeout. (plasma/plasma-nano!3) Some Maui apps take longer than it to start, leading to the feedback window disappearing too early and the app starting nevertheless. If the StartupFeedback really got stuck for whatever reason, the user can still manually close, minimize it etc.https://invent.kde.org/plasma/plasma-nano/-/issues/3Improve readme2023-10-31T12:51:43ZSum GaiImprove readmePlease update the readme to include a description of what is included in `plasma-nano` and what sets it apart from the standard Plasma shell environment. An additional section with build and install instructions would also be appreciated.Please update the readme to include a description of what is included in `plasma-nano` and what sets it apart from the standard Plasma shell environment. An additional section with build and install instructions would also be appreciated.Joshua Goinsjosh@redstrate.comJoshua Goinsjosh@redstrate.comhttps://invent.kde.org/plasma/plasma-nm/-/issues/3Improve UX for adding new VPN connection2023-04-19T14:01:43ZNicolas FellaImprove UX for adding new VPN connectionWhen clicking "Add new connection" in the KCM the user gets presented with a huge list of different connection types to choose from.
Some of them are somewhat obscure technologies (Bond, Team, VLAN).
Some of them are common things (wire...When clicking "Add new connection" in the KCM the user gets presented with a huge list of different connection types to choose from.
Some of them are somewhat obscure technologies (Bond, Team, VLAN).
Some of them are common things (wired ethernet, WiFi), but one usually doesn't create such connections that way. Wired connections should just work when plugging a cable in. For Wifi we expect people to select a discovered WiFi from the applet instead of creating a Wifi connection from scratch.
My guess would be that 99% of the time people go there they want to configure a VPN. And yet VPNs are sorted last in the list. Quite often they probably want to import a VPN from a configuration file they got e.g. from $work, but that item is the last in the list.
How can we make the common case of wanting to add a VPN more streamlined instead of hiding it below a bunch of mostly irrelevant and even confusing options?
For context, this is the current list of available connection types:
![grafik](/uploads/ab52b70361c6bdb60c63324ae715b49e/grafik.png)
@teams/vdghttps://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-mobile/-/issues/264initialstart: Ensure custom scaling is accounted for2024-03-08T21:30:20ZDevin Lininitialstart: Ensure custom scaling is accounted forIf we have a scaling factor not in the combobox, it should still be shown in the card delegate.If we have a scaling factor not in the combobox, it should still be shown in the card delegate.6.1https://invent.kde.org/plasma/kwin/-/issues/67Input redirection with QtQuick window thumbnails2021-11-30T12:29:36ZVlad ZahorodniiInput redirection with QtQuick window thumbnailsIn the overview effect, it can be desired to forward mouse events to the panel. On X11, it's a difficult problem. On the other hand, on Wayland, it should be doable as kwin is in charge of input handling. We may need to tweak some intern...In the overview effect, it can be desired to forward mouse events to the panel. On X11, it's a difficult problem. On the other hand, on Wayland, it should be doable as kwin is in charge of input handling. We may need to tweak some internal abstractions though, but it still should be technically possible.
Implementation-wise, we need to override various input related methods in `QQuickItem`, e.g. `QQuickItem::mousePressEvent()`, `QQuickItem::hoverMoveEvent()`, etc.
We may potentially hit the problem with losing some input event data. For example, the `MouseEvent` type contains all of `QMouseEvent` data but also extra stuff, e.g. unaccelerated delta, etc.
This also begs a question regarding whether the scene should be in charge of deciding what focus object is.
This task is good opportunity to clean up existing input abstractions in kwin. For example, it would be nice to unify focus handling for regular and internal windows, i.e. kill InputDeviceHandler::internalWindow(), etc.https://invent.kde.org/plasma/kwin/-/issues/182Insufficient dependency definitions in cmake config2023-10-07T21:26:06ZYue LiuInsufficient dependency definitions in cmake configFor the dependency definitions in CMakeLists.txt, required dependencies are defined in two different ways:
- by using `find_package(XCB 1.10 REQUIRED COMPONENTS ...`, CMake would fail at this line if dependency not found
- by using
``...For the dependency definitions in CMakeLists.txt, required dependencies are defined in two different ways:
- by using `find_package(XCB 1.10 REQUIRED COMPONENTS ...`, CMake would fail at this line if dependency not found
- by using
```
find_package(KDecoration2 ${PROJECT_VERSION} CONFIG)
set_package_properties(KDecoration2 PROPERTIES
TYPE REQUIRED
PURPOSE "Required for server side decoration support"
)
```
Then with a `feature_summary(WHAT ALL INCLUDE_QUIET_PACKAGES FATAL_ON_MISSING_REQUIRED_PACKAGES)` at the end.
The second method is fine if there is no other CMake code before that line depending on those required dependencies. In this Kdecoration2 example, at https://invent.kde.org/plasma/kwin/-/blob/master/src/plugins/kdecorations/aurorae/src/config/CMakeLists.txt?ref_type=heads#L1 the variable `${KDECORATION_KCM_PLUGIN_DIR}` is required but it's only defined by CMake code within KDecoration2. Since missing KDecoration2 will not cause FATAL_ON_MISSING_REQUIRED_PACKAGES until the feature summary stage, if KDecoration2 is not available we are seeing error:
```
Must specify INSTALL_NAMESPACE for kcm_auroraedecoration
```
Without mentioning the actual error is missing KDecoration2 dependency.
To solve these kind of issues, we can either move all required dependency definitions to the first method, or move all the `add_package` and `feature_summary` calls before any `add_subdirectory` call, since CMake files in a subdirectory may have CMake config time dependency on a specific required dependency.https://invent.kde.org/plasma/kwin/-/issues/45Introduce snapshot tests2022-10-23T09:09:55ZVlad ZahorodniiIntroduce snapshot testsThe following discussion from !1043 should be addressed:
- [ ] @vladz started a [discussion](https://invent.kde.org/plasma/kwin/-/merge_requests/1043#note_249757): (+1 comment)
> I guess it's worth introducing "snapshot tests," i....The following discussion from !1043 should be addressed:
- [ ] @vladz started a [discussion](https://invent.kde.org/plasma/kwin/-/merge_requests/1043#note_249757): (+1 comment)
> I guess it's worth introducing "snapshot tests," i.e. the tests that setup the workspace, render a frame and then compare it with a reference screenshot. The problem is getting the reference screenshot.
Prior art: openQA. Could we have something like openQA in kwin?
---
Snapshot tests verify that the rendered scene is correct. The naive approach will be to compare the rendered frame and the reference frame pixel by pixel, however any small changes in rendering code may result in many red tests. It makes sense to have some metric that allows small errors.https://invent.kde.org/plasma/kwin/-/issues/19Introduce X11-specific and Wayland-specific sets of input event filters2023-08-29T12:58:27ZVlad ZahorodniiIntroduce X11-specific and Wayland-specific sets of input event filtersOn Wayland, features such as window actions and move/resize are implemented using generic input event filters. They work for all kinds of clients, e.g. XdgToplevelClient, InternalClient, etc.
The problem is that X11Client/XwaylandClient...On Wayland, features such as window actions and move/resize are implemented using generic input event filters. They work for all kinds of clients, e.g. XdgToplevelClient, InternalClient, etc.
The problem is that X11Client/XwaylandClient implements window management features as well using X11-specific stuff, which may conflict with the event filters.
In order to resolve that conflict, we need to introduce X11-specific and Wayland-specific sets of event filters and use only one of them based on whether we're running as a wayland compositor or as an x11 window manager.https://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.