Patched KDE Dolphin with Pixel Scaling https://fiftyfourth.xyz/git/dolphin/atom?h=pixelated-scaling-option 2026-03-06T09:55:03Z 2026-03-06T09:55:03Z Akseli Lahtinen akselmo@akselmo.dev 2026-03-05T09:46:28Z urn:sha1:fcbc7479769462505d39de5de498f76e75f3c78d Like with leftclick, we should check this for rightclick. If user has highlightEntireRow enabled and right clicks an item, the item should be activated. BUG: 508356 2026-02-05T08:49:41Z Akseli Lahtinen akselmo@akselmo.dev 2026-02-04T14:10:58Z urn:sha1:17e55c976581aa58b4500e426fb2925a3d45c308 Currently when dragging and dropping items in Details view, even if the "Open files and folders" setting is set "By clicking anywhere on the row", drag and drop still behaves differently. Instead, make the drag and drop follow the setting: If clicking anywhere on the row causes actions, so should dropping anywhere on the row. BUG: 515439 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-11-10T08:38:31Z weinan li liweinan@kylinos.cn 2025-11-10T08:38:31Z urn:sha1:3858afbfa4f2f60cc33f39a471d36a1e1a3514c7 The original keyboard search implementation had a limitation when dealing with files containing repeated characters like 44.txt. When typing 44, it would trigger rapid navigation to the next item starting with 4 instead of matching the full string 44. This patch introduces a smarter search strategy: 1. First attempt full string matching for exact file names 2. If full match fails and user is typing repeating characters, fall back to rapid navigation using either: - Last successful search string (for extended searches like 444 -> 4444) - First character only (original rapid navigation behavior) The changes include: - Modified changeCurrentItem signal to include a found parameter for search result feedback - Added m_lastSuccessfulSearch to track successful searches for better fallback behavior - Used Qt::DirectConnection to ensure synchronous execution for immediate result feedback This provides better user experience when searching for files with repeated characters while maintaining the rapid navigation feature for quick browsing. BUG: 501851 2025-06-19T21:15:31Z Akseli Lahtinen akselmo@akselmo.dev 2025-06-19T21:15:31Z urn:sha1:c1e71289082ec7416ac19c822393ea70f63d1b75 This adds a new selection effect that is similar to what we have in QtQuick file item views. There are also changes to some usability: Instead of only the icon and text being the clickable area in icon and details mode, the whole selection is now the clickable area. Otherwise the usability should stay the same, it's mostly a visual change. See also: https://invent.kde.org/teams/vdg/issues/-/issues/94 2025-05-09T10:34:30Z Akseli Lahtinen akselmo@akselmo.dev 2025-05-09T10:34:30Z urn:sha1:2201018673467bf7a871082b1fd1e3f8c6f926e7 In future Qt versions, Qt Timers do not allow negative intervals. Instead, they will be changed to 1. Related Qt commit: https://github.com/qt/qtbase/commit/f1f610bc67bfd5c2ef31270a6945e7bae93b5e4a Instead of relying on the interval, use a boolean variable to check if the autoactivation is enabled or not. 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 2024-12-29T11:42:22Z Felix Ernst felixernst@kde.org 2024-12-29T11:42:22Z urn:sha1:95542a389112491abf3a31c338e7d78f7785f48e This commit implements mirroring of the details view mode for right-to- left languages. This is the last of the Dolphin view modes which did not adapt to right-to-left languages correctly. Implementation-wise this is mostly about adapting the math so all the information is placed correctly no matter the view mode or layout direction. While most of the view actually changes the painting code for right-to-left languages, for the column header I decided to keep the logic left-to-right and instead reverse the order of the role columns. To implement this mirroring I needed to rework quite a bit of logic, so I used the opportunity to fix some bugs/behaviur quirks: - Left and right padding is now saved and restored separately instead of only saving the left padding - Changing the right padding no longer disables "automatic column resizing". - The grip handles for column resizing can now be grabbed when near the grip handle instead of only allowing grabbing when slightly to the left of the grip. - Role column headers now only show a hover highlight effect when the mouse cursor is actually above that role and not above the grip handle or the padding. - There is now a soft-boarder when shrinking the right padding so shrinking the padding "below zero width" will no longer immediately clear automatic resize behaviour. So now it is possible to simply remove the right padding by resizing it to zero width. BUG: 449211 BUG: 495942 # Acknowledgement This work is part of a my project funded through the NGI0 Entrust Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology. 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