Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2023-11-01T17:08:50Zhttps://invent.kde.org/plasma/plasma-desktop/-/issues/97[Approved] Plasma 6 proposal: enable tap-to-click by default2023-11-01T17:08:50ZGuilherme Marçal Silva[Approved] Plasma 6 proposal: enable tap-to-click by defaultI would like to propose enabling the tap-to-click option for all touchpads by default. A few distributions already enable it even though the upstream default is to leave it disabled. The current default was decided on [9 years ago](https...I would like to propose enabling the tap-to-click option for all touchpads by default. A few distributions already enable it even though the upstream default is to leave it disabled. The current default was decided on [9 years ago](https://gitlab.freedesktop.org/libinput/libinput/-/commit/2219c12c3aa45b80f235e761e87c17fb9ec70eae), when low-quality touchpads were more widespread. In the same vein as #94, that upstream default no longer represents the reality of most laptop users.
- Windows enables tap-to-click (and tap-and-drag) by default for millions of users without any widespread issues. Following the same default would make migrating users more comfortable with the transition. This also means that manufacturers already have to take care of touchpad quality and placement, making accidental clicks rare.
- Clicking physically requires repeated physical force, which can create repeated strain injuries or aggravate symptoms of carpal tunnel syndrome.
- If the touchpad has physical buttons at the bottom and the option is disabled, the user has to move the hand to a specific part of the laptop to click every time.
- Users of smartphones, which encompass virtually everyone, are already familiar with the concept of tapping to click on something. Translating that action to the touchpad means they don't have to learn another interaction pattern.
- Clicking physically wears down the touchpad, creating hardware problems over time.
- Depending on the quality of the touchpad, clicking physically can be noisy.
**Now to some data on multiple demographics:**
[Most Plasma users on r/kde enable tap-to-click.](https://www.reddit.com/r/kde/comments/159kbly/laptop_users_do_you_use_taptoclick_with_your/) Here I'm assuming they are probably experienced with computers since they follow r/kde and use Linux.
Even though tap-to-click is **disabled by default** on macOS and the trackpads of Apple computers are considered high-quality (so they should feel good to click physically), the preference for tapping to click is almost evenly split. Actually, as of the time of writing, more users prefer tap-to-click even though it's not the default: https://www.reddit.com/r/MacOS/comments/159knol/macbook_users_do_you_use_taptoclick_with_your/
Between Windows users on Reddit, the vast majority prefer tap-to-click: https://www.reddit.com/r/microsoft/comments/159ksb2/laptop_users_do_you_use_taptoclick_with_your/
In a subreddit where less tech-savvy people go to get recommendations about laptops, the preference towards tap-to-click is also seen: https://www.reddit.com/r/laptops/comments/159lupo/laptop_users_do_you_use_taptoclick_with_your/
And, if we want to make sure we're getting a varied sample of users, people on r/polls which is not a tech-related subreddit and that also encompasses users of laptops of different brands and operating systems, including Apple and Windows devices, also favor tap-to-click:
https://www.reddit.com/r/polls/comments/159lxr3/laptop_users_do_you_use_taptoclick_with_your/
@teams/vdg6https://invent.kde.org/plasma/plasma-desktop/-/issues/65[Approved] Plasma 6 proposal: remove System Settings Icon view2023-09-15T13:39:24ZNate Graham[Approved] Plasma 6 proposal: remove System Settings Icon viewIt doesn't support the "Highlight changed Settings" feature or the "Quick Settings" view, both of which were major features that were well-received by users. It's unmaintained and slowly bit-rotting, like the old tree view was until we r...It doesn't support the "Highlight changed Settings" feature or the "Quick Settings" view, both of which were major features that were well-received by users. It's unmaintained and slowly bit-rotting, like the old tree view was until we removed it. And the very concept of having multiple UI styles for a settings app seems like overkill; I think it would be best if we had just one and made it really good.
@teams/vdg6Carl Schwancarl@carlschwan.euCarl Schwancarl@carlschwan.euhttps://invent.kde.org/plasma/plasma-desktop/-/issues/73[Approved] Plasma 6 proposal: floating panels by default2023-11-18T02:54:50ZNiccolò Venerandi[Approved] Plasma 6 proposal: floating panels by defaultI propose to make the floating panels enabled by default, assuming that they
- De-float when touching a window (including when a window is maximized)
which is implemented, and
- Will gain shadows
- Do not expand vertically when they...I propose to make the floating panels enabled by default, assuming that they
- De-float when touching a window (including when a window is maximized)
which is implemented, and
- Will gain shadows
- Do not expand vertically when they touch a window
both of which should land really soon. Of course, floating can always be disabled by the user if they don't like it.6Niccolò VenerandiNiccolò Venerandihttps://invent.kde.org/plasma/plasma-desktop/-/issues/72[Approved (!)] Plasma 6 proposal: double-click to open files and folders by d...2023-08-18T13:23:27ZNate Graham[Approved (!)] Plasma 6 proposal: double-click to open files and folders by defaultThis was discussed and agreed to at Akademy 2022, but not everyone was there, so I'm opening this issue here to make sure all relevant voices are heard.
---
This debate has been going on for years, and basically boils down to the follo...This was discussed and agreed to at Akademy 2022, but not everyone was there, so I'm opening this issue here to make sure all relevant voices are heard.
---
This debate has been going on for years, and basically boils down to the following positions:
"Single-click is objectively better and more internally consistent for opening items, and those are more important than any concerns about familiarity for migrating users or usability when selecting items."
"Double-click is more familiar to people migrating from other systems and has objectively better usability for selecting items, and those are more important than what's better or more internally consistent for opening items."
FIGHT!
...or not, because over time, distros have been making the decision for us. At the moment, Kubuntu, Fedora KDE, and Manjaro all default to double-click, and these are major distros. Many of the major distros that do not change this setting follow upstream settings (e.g. Arch, Neon, Debian) so not switching doesn't imply satisfaction with the status quo, just a preference for or policy of not changing upstream settings. A couple of other smaller distros also default to double-click, such as NetRunner and FerenOS.
Distros are close to users and clearly the feedback they've been getting is that double-click is a better default.
Let's admit it and switch to double-click by default ourselves.6https://invent.kde.org/plasma/systemsettings/-/issues/13Simplify KCM Navigation on System Settings2023-01-03T00:02:27ZAndy BettsSimplify KCM Navigation on System SettingsI would like to propose a couple of changes for future versions of System Settings. It seems to me that our information concentration is big in the sidebar and it needs to find a way to present data to the user in more digestible way. I ...I would like to propose a couple of changes for future versions of System Settings. It seems to me that our information concentration is big in the sidebar and it needs to find a way to present data to the user in more digestible way. I also see that there is a current experience issue with the header changes in the sidebar as the user goes deeper into KCMs. I propose a solution for each.
For simplifying navigation in the sidebar, I propose moving the KCM shortcuts into a gallery grid. This provides a larger click target. The user can parse bigger items faster. The user is presented with extra options in a more transparent way. Each gallery item features a short description of the KCM they are about to enter making sure the user sees content in context.
Additionally, each KCM "supergroup" gets a short description above the gallery to invite the user to interact and explain the purpose of this section. Please note that looks are subject to change during development.
![Appearance](/uploads/71a4938a9288238fa5d13b129d45c39d/Appearance.png)
For the second element in the sidebar, I propose to use a generic "Back" label every time the user goes deeper into a KCM. This helps with the general space of the sidebar top label instead of creating a button with a label borrowed from the KCM's name. The user still has access to HOME as part of the sidebar and also can use the breadcrumb provided. This just seems cleaner.
![Global_Theme](/uploads/7f48d979bb3b5af7087708a489b989d2/Global_Theme.png)
Interactive janky mockup
https://www.figma.com/proto/JgzQf4XeCaZtm8h2RAeAov/(Cleaned-up)-KDE-Plasma-Mockups?page-id=3511%3A1461&node-id=3511%3A1462&viewport=241%2C48%2C0.61&scaling=min-zoom&starting-point-node-id=3511%3A1462&show-proto-sidebar=1
@teams/vdghttps://invent.kde.org/plasma/plasma-desktop/-/issues/61Plasma 6 proposal: remove all existing cursor launch feedback options and jus...2023-05-06T05:43:29ZNate GrahamPlasma 6 proposal: remove all existing cursor launch feedback options and just use the standard busy cursor insteadPreviously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
"Static" isn't an animation at all and looks really weird.
"Blinking" ...Previously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
"Static" isn't an animation at all and looks really weird.
"Blinking" looks quite terrible, almost broken.
"Bouncing" (the current default setting) is polarizing, with a vocal crowd of people who really hate it.
Ultimately I think all this configurability and the code driving them is not worth the maintenance and drama. Instead, we can just use the standard pointer+spinner cursor and automatically time it out after 5 seconds. No need for any configurability here, IMO.
@teams/vdg6https://invent.kde.org/plasma/plasma-desktop/-/issues/58[Approved] Plasma 6 proposal: remove the ability to configure icon sizes syst...2024-03-08T16:02:38ZNate Graham[Approved] Plasma 6 proposal: remove the ability to configure icon sizes systemwide in the icons KCMPreviously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
People use this setting as a way around using the global scaling slider...Previously discussed at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
People use this setting as a way around using the global scaling slider to make things bigger or smaller, and it's the wrong way to do it. It only scales some icons in some apps, and the proportions of everything else look wrong. This is a general theme: we need to fix our own bugs, rather than offer user-configurability that lets people work around the bugs themselves, which generally causes even more bugs in the process.
This setting doesn't affect non-Qt apps, almost all of KDE's own QtQuick apps, and even random icons in QtWidgets apps. It's one of those "broken promise" features that needs to be universal to work, and because universality isn't feasible or even possible, it can't really work.
Let's remove it.
@teams/vdg @teams/usability6https://invent.kde.org/plasma/plasma-desktop/-/issues/69Plasma 6 proposal: disable splash screen by default2023-05-14T19:13:48ZFushan WenPlasma 6 proposal: disable splash screen by defaultThe splash screen from ancient times was used to make people less anxious during the long period of a login process.
![图片](/uploads/d45359c740f32cb2952a9026c5ab5b74/图片.png)
But since Windows has become almost unusable with HDD, SSD is ...The splash screen from ancient times was used to make people less anxious during the long period of a login process.
![图片](/uploads/d45359c740f32cb2952a9026c5ab5b74/图片.png)
But since Windows has become almost unusable with HDD, SSD is popular nowadays. The splash screen on the contrary increases the loading time from entering password to the desktop finally being shown, brings negative performance hints about KDE Plasma. It's time to disable splash by default, and perhaps even remove it completely in Plasma 6.6https://invent.kde.org/plasma/plasma-desktop/-/issues/57[Approved] Plasma 6 proposal: remove the "Air" theme that currently lives in ...2023-05-06T05:46:02ZNate Graham[Approved] Plasma 6 proposal: remove the "Air" theme that currently lives in Plasma frameworkPreviously discussed and agreed to at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
This theme hasn't gotten maintenance in years, and should...Previously discussed and agreed to at https://invent.kde.org/teams/vdg/issues/-/issues/16, but I'm moving it here for more visibility, since this is the better place for it.
---
This theme hasn't gotten maintenance in years, and should live on store.kde.org if we want to preserve it.
@teams/vdg6https://invent.kde.org/plasma/kwin/-/issues/22Better compositing timing algorithm2023-08-29T12:58:27ZVlad ZahorodniiBetter compositing timing algorithm# Motivation
The main motivation behind this task is to reduce the latency caused by compositing, particularly make dragged windows lag less behind the cursor, and unlock per screen rendering on Wayland.
# Current state
Due to KWin be...# Motivation
The main motivation behind this task is to reduce the latency caused by compositing, particularly make dragged windows lag less behind the cursor, and unlock per screen rendering on Wayland.
# Current state
Due to KWin being originally an X11 window manager and compositing manager, the compositing infrastructure is heavily based on Xinerama-style rendering. This means that we have a single compositing timer, if you have several outputs with different refresh rate, the refresh rate will be capped to the lowest one, etc. A typical compositing cycle looks as follows
![before](/uploads/2ec7396478226a1499dd1534b8a86b93/before.png)
First of all, you've probably noticed that eglSwapBuffers() and glxSwapBuffers() are called at the next vblank. This is to ensure that we start compositing after a vblank. Second thing is that, in the best scenario, we have a latency of at least one frame. It worked okay-ish on X11, but we need something better...
# Proposed design
In order to reduce the latency, the compositor has to perform compositing right before the next vblank, i.e.
![ideal](/uploads/f37fd13c9ea9a98e27c9f078e0ccb958/ideal.png)
With this design, we don't start compositing at a vblank. Instead, we just send frame callbacks. This way, all that precious time after frame callbacks have been sent and before the next compositing cycle starts can be used by clients to submit new buffers.
However, it introduces a new problem - we may miss the next vblank if it takes more than usual amount of time to composite the next frame for various reasons, e.g. the GPU is too loaded up, etc. Our compositing timing algorithm will have to be aware of that and keep the compositing window dynamic to avoid dropping frames.
In order to separate compositing scheduling from the actual act of performing compositing, it's better to introduce a new type whose sole purpose is to pick the best moment to perform compositing. Let's call it `RenderLoop`. On Wayland, we want every output to have its own render loop, e.g.
![per-screen-rendering](/uploads/be7dd83736bde3aaf67a7f9bfff402f5/per-screen-rendering.png)
_Note: VBlanks for outputs with the same refresh rate are not necessarily synchronized_
On X11, per screen rendering is not possible with Xinerama, so the most sensible option is to have a single render loop provided by the platform that drives compositing.
# Timeframe
We want to get this all done in 5.21.
# Testing
With this sort of things, we need a way to visualize when kwin starts compositing. For this purpose, ftrace can be used. I know that d_ed has a WIP patch for that.5.21Vlad ZahorodniiVlad Zahorodniihttps://invent.kde.org/plasma/bluedevil/-/issues/1KCM redesign2020-09-03T10:19:11ZNicolas FellaKCM redesignThe KCM should be redone according to current standards, i.e. QML.
This is also a good opportunity to merge the three KCMs into oneThe KCM should be redone according to current standards, i.e. QML.
This is also a good opportunity to merge the three KCMs into onehttps://invent.kde.org/plasma/plasma-desktop/-/issues/63[Approved] Plasma 6 proposal: delete some of the Task Switchers from kdeplasm...2024-03-01T18:08:58ZNate Graham[Approved] Plasma 6 proposal: delete some of the Task Switchers from kdeplasma-addons* Grid (Thumbnail Grid is better and doesn't take up the entire screen)
* Informative (it's the same as Compact but with less space efficiency)
* Thumbnails (it scrolls horizontally after only 5 or 6 windows, which is really awkward and ...* Grid (Thumbnail Grid is better and doesn't take up the entire screen)
* Informative (it's the same as Compact but with less space efficiency)
* Thumbnails (it scrolls horizontally after only 5 or 6 windows, which is really awkward and unpleasant; same issue as the "Breeze" sidebar style switcher)
* Small Icons (tiny icons are very hard to see and window title text is always elided into uselessness)
* Text Only (it's like Compact but worse without icons, since this loses visual scanability)
@teams/vdg @teams/usability6https://invent.kde.org/plasma/plasma-desktop/-/issues/55[Approved] Plasma 6 proposal: Disable scroll on desktop to switch virtual des...2024-03-07T01:50:30ZNate Graham[Approved] Plasma 6 proposal: Disable scroll on desktop to switch virtual desktops by defaultIn general it's non-optimal for scrolling to trigger hidden behavior, unless that behavior is benign, does not change the entire screen contents, and seems connected to the thing you scrolled on. Scrolling over the volume icon to change ...In general it's non-optimal for scrolling to trigger hidden behavior, unless that behavior is benign, does not change the entire screen contents, and seems connected to the thing you scrolled on. Scrolling over the volume icon to change the volume satisfies these criteria; scrolling on the desktop to change the virtual desktop does not. The user can easily scroll on the desktop by accident and have the entire screen contents changed without knowing how to get back. And if the virtual desktop they switched to has a maximized window on it, they won't be able to see the desktop to scroll to get back.
This should be considered an expert feature, and hence disabled by default.
@teams/usability6https://invent.kde.org/plasma/plasma-workspace/-/issues/40[Approved] Plasma 6 Proposal: Add new Blue Ocean sound theme to Plasma2023-10-17T15:46:49ZGuilherme Marçal Silva[Approved] Plasma 6 Proposal: Add new Blue Ocean sound theme to PlasmaThe new Blue Ocean sound theme is finally here. It is meant to replace Oxygen sounds and add new sounds that improve usability, like those for un/plugged devices. Oxygen still offers some sounds that this theme does not replace, mainly s...The new Blue Ocean sound theme is finally here. It is meant to replace Oxygen sounds and add new sounds that improve usability, like those for un/plugged devices. Oxygen still offers some sounds that this theme does not replace, mainly sounds for instant messaging apps and window actions like minimizing or maximizing.
The files for the Blue Ocean sound theme can be found in this repository: https://invent.kde.org/plasma/ocean-sound-theme
There is also another theme called Harmony made by Gianmarco which can be found here: https://dl.gianmarco.ga/Dream%20Sounds/Harmony/%21Download%20all%20v1.3.zip
Here are other technical changes that are needed to make this a reality:
~~**Blocker bugs:**~~
- [x] ~~The Start-up sound is not played: https://bugs.kde.org/show_bug.cgi?id=422948 (fixed by: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2313)~~
**Changes needed:**
- [x] ~~Un/plugging USB device should produce sound (https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2106)~~
- [x] ~~Sounds could follow XDG spec: #47 http://0pointer.de/public/sound-theme-spec.html and http://0pointer.de/public/sound-naming-spec.html~~
- [x] Use custom sound for changing the volume: https://invent.kde.org/plasma/plasma-pa/-/merge_requests/202
All sounds in the Blue Ocean sound theme are in 16-bit, 48000hz .oga targeting 320Kbps VBR, normalized using the ReplayGain plugin in Audacity. The XDG spec does not specify a specific normalization level, only that "The sound samples must be normalized with a suitable average replay level, in order to be properly mixed down.". I used Windows sounds as a reference and noticed their volume is unchanged when using ReplayGain with a -3dB gain, so that's the value I'm using.6https://invent.kde.org/plasma/plasma-workspace/-/issues/24"Simple by default, powerful when needed" applied to multi-monitor2023-11-28T14:35:08ZNate Graham"Simple by default, powerful when needed" applied to multi-monitorWe discussed this a bit in the Plasma 5.24 kickoff meeting on Monday 19 October 2021. Here's my pitch:
## The problem
Right now multi-monitor users are terribly confused about:
1. What the "Primary Monitor" setting means and does and w...We discussed this a bit in the Plasma 5.24 kickoff meeting on Monday 19 October 2021. Here's my pitch:
## The problem
Right now multi-monitor users are terribly confused about:
1. What the "Primary Monitor" setting means and does and why it's not present on Wayland
2. What determines the screen that apps and notifications appear on, and how they change it
3. How they determine which screen their panel and containment should live on
4. How to move panels from one screen to another
5. How to move containments from one screen to another
6. How to get the same panel on multiple screens without mirroring the whole screen
In reality, the Primary Monitor setting does \#2 only for certain non-KDE apps and many games; it kind of does \#3 and \#4 but conflicts with other ways to move panels, and there is no way to do \#5 and \#6 right now. It's no wonder that people are confused!
---
I have a proposal in line with Plasma's "Simple By Default, Powerful When Needed" motto:
## Simple By Default
Now that the "Primary Monitor" setting is present in the KScreen KCM on both X11 and Wayland, we make it determine which screen shows your "primary containment"--defined as the containment that started out life with Folder View and the default panel on it (i.e. the first one you had). The whole containment automatically moves to whichever screen you designate as the primary monitor in the KScreen KCM. Notifications and new windows also automatically open on this screen. And the KScreen KCM gains some explanatory text to indicate all of this.
By default, other monitors cannot have independently-determined panels, and panels can no longer be manually dragged to another screen; it would be too confusing. Instead, we provide a simple UI to let people "mirror" the primary containment's panels across other screens, keeping them in sync with a single common set of settings.
In addition, by default widgets cannot be added to the desktop on secondary screens as this allows the risk of data loss (e.g. if you add text to a sticky note on a secondary screen and turn off the screen, that text becomes inaccessible).
It should remain possible to drag files from a Folder View containment on the primary screen onto a secondary screens, though. When any such screens are turned off, the icons on those screens would jump back to their prior locations on the primary screen's Folder View containment.
## Powerful When Needed
In the UI that allows the user to mirror their primary screens' panels onto a secondary one, we provide access to another feature: the ability to have custom layouts on secondary screens. This would essentially enable what we have today--full editability of secondary containments. Custom panels, widgets, desktop vs folder view, you name it. When the user activates this feature, we display a warning telling them that any panels and widgets they add to a custom secondary containment like this will become inaccessible when its screen is turned off.
It would also provide a way to change which containment is considered the "primary" one; clone panels; and mirror panels or containments across any or all screens. Optionally, we can provide a way for users using this feature to gain access to any currently inaccessible containments via an advanced UI, like what's being proposed in https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/618
---
An advantage to this proposal is that it happens to largely mirrors our how users *think* the system works, even if it doesn't already work this way! And experts would have more powerful tools to deterministically configure their panels and containments than they have right now.
cc @teams/usability @teams/vdg @davidedmundson @mart @apol @vladz @merritthttps://invent.kde.org/plasma/plasma-desktop/-/issues/82[Approved] Plasma 6 proposal: remove the concept of icons in the Plasma theme2023-08-18T17:45:37ZNate Graham[Approved] Plasma 6 proposal: remove the concept of icons in the Plasma themeOnce upon a time, this was implemented so that System Tray icons and other icons on the panel could be monochrome. This looked better than putting a jumble of colorful icons on the panel, and still looks better today.
However, it causes...Once upon a time, this was implemented so that System Tray icons and other icons on the panel could be monochrome. This looked better than putting a jumble of colorful icons on the panel, and still looks better today.
However, it causes a lot of subtle edge-case issues and user confusion, because now there are two sources of icons, and the rules for which source gets used where are unclear and unpredictable. Everything mostly works when using the Breeze icon theme and Breeze Plasma theme, but anytime you switch one or both of those to a theme that doesn't match with the other, all kinds of subtle icon source bugs crop up and your panel looks weird in random-seeming ways. See all the bugs in the "See also" list of https://bugs.kde.org/show_bug.cgi?id=438191
I'd like to propose for Plasma 6 that we remove the concept of icons in Plasma themes; instead, icons would always come from the icon theme for simplicity and comprehensibility.
---
Relatedly:
To facilitate the legitimate design goal to have monochrome app and plasmoid icons on the panel and not-always-monochrome icons elsewhere in the icon theme (see https://phabricator.kde.org/T10413), we have now settled on using the `-symbolic` suffix for monochrome icons in Plasma 6 and beyond. We now need to do the following:
- In all KDE software, every time we ask for an icon we want to never be colorful, ask for the icon name with `-symbolic` appended
- Rename all of our monochrome Breeze icons to end with -symbolic
(These changes can be done over time and are not mandatory)
---
Merge requests implementing this change:
- All of the work done for https://invent.kde.org/plasma/plasma-workspace/-/issues/82
- https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1640
- https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3138
- https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/439
To test those merge requests, use the Breeze icon theme and a non-default Plasma theme that includes some of its own icons (e.g. Adapta, Layan, Materia) and look for non-Breeze icons in widgets. There shouldn't be any. Then change your icon theme to something other than Breeze. You should see that the new icons from the icon theme apply to Plasma things too now.6https://invent.kde.org/plasma/kwin/-/issues/85Handling cursor updates with VRR2024-03-11T20:04:34ZXaver HuglHandling cursor updates with VRRWith VRR we have a conflict between smooth cursor updates and smooth application content - only one can be made smooth, and which to prefer depends heavily on the user preference and the application in question.
Currently, we're solving...With VRR we have a conflict between smooth cursor updates and smooth application content - only one can be made smooth, and which to prefer depends heavily on the user preference and the application in question.
Currently, we're solving that problem by having cursor updates always force a repaint, but for some games that is not a good idea. In some other situations, like a video or animation playing at 60Hz, it would also be preferable to have the cursor update with LFC at 120Hz, if the hardware can do that. Sadly, we currently have neither the option of LFC cursor updates nor any knowledge about the content we show.
Options to improve the situation are
- [ ] make a dumb setting for which to prefer. This is pretty horrible, as it requires the user to switch back and forth manually. As generally there's only very few games where cursor refreshes are actually annoying, maybe it's acceptable as a first step though
- [ ] make a setting for a minimal cursor refresh rate. Could cause the cursor to be rather jumpy though without page flip scheduling in the kernel
- [ ] make a window rule. Better than a dumb switch but not exactly discoverable
- [ ] improve the situation on upstream protocols like [content-type](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/117) first, then use those to make better / more granular settingshttps://invent.kde.org/plasma/kdeplasma-addons/-/issues/5Renmae repo from kdeplasma-addons to plasma-addons2020-11-05T07:07:20ZYunhe Guoi@guoyunhe.meRenmae repo from kdeplasma-addons to plasma-addonsTo be aligned with plasma-desktop, plasma-workspace, etc.
As mentioned in https://phabricator.kde.org/T13834 , we have to get enough approvals here to proceed. So I would like to ask all contributors of this repo to give your opinion in...To be aligned with plasma-desktop, plasma-workspace, etc.
As mentioned in https://phabricator.kde.org/T13834 , we have to get enough approvals here to proceed. So I would like to ask all contributors of this repo to give your opinion in comments.
If you like the idea, click :thumbsup:, otherwise click :thumbsdown: under the issue description.https://invent.kde.org/plasma/plasma-desktop/-/issues/105[TBD] Plasma 6 proposal: Fullscreen application launcher based on Kickoff2023-08-31T01:34:07ZFushan Wen[TBD] Plasma 6 proposal: Fullscreen application launcher based on Kickoff# Background
The existing application dashboard (referred as "fullscreen launcher") [has a questionable technical architecture and is completely broken in Plasma 6](https://invent.kde.org/plasma/plasma-workspace/-/issues/88). Most exist...# Background
The existing application dashboard (referred as "fullscreen launcher") [has a questionable technical architecture and is completely broken in Plasma 6](https://invent.kde.org/plasma/plasma-workspace/-/issues/88). Most existing fullscreen launchers on sko are also based on the broken fullscreen launcher, so they are also likely to fail, which means there will be no usable fullscreen launcher in Plasma 6.
# Reasons
It's difficult to quickly completely understand what people really need when they use the fullscreen launcher and its variants. [Some are using it on small-screen devices, and some are using it on full desktops.](https://discuss.kde.org/t/fullscreen-kickoff/4281) If there are still many users using the fullscreen launcher, it might make sense to make a new fullscreen launcher following the design of Kickoff. Reasons given below:
1. The design of the new Kickoff has [gone through multiple rounds of prototyping](https://phabricator.kde.org/T12192), making the final product have good usability, and people seem to be in favor of the current Kickoff as [there are few negative reports](https://bugs.kde.org/buglist.cgi?component=Application%20Launcher%20%28Kickoff%29&list_id=2456024&product=plasmashell&resolution=---).
2. The current Kickoff has already implemented the features available in the fullscreen launcher except for the widget browser, and it's questionable whether it's useful to browse widgets in an application launcher as [many forks of the fullscreen launcher have removed the feature](https://store.kde.org/p/1897990). People using the existing fullscreen launcher will not feel anything incomplete in the new fullscreen launcher.
As I believe users tend to use the fullscreen launcher on touch-capable devices, to adapt Kickoff design to the fullscreen launcher, a few changes will be made:
1. No information overload: A fullscreen view will only serve for a single purpose, which means the home page will no longer be crowded with favorites and application lists, making buttons bigger and more touch-friendly.
2. Less tab, more swipe: Using tabs to navigate is not touch friendly. People are more used to swiping to switch views on mobile platforms.
# Plans
A few fullscreen launcher prototypes will be made to more quickly get feedbacks from the users. A final product will be made after a consensus is reached.6https://invent.kde.org/plasma/plasma-workspace/-/issues/93[Approved] Split battery applet into two: "Power Management" and "Brightness"2023-11-18T18:12:23ZNatalie Clariusnatalie_clarius@yahoo.de[Approved] Split battery applet into two: "Power Management" and "Brightness"This was raised here https://bugs.kde.org/show_bug.cgi?id=424283 but I would like to get some more opinions on it from people who are involved in the code. Since we're going to want to dig the applet over to port away from data engines s...This was raised here https://bugs.kde.org/show_bug.cgi?id=424283 but I would like to get some more opinions on it from people who are involved in the code. Since we're going to want to dig the applet over to port away from data engines soon anyway this would be a natural breaking point.
Reasons in favor imo:
1. There is no strong reason the two should be in the same applet to begin with; surely brightness affects power usage, but so does wifi, bluetooth and just about anything you do on your computer, and it's not relevant for external screens either, so it seems a little random to put these two in the same place.
2. The applet is getting full: We now have block inhibiting, screen brightness, keyboard brightness, power profile, battery status for the laptop, battery health for the laptop, battery status for bluetooth devices - this already fills the default applet popup size, and we are planning to include more brightness sliders for both internal and external screens, and potentially backlight color setting for RGB keyboard, so the applet would have to be scrolled or manually resized to access all controls which is not ideal.
Resaons against:
1. More tray icons, which some users don't like
Even as someone who doesn't like many tray icons myself I think a split makes sense.
@teams/usability @teams/vdg @fusionfuture @ratijas @ngraham