Patched KDE Dolphin with Pixel Scaling https://fiftyfourth.xyz/git/dolphin/atom?h=master 2026-01-21T09:01:28Z 2026-01-21T09:01:28Z Tomasz Kot tomasz.kot13@gmail.com 2025-11-28T15:11:00Z urn:sha1:843d10ae2ab6a7f2c6f69b63fa278fdd6162254c The mouse events need to modify the keyboard anchor assignments as well, because selecting an item with a mouse and then navigating with keyboard wouldn't follow the same selection. BUG: 508609 2025-11-12T14:54:30Z Nate Graham nate@kde.org 2025-11-11T17:47:26Z urn:sha1:7419cd326902c64b69802ab3f01656076d3c7a97 This reverts commit 122fee5625f0285ec4ebda79162c72390989eb2a. This behavior change was well-intentioned, but has significant usability and speed drawbacks that have not been addressed: - Keyboard-driven folder manipulation became slower - Unexpected behavioral differences when opening files with the pointer compared to when opening them with the keyboard introduced inconsistency and cognitive load - Unexpected opening of selection mode during fast operation introduced the potential for confusion and additional errors - Dolphin's behavior became inconsistent with that of other file managers users may be accustomed to The bug tracker, discuss.kde.org, and Reddit are full of complaints about this change. It's been a year now; I think it's clear that many Dolphin users have not gotten used to and accepted it. I have to count myself as one of them, I'm afraid. I've tried to get used to it for a year, but I just have not been able to. I don't believe the benefits of this change outweigh the drawbacks, so let's revert it. 24d859cf19e90fa22ed687b36a68231625c1bd80 was explicitly mentioned as a thing that should also be reverted in this case, but it's already been done. BUG: 494125 BUG: 511966 CCBUG: 424723 CCBUG: 492404 FIXED-IN: 25.12.0 2025-04-29T10:33:44Z Méven Car meven@kde.org 2025-04-29T10:33:44Z urn:sha1:0464ea82a6850f58805bc4d6fc1df5369d83c3df 2025-02-22T22:26:57Z Yifan Zhu fanzhuyifan@gmail.com 2025-02-20T18:35:06Z urn:sha1:b4dedc0d0df2c8b191192476d7787630180e51c7 Search from the next position for new search and special repeated key search. Otherwise search from the current position, which is current selected item if something is selected or in selection mode, and 0 (the beginning) otherwise. Test plan: - create directory with files ab1, ab2, and ab3 - click ab2, and press escape to deselect - type ab; verify that ab1 is selected - wait a while, type ab again, verify that ab2 is selected - wait a while, type ab again, verify that ab3 is selected - click ab1, type ab, verify that ab2 is selected BUG: 422951 2025-02-20T17:37:40Z Méven Car meven@kde.org 2025-02-20T17:37:31Z urn:sha1:387dafe8e191f65399c37acf35379da0e2f0f5d5 NO_CHANGELOG 2024-12-29T11:27:18Z Felix Ernst felixernst@kde.org 2024-12-29T11:27:18Z urn:sha1:3696213ccbbe27e9ef3fc85eb97dd32fd669066f Prior to this commit keyboard controls and behaviour of Dolphin's main view were identical no matter if selection mode was enabled or not. While selection mode makes it impossible to accidentally clear the selection by singular mouse clicks, any press of an arrow key on the keyboard would still clear the full selection which goes against selection mode's objective. Furthermore, keyboard-only users had no reason to ever enable selection mode because it made no difference to them. This commit changes this by offering a changed control scheme for key presses while in selection mode. Arrow key presses without modifier now only move focus between items but do no longer clear or change the selection. Similarly, Page Up/Down, Home, and End key presses only move keyboard focus. Enter, Return, and Space key presses now only toggle the selection for the current item. The above controls are however mostly unchanged when combining them with Modifier keys like Shift or Control. The type-ahead feature is also changed in selection mode to only move keyboard focus without changing the selection. This way keyboard users are less likely to clear their selection by mistake. Regression tests are added for these selection mode controls. The code changes to change this keyboard behaviour are quite minimal. Most of the added code is for making selection mode accessible. That's because we need to make sure the changed control scheme is properly announced and communicated or a blind user will be left utterly confused why the normal keyboard controls "stopped working". Enabling or disabling selection mode is announced to accessibility software. Furthermore whenever focus goes to the main view, the selection mode state is also mentioned when active. BUG: 458091 2024-10-31T10:04:40Z Zhangzhi Hu integral@member.fsf.org 2024-10-29T16:18:57Z urn:sha1:25f7aba43d0f4ca38167dd686ae0efd8c89cc5d4 2024-07-31T12:04:38Z Méven Car meven@kde.org 2024-07-31T09:00:32Z urn:sha1:131c889b0c050592809035242db6200482e0edde Add test for double-click activation. BUG: 485295 2024-05-18T22:18:14Z Felix Ernst felixernst@kde.org 2024-05-18T22:18:14Z urn:sha1:122fee5625f0285ec4ebda79162c72390989eb2a Items should only be selected if the user wants to act on them. However, previous to this commit we sometimes selected items even when there is no reason to assume that the user would like to act on them. Such selections are dangerous because they make it more likely that the user manipulates items by accident which they never even explicitly selected. Example: The "Up" action is used to navigate to the parent folder. This will implicitly select the folder one emerged from after opening the parent folder, so just one accidental press of the Delete key will lead to data loss if the press goes unnoticed. This scenario would have been avoided if no folder had been selected automatically. The above example becomes even more dangerous if the user is acting with elevated privileges. The following implicit selections of items are being removed: - Selecting items that are being activated - Selecting folders one emerges from Even though these items will no longer be selected after these actions, they will still be marked as current. The only downside I see is that our indication of which item is "current" is a lot weaker than the selection highlight, so it might be more difficult to spot which folder one has emerged from. However, this could be counter-acted with some other temporary indication if this really turns out to be a problem. The only downside I see is that our indication of which item is "current" is a lot weaker than the selection highlight, so it might be more difficult to spot which folder one has emerged from. However, this could be counter-acted with some other temporary indication if this really turns out to be a problem. BUG: 424723 2024-03-27T10:28:15Z Eugene Popov popov895@ukr.net 2024-03-27T10:28:15Z urn:sha1:240d33ce17fc531e8bc6638af8f71454fe7c05e6 This MR fixes some issues related to RTL scripts: - wrong layout in Compact View mode - broken horizontal scrolling in Icon View and Details View modes - broken navigation with left and right arrow keys in Details View mode BUG: 484012 BUG: 449493