Debian Patches
Status for plasma-desktop/4:6.3.6-1
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| upstream_c2d83388_lockscreen-sync-password-across-different-screens.patch | [PATCH] lockscreen: sync password across different screens Test plan: - lock screen in multiscreen setup - type on one password box, verify password is synced to other screen - make deletions and insertions in other screen, and verify changes are synced back |
Yifan Zhu <fanzhuyifan@gmail.com> | no | 2025-01-10 | ||
| relax-interplasma-versioned-deps.patch | no | |||||
| add-sddm-debian-theme | no | |||||
| upstream_7327baf0_kcms-keyboard-Allow-to-edit-the-layout-display-name.patch | [PATCH] kcms/keyboard: Allow to edit the layout display name The display name of the layouts can be customized, but in the UI it was only possible to set it when adding a new one. Expose the setting also in the layout list, in a non-intrussive way by giving the appearance of a label, which can be edited when given focus either by click or keyboard. |
Ismael Asensio <isma.af@gmail.com> | no | upstream | 2025-02-21 | |
| upstream_26233825_kcms-runners-Add-power-session-actions-to-favorite-runners-list.patch | [PATCH] kcms/runners: Add power/session actions to favorite runners list Right now we have a problem that when people search for "shut down" and "reboot" and the like, the Desktop Sessions KCM appears first. This is currently expected because the System Settings runner is a default favorite runner, and the power/session runners are not. Logical, but not ideal. There are three ways we can fix this: 1. Add the runners for power and session actions to the default favorite runners list. 2. Remove a bunch of keywords from the desktop sessions KCM so it doesn't match those kinds of searches anymore. 3. Remove all default favorite runners and hope the internal weightings are good enough to solve the problem. This commit implements option 1, which is the least invasive change given the current implementations. |
Nate Graham <nate@kde.org> | no | upstream | 2025-03-06 | |
| upstream_305d88e0_lockscreen-only-show-UI-on-screen-with-mouse.patch | [PATCH] lockscreen: only show UI on screen with mouse Otherwise one appears on every screen, which is awkward. However, forcing it to be on a particular screen is undesirable, since if that screen is turned off but not unplugged, it may still be sending a signal to the OS and show up as a valid screen to show things on. To alleviate that concern, always show the UI on the screen with pointer. Test plan: - use multiscreen setup and lock screen - move mouse across screens, verify that only screen with pointer shows controls - type some password without pressing enter, and repeat previous point |
Yifan Zhu <fanzhuyifan@gmail.com> | no | upstream | 2025-02-05 | |
| upstream_f6c6e03a_containments-desktop-fix-folder-view-clicking.patch | [PATCH] containments/desktop: fix folder view clicking 53d67b9a0b82fff40b2057f1ceb74b529b943df5 made clicking use the same logic to determine the selected item for mouse and touch, rather than relying on hover events. It seems the logic for touch was broken in some cirumstances, namely scrolled views and certain alignments, where the coordinate systems do not align. A similar issue was already fixed elsewhere in folder view with 509b655ef2edef04a13d9afaab6349911beaaeb1, so we reuse the approach here. |
Christoph Wolk <cwo.kde@posteo.net> | no | upstream | 2025-06-20 | |
| upstream_71081728_Make-sure-the-handles-never-go-out-of-view.patch | [PATCH] Make sure the handles never go out of view when the panel custom size ruler gets resized due to other panels reserving space, the handles might end up in a position which goes out of the view of just few pixels, but makes the handles completely non iteractible. when the maximum possible size of the panel is less because another panel is taking some reserved space, the handles should reflect that and never go out of bounds BUG:494452 (cherry picked from commit c27dd27bffec16a214db35a5e192ca98a558dd5f) c27dd27b Make sure the handles never go out of view |
Marco Martin <notmart@gmail.com> | no | 2025-05-23 | ||
| upstream_f8532d35_applets-kickoff-recalculate-app-model-binding-on-rootModel-refresh.patch | [PATCH] applets/kickoff: recalculate app model binding on rootModel refresh Kickoff stores (a pointer to) the most recently accessed app category (including the all-apps category, but not favorites) through a binding chain fetching the rootModel's modelForRow() on the current index of the sidebar. That's a method call that does not by itself create a qml dependency on the main model state, so if the user installs or removes software, the underlying model is replaced completely (and the existing one is deleted), but the binding is not updated to point to the new (sub)model. Accessing the same category again will then fail (as it reads the old model, now null), until the user selects a different category first, changing the index and causing the binding to be reevaluated. Instead, reevaluate the binding whenever the rootModel is refreshed. |
Christoph Wolk <cwo.kde@posteo.net> | no | upstream | 2025-05-28 | |
| upstream_64f3fe1b_Only-start-drag-and-drop-from-Widget-Explorer-when-dragging-horizonally.patch | [PATCH] Only start drag and drop from Widget Explorer when dragging horizonally This way, you can still drag vertically through the list of applets, and then horizontally to start a drag and drop. BUG:474929 |
=?UTF-8?q?Niccol=C3=B2=20Venerandi?= <niccolo@venerandi.com> | no | 2025-02-10 | ||
| upstream_a5573c43_applets-kicker-reset-custom-icon-when-cleared.patch | [PATCH] applets/kicker: reset custom icon when cleared Kicker's configuration page has a somewhat complex handling of the custom icon, which is spread across three properties. When the custom icon is cleared, the property that governs which of the other properties is used is set. but the actual icon is not cleared. This means that setting and resetting the icon will still prompt the user to save the changes to the (now unused) property. This would be meaningful if the custom icon could be reactivated, but the only way to enable it again is to set it again, at which point the stored value would be overwritten anyway. Instead, remove the value of the custom property as well if the icon is cleared. |
Christoph Wolk <cwo.kde@posteo.net> | no | 2025-04-06 | ||
| upstream_cdca22a5_applets-kicker-handle-icon-dialog-being-accepted.patch | [PATCH] applets/kicker: handle icon dialog being accepted Kicker's custom icon button handles the icon dialog's iconName property being changed, and stores the result in its own configuration. This will fail sometimes: if the user sets a custom icon, clears it using the icon button's "Clear Icon" function, and sets the same custom icon again, the icon will not be changed as the icon dialog's property is unchanged by selecting the same icon again. Instead, we listen to the icon dialog's accepted signal, and only set the custom icon if an icon was actually chosen. |
Christoph Wolk <cwo.kde@posteo.net> | no | 2025-04-06 | ||
| upstream_d12eaa3a_sddm-theme-clear-password-when-selecting-a-different-user.patch | [PATCH] sddm-theme: clear password when selecting a different user Users don't have the same passwords, so it doesn't serve any purpose to keep anything in the password field when the selected user changes. |
Nate Graham <nate@kde.org> | no | upstream | 2025-04-11 | |
| upstream_9a223547_AbstractKickoffItemDelegate-block-action-trigger-while-dragging.patch | [PATCH] AbstractKickoffItemDelegate: block action trigger while dragging | Noah Davis <noahadvs@gmail.com> | no | upstream | 2025-04-14 | |
| upstream_2592f1fe_lockscreen-remove-dead-code.patch | [PATCH] lockscreen: remove dead code The function tryToSwitchUser was removed in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3577 but still called, casing error output on terminal CCBUG:486352 (cherry picked from commit 24857e68a01cf92929c48279b9c42251e136a682) 24857e68 lockscreen: remove dead code |
Marco Martin <notmart@gmail.com> | no | 2025-05-20 | ||
| upstream_a2ed9f88_applets-trash-Use-KIO-CommandLauncherJob-to-open-trash.patch | [PATCH] applets/trash: Use KIO CommandLauncherJob to open trash QDesktopServices::openUrl (through Qt.openUrlExternally) requests a token from the focus window. When trash is clicked in a panel, the panel doesn't have focus, resulting in no token being created. KProcessRunner used by KIO CommandLauncherJob as a fallback takes whatever first window in qApp making activation work. While at it, also use KNotificationJobUiDelegate for proper error reporting in case opening trash fails. |
Kai Uwe Broulik <kde@privat.broulik.de> | no | upstream | 2025-04-22 | |
| upstream_a4581040_kcms-access-change-icon-for-Screen-Reader-entry.patch | [PATCH] kcms/access: change icon for Screen Reader entry The current icon is a microphone, which isn't really a good fit for this page as no one is actually talking into a microphone. We have a semantically perfect icon: text-speech. Let's use this. |
Christoph Wolk <cwo.kde@posteo.net> | no | 2025-05-09 | ||
| upstream_635ea80c_Folder-View-Don-t-show-wrong-context-menu-when-left-and-right-clicking.patch | [PATCH] Folder View: Don't show wrong context menu when left-and-right-clicking On devices with physical left and right buttons, it's possible to right-click while holding down the left button. When doing this on the desktop, you get the wrong context menu, because Folder View code was inappropriately handling the event rather than falling back to the desktop context menu plugin. To fix this, explicitly handle that case and don't accept the event, allowing it to fall back properly. |
Nate Graham <nate@kde.org> | no | upstream | 2025-04-13 | |
| upstream_a6a8a35a_containments-desktop-fix-reopening-Location-config-page.patch | [PATCH] containments/desktop: fix reopening Location config page When the radio button for the Places option is selected, the combobox is enabled and the path selected there is marked as the new path for the widget. This is generally reasonable, but breaks when opening the configuration page with anything except the first entry selected - the combobox is enabled before the correct value is set, which causes it to overwrite the correct value with the default combobox value, losing the user's configuration. Instead we just set the value before enabling the combobox and everything works out fine. |
Christoph Wolk <cwo.kde@posteo.net> | no | upstream | 2025-05-10 | |
| upstream_6f417e4b_PanelConfiguration-Fix-missing-RTL.patch | [PATCH] PanelConfiguration: Fix missing RTL Because this is used as the root item in QML, we need to set LayoutMirroring ourselves. | Oliver Beard <olib141@outlook.com> | no | upstream | 2025-05-09 | |
| upstream_53bd4d6b_containments-desktop-redetermine-item-on-click.patch | [PATCH] containments/desktop: redetermine item on click In case of touch events, Folder View already resets the hovered item to the actual click position, as touch does not cause hover events. There is another case where a click on a non-hovered element can happen, namely if the containsMouse determination is blocked by an open context menu. If the user does not move the pointer after opening a context menu, moving the pointer to another item, and closing the context menu, left-clicking will leave the icon completely unaffected and right- clicking will re-open the previous context menu, rather than open the one for the clicked entry. Instead, always take the delegate that was clicked to activate or open the context menu, whether on touch or not. This matches the behavior in Dolphin, where in the same situation the hover feedback is not updated, but clicking still works normally. (cherry picked from commit 53d67b9a0b82fff40b2057f1ceb74b529b943df5) |
Christoph Wolk <cwo.kde@posteo.net> | no | upstream | 2025-05-26 | |
| upstream_fc4981c4_lockscreen-prevent-immediate-prompting-for-the-password.patch | [PATCH] lockscreen: prevent immediate prompting for the password As of Qt 6.8.2, the fix for QTBUG-127122 causes a positionChanged event to be emitted when handling QEvent::HoverEnter. The lockscreen creates a full screen MouseArea on every connected screen, one of which will cover the current position of the mouse pointer. This causes QEvent::HoverEnter and then the positionChanged event to be raised immediately. The mouse position did not change. Ignore the spurious (first) positionChanged event, show the password UI as usual in response to further events. (cherry picked from commit c0d12c52198a660629dcd194f85ad750196fdd68) |
Nate Graham <nate@kde.org> | no | upstream | 2025-07-11 |
All known versions for source package 'plasma-desktop'
- 4:6.3.6-1 (forky, sid, trixie)
- 4:5.27.5-2 (bookworm)