Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2023-12-04T23:48:23Zhttps://invent.kde.org/plasma/plasma-desktop/-/issues/91[Approved] Plasma 6 Proposal: incubate SDDM2023-12-04T23:48:23ZNate Graham[Approved] Plasma 6 Proposal: incubate SDDMBeing a non-KDE project necessarily imposes more distance and loses certain opportunities for tighter integration, like the kind that GNOME has with their GDM login manager. It would be of long-term benefit to tighten integration between...Being a non-KDE project necessarily imposes more distance and loses certain opportunities for tighter integration, like the kind that GNOME has with their GDM login manager. It would be of long-term benefit to tighten integration between SDDM and Plasma to improve the UX in a way that incubation within KDE could achieve.
At this point nearly all SDDM development comes from KDE devs anyway, so it's already sort of de facto incubated in all but name and release schedule. On that subject, being a part of presumably the Plasma release cycle would also ensure that SDDM gets regular releases, which it is desperately in need of.
Obviously we would need to talk with the prior maintainer Pier Luigi Fiorini about this.6https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12Add support for InputCapture portal and RemoteDesktop ConnectToEIS2024-03-21T11:13:19Ztheofficial gmanAdd support for InputCapture portal and RemoteDesktop ConnectToEISInputCapture portal spec has been finalized and merged in xdg-desktop-portal https://github.com/flatpak/xdg-desktop-portal/pull/714
It has also been implemented and merged into xdg-desktop-portal-gnome https://gitlab.gnome.org/GNOME/xdg...InputCapture portal spec has been finalized and merged in xdg-desktop-portal https://github.com/flatpak/xdg-desktop-portal/pull/714
It has also been implemented and merged into xdg-desktop-portal-gnome https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/61
This isssue is a request that it be implemented in xdg-desktop-portal-kdehttps://invent.kde.org/plasma/plasma-workspace/-/issues/35Deprecate and remove Activities2024-02-11T00:39:53ZNate GrahamDeprecate and remove ActivitiesIt is with a heavy heart that I write this, but the Activities feature suffers from multiple significant issues and I think it should be deprecated in Plasma 5 and deleted in Plasma 6.
# It's confusing and doesn't work for common use ca...It is with a heavy heart that I write this, but the Activities feature suffers from multiple significant issues and I think it should be deprecated in Plasma 5 and deleted in Plasma 6.
# It's confusing and doesn't work for common use cases
Activities are difficult to understand, as they have an unclear scope. An Activity contains a private, activity-specific repository of certain but not all sources of config and state data. Because it does not encompass all settings and all state, figuring out what parts of the shell and user apps are Activity-aware is a guessing game. For the apps that do support it, support must be specifically added, which in practice means that only a very small number of apps will ever be Activity-aware, so means the system cannot work generically. Most users use more than just Activity-aware KDE apps. The more this is true, the less Activities work or make sense.
# It makes everything it touches buggier
Activities contribute to a combinatorial explosion of options that makes bugs easy to encounter and difficult to triage, especially for things that *are* Activity-aware, such as desktop containments and panels. Users who use Activities can and do suffer loss of data or important state.
# It isn't maintained
The feature seems to be effectively abandoned. I have not seen any substantive work to fix bugs, add new features, or add support for additional apps during the 5 years I have been involved in KDE. Most KDE developers don't use it, aren't familiar with its code, and avoid bug reports about it. The feature is slowly bit-rotting.
---
With the above in mind, I think Activities' disadvantages outweigh its advantages and we should deprecate it and begin porting away from it, with the goal of removing it in Plasma 6. Features can be migrated back to Virtual Desktops as needed--for example [per-virtual-desktop wallpapers](https://bugs.kde.org/show_bug.cgi?id=341143).https://invent.kde.org/plasma/plasma-desktop/-/issues/52[Approved] Plasma 6 proposal: change the release schedule2024-02-27T13:48:02ZNate Graham[Approved] Plasma 6 proposal: change the release scheduleI'd like to discuss the Plasma release schedule, because it presents a few issues:
1. Shipping three big Plasma releases a year doesn't generally leave enough time for adequate QA and bugfixing before release, contributing to .0 release...I'd like to discuss the Plasma release schedule, because it presents a few issues:
1. Shipping three big Plasma releases a year doesn't generally leave enough time for adequate QA and bugfixing before release, contributing to .0 releases being buggy. It interacts awkwardly with the release schedules of several big discrete-release distros such as Kubuntu and Fedora, causing them to frequently make distro releases that have a version of Plasma that's 6+ months old and already out of support from the KDE perspective. It also often causes the last month or two of some Plasma development cycles to coincide with the holiday season and Akademy which isn't ideal because developers' attentions are split. Finally, it stresses the Promo team's resources, so they often can't spend enough time polishing each individual release announcement.
2. Our beta periods are quite short and the beta isn't updated after its initial release, so beta testers frequently report already-fixed issues, wasting everyone's time.
3. Coming up with 3 new wallpapers a year--one per Plasma feature release--has been extremely challenging for VDG.
---
To address these issues, I would like to propose the following changes for Plasma 6:
We go down to two feature releases per year, and we adjust the schedule to release them in early March and early September.
With that extra time, we lengthen each feature release's beta period to 6 weeks and update the beta every week.
---
My hope for these changes would be more stability, less user confusion, better alignment with distro release schedules, and better use of the Promo team's resources.6https://invent.kde.org/plasma/kwin/-/issues/198Suggestion to include the KDE-Rounded-Corners as a part of KWin2024-01-23T14:53:11ZMatin LotfalieiSuggestion to include the KDE-Rounded-Corners as a part of KWinHi. I am the maintainer of [KDE-Rounded-Corners](https://github.com/matinlotfali/KDE-Rounded-Corners) which is a KWin effect to round window corners even without decoration.
The effect pushes a shader to: 1) hide corners 2) draw a round...Hi. I am the maintainer of [KDE-Rounded-Corners](https://github.com/matinlotfali/KDE-Rounded-Corners) which is a KWin effect to round window corners even without decoration.
The effect pushes a shader to: 1) hide corners 2) draw a round outline 3) draw shadows beneath rounded areas.
Because it is just using a shader, I don't believe it to have a significant effect on the performance.
I would like to suggest this effect to become part of KWin and I would like to volunteer to maintain it.
I will be open to your comments.
Matinhttps://invent.kde.org/plasma/kwin/-/issues/169Roadmap to Vulkan2024-01-06T22:32:58ZXaver HuglRoadmap to VulkanVulkan brings some advantages like async compute, better defined behavior and in general more control over the specifics of what's happening. This is a rough plan on how to get there, and how to do it in steps, without having one giant m...Vulkan brings some advantages like async compute, better defined behavior and in general more control over the specifics of what's happening. This is a rough plan on how to get there, and how to do it in steps, without having one giant merge request
# Basic infrastructure
- require Vulkan 1.3 and all the extensions that make our lives easier. We have OpenGL as a fallback, so compatibility can effectively be ignored
- add Vulkan support to the Wayland backend, to create a device and allow for testing
- export texture to OpenGL and use OpenGL compositing with a Vulkan backend at first
- port shaders to Vulkan, add CMake command to compile it to SPIR-V at built time
- scene: paint items, without any effects as a start
# Libkwineffects
- add infrastructure for Vulkan objects
- add infrastructure for Vulkan <-> OpenGL interop
- port offscreen effects to use Vulkan <-> OpenGL interop
- import Vulkan textures into QtQuick
- port:
- contrast to Vulkan
- blur to Vulkan
- colorpicker to Vulkan
- invert to Vulkan
- magnifier to Vulkan
- mouseclick to QML
- mousemark to QML
- screenedge to QML
- screenshot to Vulkan
- screentransform to Vulkan
- showpaint to Vulkan
- snaphelper to QML
- touchpoints to QML
- trackmouse to QML
- zoom to Vulkan
- startupfeedback to Vulkan or QML
# Other plugins
- qpa: port to Vulkan, or use OpenGL interop
- screencast: port to get a buffer instead of a texture from the backend -> screencast code can mostly stay untouched besides that
# Other backends
- virtual backend: should be very straight forward, it's just one texture
- drm backend: write a replacement for `EglGbmBackend` + `EglGbmLayer`. To simplify multi gpu, only support setups where all GPUs support Vulkan
# Long term goals
- make use of asynchronous compute for simple scenes (no active effects)
- port effects from Vulkan <-> OpenGL interop to use Vulkan directly?
- port shader loading to Qt's shader infrastructure? (QTBUG-113331)6https://invent.kde.org/plasma/systemsettings/-/issues/15Flattened navigation with logically combined KCMs2024-03-17T06:37:49ZNate GrahamFlattened navigation with logically combined KCMshttps://invent.kde.org/plasma/systemsettings/-/issues/13 proposes to nest KCMs more deeply and expose a small number of high-level items as quick settings pages specific to their category, with all KCMs being accessed from within them.
...https://invent.kde.org/plasma/systemsettings/-/issues/13 proposes to nest KCMs more deeply and expose a small number of high-level items as quick settings pages specific to their category, with all KCMs being accessed from within them.
I'd like to make a proposal that is sort of the opposite: we flatten the hierarchy completely and expose only top-level KCMs. To accomplish this without overwhelming users with too many top-level options, many KCMs would have their contents merged into others, or embedded as sub-pages of existing KCMs they are logically related to. Many top-level KCMs therefore become slightly higher-level in concept (e.g. the new "Colors & Themes" KCM, while others are moved up to make them more discoverable (e.g. the new "Mouse & Touchpad" KCM).
## Legend
`kcm1 [thing1, thing2]` means "thing 1 and thing 2 are integrated into kcm1's main view"
`kcm1 {thing1, thing2}` means "thing 1 and thing2 are embedded into kcm1 as sub-pages"
## Proposed organization
```
Input & Output - 5-8 items
--------------
- Mouse & Touchpad [single/double-click setting and scrollbar clicking behavior from the General Behavior KCM] {Screen Edges} (auto-hides when no mice or touchpads are attached)
- Keyboard {Virtual Keyboard, Shortcuts}
- Touchscreen {Touchscreen Gestures} (auto-hides when no graphics tablets are attached)
- Graphics Tablet (auto-hides when no graphics tablets are attached)
- Game Controller (auto-hides when no game controllers are attached)
- Sound
- Display & Monitor {Gamma}
- Accessibility [Desktop Effects from the Accessibility category, Tooltip and OSD settings from the General Behavior KCM]
Connected Devices - 4-5 items
-----------------
- Bluetooth
- Disks & Cameras [Device Actions, Digital Cameras]
- Thunderbolt (auto-hides when the hardware has no Thunderbolt ports)
- KDE Connect
- Printers
Internet - 2 items
--------
- WiFi & Networking {Firewall, all the miscellaneous Connections KCMs}
- Online Accounts
Appearance & Style - 4 items
------------------
- Wallpaper
- Colors & Themes [Global Themes, Accent color] {Colors, Night Color, Application Style's theme page, Plasma Style, Window Decorations, Icons, Cursors, Sound Theme, Splash Screen, SDDM, Boot Splash Screen}
- Text & Fonts {Font Management}
- Animations [Global animation speed slider, purely visual Desktop Effects, relevant things from Compositor KCM]
Apps & Windows - 4 items
--------------
- Default Applications {File Associations}
- Notifications
- Window Management {Window Behavior, Task Switcher, Desktop Effects from the Window Management category, Application Style's titlebar buttons page, Window Rules, KWin Scripts, Virtual Desktops}
- Activities
Workspace - 3 items
---------
- General Behavior (to be deleted eventually)
- Search [Plasma Search {Web Shortcuts}, File Search]
Security & Privacy - 4 items
------------------
- Screen Locking
- App Permissions [Flatpak Permission settings] {Legacy X11 App Support}
- KDE Wallet
- Recent Files
- User Feedback
Language & Time - 3 items
---------------
- Language & Formats
- Spell Check
- Date & Time
System - 6 items
------
- About
- Energy Saving {Advanced Power Saving}
- Software Update
- Users
- Autostart
- Session [the behavior part of SDDM] {Background Services, Locations}
```
Status quo: 6 categories (one implicit with no header) with 28 top-level items and many child items inside them
Proposal: 9 categories with 35-39 top-level items in them and no children
---
Any KCMs not listed above are removed because their settings/functionality are merged into other more appropriate KCMs.
With this proposal, we would need to gain the ability to embed a KCM inside another one as a sub-page. Sub-page KCMs would still appear in search results, but not in the sidebar or icon view.
@teams/vdg @teams/usability6https://invent.kde.org/plasma/kwin/-/issues/10Make tiling a first-class citizen2023-08-29T12:58:27ZUros PerisicMake tiling a first-class citizenThere are countless tiling plugins (KWin scripts, all of which break in Wayland sessions) for KWin. The feature is obviously desired, but as things stand, using them requires ugly hacks like:
- tweaking window decorations
- ensuring wind...There are countless tiling plugins (KWin scripts, all of which break in Wayland sessions) for KWin. The feature is obviously desired, but as things stand, using them requires ugly hacks like:
- tweaking window decorations
- ensuring windows are never natively maximized
- ignoring size hints in some programs like system settings
- etc.
It would be nice if this feature was more accessible and only a toggle away like it is in [Pos!_OS](https://github.com/pop-os/shell). Tiling window managers aren't just for technical users. That's a consequence of how difficult they are to set up. And KDE isn't Gnome, leaving every tweak to plugins. Something like [Krohnkite](https://github.com/esjeon/krohnkite) integrated into KDE would bring tiling to the casual Linux user, where it belongs.
The ability to hide window decorations and add borders indicative of the active window regardless of style (breeze/oxygen/etc.) would also be a prerequisite for this feature IMHO.
Thoughts?https://invent.kde.org/plasma/kwin/-/issues/117Virtual Desktops for Plasma 62024-02-28T16:05:00ZXaver HuglVirtual Desktops for Plasma 6This is sort of part of the Activities discussions, but because it's a pretty large topic without them as well I split out this issue for VDs.
# Status Quo
There's a grid of n \* m virtual desktops. These VDs are static, cover all outpu...This is sort of part of the Activities discussions, but because it's a pretty large topic without them as well I split out this issue for VDs.
# Status Quo
There's a grid of n \* m virtual desktops. These VDs are static, cover all outputs and are the same in all Activities. When you switch VDs, all windows on all monitors switch VDs. When you switch Activities, by default it stays in the same virtual desktop position or optionally switches you to the last VD used in the switched-to Activity.
# Use cases
I think these are the two high level use cases we have to take care of:
1. permanent spatial separation of smaller tasks or applications. An example for this would be that you always put the music player on a specific VD, the IDE on a different one etc
2. providing more space to work with, but without any persistent task association. Effectively VDs are additional monitors for this use case
I'll call these (1) static and (2) dynamic setups from here on.
# Multi Monitor
There's two options in regards to multi monitor:
1. All monitors are on the same VD. Switching VDs will move the state on all monitors
2. All monitors have a separate list of VDs. Both options to switch only on one monitor and on all monitors at once can be provided
# Activities
Generally it makes sense for both static and dynamic setups for VDs to be completely separate per Activity.
Ideally, the dynamic/static state would also be per Activity, but if it makes the implementation simpler I think it wouldn't be a large loss to make it be the same in all Activities. Same for multi monitor options; it's probably not necessary to support a different setting per Activity.
# What to (not) support
In order to limit the complexity of both implementation and UX, a line has to be drawn somewhere. I think we can simplify these things:
- static setups + per monitor VD layouts. Static setups should be required to have the same amount of VDs per monitor, so that we have a clear and intuitive mapping of what should happen when you unplug a monitor with windows still on it (-> move into the matching VD on the other monitor)
- dynamic setups + VD grids. While not impossible, grids do make the UX more complex, especially if VDs are automatically added and removed. So I think we should just not support that
- naming VDs in dynamic setups. Names create the illusion that VDs would be somehow permanent when they're not, so that should not be supported either.
- sharing VDs between Activities. With Activities being explicit separation between environments, sharing VDs doesn't make any sense and should not be supported
- apps interacting with VDs. The usefulness is questionable and creates very different API requirements, so keeping access restricted to plasmashell in the new implementation would be sensible
# How to get there
In order for KWin internals to change, the outward facing APIs must also change; that's what more or less requires such a change to happen with the Plasma 6 transition. The APIs to change would be:
- Wayland: https://invent.kde.org/libraries/plasma-wayland-protocols/-/blob/master/src/protocols/plasma-virtual-desktop.xml, can be easily extended. Adopting https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40 would also be in the cards, it supports pretty much everything we need
- X11: https://invent.kde.org/frameworks/kwindowsystem/-/blob/master/src/platforms/xcb/netwm.h, need to create new API for that
- also dbus for some reason? https://invent.kde.org/plasma/kwin/-/blob/master/src/virtualdesktopsdbustypes.cpp
- Effects and scripting
I haven't started properly looking into any implementations yet, but if we need to break backwards compatibility with other X11 DEs anyways, we could directly switch to a dbus protocol or sth that can be used on both Wayland and X11https://invent.kde.org/plasma/kwin/-/issues/11Color management on Wayland2023-12-18T16:40:52ZVlad ZahorodniiColor management on WaylandOne of the things that had been discussed during a kwin sprint in July 2019 was color management. Currently, we have a component called Night Color which is kind of responsible for color correction, however it's more oriented for adjusti...One of the things that had been discussed during a kwin sprint in July 2019 was color management. Currently, we have a component called Night Color which is kind of responsible for color correction, however it's more oriented for adjusting screen color temperature.
Color temperature is one of the things that user should be able to tweak, but there is a lot more... From design perspective, we need a generic color management system in kwin. It should be capable of adjusting screen brightness, gamma correction, and so on. Things may get tricky if we want to apply both a custom screen color temperature and an ICC profile to calibrate white point, but luckily for us lcms2 has everything we could have dreamed of. lcms2 makes it very easy to interpret the VCGT tag, and combine tone curves.
So far, most developers that are involved in color management discussions agree that the compositor has to perform necessary color space conversions. Ideally, applications should tag their surfaces with color space metadata and from that point on, the compositor ensures that the surfaces will be displayed properly on the screen. [2] introduces a new wayland protocol that can be used to set the color space metadata.
## Open Questions
### Maybe add some colord integration?
Done. See !436
### Is color management an integral part of the compositor? If it's not, put it in a plugin.
Yes, it is.
### What is the role of Night Color?
Night Color is responsible for only adjusting the screen color temperature.
## Relevant upstream links
- [1] http://www.argyllcms.com/WaylandCM_v1.txt
- [2] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
- [3] https://lists.freedesktop.org/archives/wayland-devel/2017-January/032769.htmlhttps://invent.kde.org/plasma/plasma-desktop/-/issues/94Plasma 6 proposal: natural scrolling by default (for touchpads only)2023-07-26T16:09:33ZRobert StonePlasma 6 proposal: natural scrolling by default (for touchpads only)About as controversial as double-click... ;)
GNOME, Windows and macOS all use reverse / "natural" scrolling by default for touchpads (macOS goes a step further and does it for mice too; GNOME and Windows do it only for touchpads). I got...About as controversial as double-click... ;)
GNOME, Windows and macOS all use reverse / "natural" scrolling by default for touchpads (macOS goes a step further and does it for mice too; GNOME and Windows do it only for touchpads). I got used to it a long time ago and find "normal" scrolling on touchpads a bit strange now, I think a lot of users switching from other platforms feel the same.
A major downside right now is that natural scrolling has a few quirks / annoyances, most notably that it doesn't work for horizontal UI elements, like tabs. They go the opposite of how you move your fingers, breaking the whole direct manipulation / scroll the content not the view / "natural" element. This happens in both GTK and Qt apps and should probably be fixed.6https://invent.kde.org/plasma/plasma-workspace/-/issues/59Day and Night color scheme switching2024-02-27T02:43:03ZNatalie Clariusnatalie_clarius@yahoo.deDay and Night color scheme switchingDecopuled form https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2567 to discuss what we want for the design before we discuss the code.
The feature discussed is a new option to automatically switch between a preferred lig...Decopuled form https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2567 to discuss what we want for the design before we discuss the code.
The feature discussed is a new option to automatically switch between a preferred light and dark color scheme based on time of day, and possibly unifying this with the existing "night color" (screen temperature) functionality.
@teams/vdg
FEATURE: 408563https://invent.kde.org/plasma/kwin/-/issues/59Touchpad & touchscreen gestures2023-04-17T14:59:49ZXaver HuglTouchpad & touchscreen gesturesI think we could use a plan on where we want to go with touchpad and touchscreen gestures.
# The status quo
We have non-configurable touchpad 4 fingers up for the desktop effect, 4 fingers down for present windows, 4 finger left/right f...I think we could use a plan on where we want to go with touchpad and touchscreen gestures.
# The status quo
We have non-configurable touchpad 4 fingers up for the desktop effect, 4 fingers down for present windows, 4 finger left/right for switching between virtual desktops. Except for the desktop effect none are real-time. There is also the screen edge touchscreen gestures and are configurable, also not real time though and sort of unreliable at the moment (at least on my laptop).
# 3 finger gestures
I implemented some for window management (maximize, quick tile left/right, minimize) in [work/more-touchpad-gestures](https://invent.kde.org/plasma/kwin/-/commits/work/more-touchpad-gestures) and they do remove the need for some annoying mouse movements with my workflow. I think something like that could be useful and well received, especially if paired with some nice (ideally real-time) animations instead of the current blinking of the quick tile shortcuts.
# Contextual awareness
I think that for the best and most intuitive experience touch(pad)gestures need to be contextual: Swipe up triggers desktop overview, so swipe down should disable it again. Same principle for present windows, quick tile and probably maximize, too. 4 finger left/right to switch between VDs should ideally work in the new overview effect. Also in the overview effect, cycling through the selected windows by scrolling / swiping with two fingers in the direction of the to-be-selected window would likely make sense.
# In applications
With Qt6 we'll be able to use touchpad gestures in applications, we need to figure out how to prevent clashes - keeping apps to 3 finger and KWin to 4 is not enough, as other DEs can and do use different global shortcuts, and obviously there's also third party apps. This goes out of the scope of KWin but there's also questions on where to use them for what, and how make them commonly configurable, too. Things like "back/forward" should probably be universal.
# Global touchscreen gestures
For things like screenshots, triggering present windows, quick tiling etc. What should be 3, what should be 4 fingers? Should 3 fingers maybe be reserved for moving windows like you can with Meta+LeftClick on laptops instead of normal gestures?
# Configurability
How far should it go? Do we want to have (at least a subset of) normal shortcuts that can generally be set to be triggered by touch(pad) gestures, or should it stay separate, like screen edges?
cc @teams/usabilityhttps://invent.kde.org/plasma/plasma-desktop/-/issues/113Make important desktop functionality not depend on the presence of applets2024-03-23T19:38:55ZBharadwaj RajuMake important desktop functionality not depend on the presence of appletsA lot of what we consider baseline features in a modern desktop — volume keys, media keys, clipboard management, notifications — are handled by the applets in Plasma.
This implementation detail creates a very common pathway for users to...A lot of what we consider baseline features in a modern desktop — volume keys, media keys, clipboard management, notifications — are handled by the applets in Plasma.
This implementation detail creates a very common pathway for users to break their systems by removing applets because they don't use the applets themselves, not knowing that those applets are the sole providers of related functionality in Plasma.
Proposal: we move appropriate parts of the applets into KDED services.
Applets which need this treatment:
- [x] Media Player applet provides media keys ([bug 409190](https://bugs.kde.org/show_bug.cgi?id=409190), [bug 460771](https://bugs.kde.org/show_bug.cgi?id=460771))
- [x] Audio Volume applet provides volume keys ([bug 391578](https://bugs.kde.org/show_bug.cgi?id=391578), plasma-pa!221)
- [ ] Clipboard applet provides clipboard management ([bug 443036](https://bugs.kde.org/show_bug.cgi?id=443036))
- [ ] Notifications applet provides notifications (this might be difficult)
Former metabug about this on Bugzilla: https://bugs.kde.org/show_bug.cgi?id=4430366.1https://invent.kde.org/plasma/breeze/-/issues/18Redesign the tab style2023-11-21T20:08:13ZCarl Schwancarl@carlschwan.euRedesign the tab styleThere are a few mockups published in the vdg chat, posting them here to not loose them
## Mutable tabs
![image](/uploads/e727b981889b6a8bc2a811cfe7e69b8a/image.png)
![image](/uploads/152b0214c1608dd576178b3101c79b77/image.png)
## Unm...There are a few mockups published in the vdg chat, posting them here to not loose them
## Mutable tabs
![image](/uploads/e727b981889b6a8bc2a811cfe7e69b8a/image.png)
![image](/uploads/152b0214c1608dd576178b3101c79b77/image.png)
## Unmutable tabs
![demo-app-configure_1_](/uploads/6943867f79d59927b3cf49e231acc714/demo-app-configure_1_.png)
![demo-app-configure_2_](/uploads/4dc48a08086ac3ab74c6265c3a48cb8e/demo-app-configure_2_.png)
@teams/vdghttps://invent.kde.org/plasma/plasma-desktop/-/issues/78[Approved] Plasma 6 proposal: Make window titlebars accent colored by default2023-11-28T15:08:07ZNatalie Clariusnatalie_clarius@yahoo.de[Approved] Plasma 6 proposal: Make window titlebars accent colored by defaultIf someone wants to go ahead and implement this, feel free to; I likely won't get around to it anytime soon.
---
Linking up on https://invent.kde.org/plasma/plasma-desktop/-/issues/74, I would like to propose to turn on the "Make windo...If someone wants to go ahead and implement this, feel free to; I likely won't get around to it anytime soon.
---
Linking up on https://invent.kde.org/plasma/plasma-desktop/-/issues/74, I would like to propose to turn on the "Make window titlebars accent colored" option for our Breeze themes by default. This is not only eye candy, but also helps accessibility. Compare how much more difficult it is to tell which window has focus with our current gray as opposed to the active window being highlighted in the accent color:
Initial proposal:
| before | after |
| ------ | ------ |
|![window-color_1](/uploads/17cdbe49ce4f787e6a253febd5ff6bed/window-color_1.png) | ![window-color_2](/uploads/184dfe1833c2e97bd12ff405db7d148d/window-color_2.png) |
Current proposal (to be discussed):
| before | after |
| ------ | ------ |
| (same as above) | ![window-colors_3](/uploads/8b247c1b3edc1bf8adc1f649fc343fe8/window-colors_3.png) |6https://invent.kde.org/plasma/plasma-workspace/-/issues/47[Approved] Plasma 6 Proposal: Sound theme support2023-10-17T15:46:49ZArtem Grinev[Approved] Plasma 6 Proposal: Sound theme supportWith the discussion of the new Blue Ocean theme there came an idea to create a new KCM for sounds theme. The most obvious idea is to use [XDG Sound Theme spec](https://specifications.freedesktop.org/sound-theme-spec/sound-theme-spec-late...With the discussion of the new Blue Ocean theme there came an idea to create a new KCM for sounds theme. The most obvious idea is to use [XDG Sound Theme spec](https://specifications.freedesktop.org/sound-theme-spec/sound-theme-spec-latest.html) which currently KDE software lacks.
As far as I understand all KF5 apps rely on KNotifications for event producing and configuration. The sound file is defined in the corresponding notifyrc file and being played by KNotifications via libcanberra or phonon by a file URL.
XDG specification defines names of sounds and an algorithm of getting a particular file name using the sound's name and a selected theme name.
My idea is to extend notifyrc files with the support of system sound name field and a new `SystemSound` event action which will lookup and play the sound by it's name. The event configuration window will allow users to select if they want to use a sound file or a sound name. `kdeglobals` will get a new field for the sound theme
This mechanism will allow us to use GNOME sounds themes (such as Ubuntu's Yaru), sync sounds with GTK and create a KCM for the sound sets management. This also won't change anything for apps, only the sound name could be added declaratively to the existing event configuration.
I really hope I got the whole existing architecture right and my proposal makes any sense. I'd be glad to hear any ideas, corrections and improvements.
@teams/vdg
---
Edit (by @iasensio): If you allow me, I'd like to use this issue to track the on-going progress and the required tasks to achieve the proposal.
### Sound Theme Support
* [x] Support the sound spec in KNotifications ( https://invent.kde.org/frameworks/knotifications/-/merge_requests/105)
* [x] Make the Oxygen theme compatible with the sound name spec ( https://invent.kde.org/plasma/oxygen-sounds/-/merge_requests/6)
* [x] Port the plasma sound references to compliant sound names (https://invent.kde.org/raploz/blue-ocean-sound-theme/-/issues/6)
* [ ] Port the applications' sound reference to compliant sound names (only on kf6 branches) (https://invent.kde.org/raploz/blue-ocean-sound-theme/-/issues/6)
* [x] Add a new Sound Theme KCM ( https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3096)
### Ocean Sound Theme
(General sub-task: https://invent.kde.org/plasma/plasma-workspace/-/issues/40)
* [x] kdereview (https://invent.kde.org/raploz/blue-ocean-sound-theme/-/issues/7)
* [x] Move the repository to the general Plasma groups
* [x] Change the default theme from oxygen to ocean ( https://invent.kde.org/frameworks/knotifications/-/merge_requests/127 and !3197 )
* [x] Include repo into the plasma release (@jriddell)
* [x] Add to the recommended packages for Plasma (https://community.kde.org/Distributions/Packaging_Recommendations) \[oygen-sounds still needed for compatibility with KF5 apps\]
* [x] Notify distributions (distributions@kde.org)
### Get New Stuff
* [ ] Add the System Sounds category (316) to the [OCS API for KNewstuff](https://api.kde-look.org/ocs/v1/content/categories)
* [ ] Show the ["System Sounds" page in the store](https://store.kde.org/browse?cat=316&ord=rating) which it is currently hidden (resources are shared with the Gnome store as they are valid for both desktops),
* [ ] Add KNewStuff support to the KCM
### Further Integration
* [ ] Add Sound Theme to Global Themes
* [x] Synchronize the [gtk setting](https://docs.gtk.org/gtk3/property.Settings.gtk-sound-theme-name.html) in kde-gtk-config ( https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/87)
* [ ] Mention Plasma at https://freedesktop.org/wiki/Specifications/sound-theme-spec/
* [x] Add a new component (kcm_soundtheme) to systems settings in bugzilla6Artem GrinevArtem Grinevhttps://invent.kde.org/plasma/plasma-workspace/-/issues/11Consider permitting the user to choose whether they want changed defaults to ...2023-11-28T14:35:07ZNate GrahamConsider permitting the user to choose whether they want changed defaults to take effect on upgradeAs we get more popular and reach more users, we increasingly run into the following problem:
1. Some of our users appreciate change and novelty and want the UX they experience to be modernized over time
2. Some of our users are happy wi...As we get more popular and reach more users, we increasingly run into the following problem:
1. Some of our users appreciate change and novelty and want the UX they experience to be modernized over time
2. Some of our users are happy with the way things look and behave right now and are annoyed when anything changes
These sentiments are mutually exclusive. It's not feasible for conservative and change-averse users to simply avoid updating because then they miss out on security fixes and the inevitable changes are simply delayed, because they have to upgrade eventually.
---
Relatedly, we have a problem whenever we change the default settings for anything: depending on the implementation, existing users may or may not see any changes at all.
Cases where the change takes effect for existing users include default settings that use kconfig which have not been overridden by user action; rewritten widgets; or changes to the widget style. Cases where changes do not take effect for existing users without a kconf update script include changes to existing color schemes or which one is the default; changes to the default Places panel items; changes to the toolbar arrangement in QWidgets-based apps (sometimes; seems buggy); or changes to the default Plasma Panel layout.
All in all it is a bit messy and random, and does not seem to satisfy everyone.
---
If we want to keep everyone happy, I think we need to unify whether or not changed settings take effect on upgrade, and then consider giving the user a choice for whether or not to apply changes upon upgrade. Not new features, mind you. Just instances where an existing feature has its default behavior or appearance changed, or is replaced with a new one.
This would allow conservative, change-averse, or technically novice users to use the "don't change my settings" option and never have their app behaviors, color schemes, or widgets changed unless they specifically go and do it. And users who appreciate change and want to see the UI modernized would be able to always have those changes applied--not just some of them.
cc @teams/vdghttps://invent.kde.org/plasma/latte-dock/-/issues/134Plasma 6 port2024-03-19T00:40:56ZLana BlackPlasma 6 portMake it happen!Make it happen!Lana BlackLana Blackhttps://invent.kde.org/plasma/powerdevil/-/issues/19Per-monitor screen brightness2024-03-06T22:27:31ZNicolas FellaPer-monitor screen brightnessCurrently powerdevil and the battery/brightness applet only knows one screen brightness.
This of course falls on the nose when we have more than one monitor with working brightness control.
UI-wise we probably want a slider per control...Currently powerdevil and the battery/brightness applet only knows one screen brightness.
This of course falls on the nose when we have more than one monitor with working brightness control.
UI-wise we probably want a slider per controllable monitor in the applet, with some indication which monitor is being controlled. What should happen when pressing the brightness keys on the keyboard is a bit unclear.
Implementation-wise the complexity is that there's two ways to control the brightness: Via sysfs (BacklightHelper in powerdevil) and via ddcutil. sysfs is mostly relevant for laptop displays whereas ddcutil is mostly relevant for external monitors. Are there screens that support both?
What we need to do is:
1) In powerdevil: Detect all controllable screens by aggregating sysfs and ddcutil results. We also need some sort of identifier (connector name? EDID?) and user-visible label
2) Expose that to the applet (via DBus?)
3) In the applet: Show a slider for each thing
4) When the slider changes write back to Powerdevil
5) In powerdevil: Write the change to the display via the right mechanism6.1