| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2024-12-29 | Have special keyboard controls in selection mode | Felix Ernst | |
| 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-03-13 | Animate most of the bars | Felix Ernst | |
| When a bar is toggled visible this usually happens because the user might want to use its functionality now. However, if bars appear without animation or at a location the user is not currently looking at, they might not notice that they have appeared at all. An animation makes it more likely that the user notices the change and can then use the newly made visible component. Another reason for animations for showing or hiding of components is that it can be disorienting for users when panels or bars suddenly appear or disappear without animation. There is no visible movement then, so the user might not know what happened if they didn't concentrate or blink at that moment. The newly appearing or disappearing component might also displace other components which can make it difficult to find what one was just looking at. These bars animate now after this change: - Search panel - Filter bar - Status bar This is implemented by extracting the animation code from SelectionMode::TopBar into a new abstract base class AnimatedHeightWidget. This class is now also used in SelectionMode::BottomBar and the animating code there was removed. These bars are left in Dolphin that stay without animation: - Menu bar (Would probably need to be implemented in KXmlGui) - Tool bar (Would probably need to be implemented in KXmlGui) - Tab bar (Needs a different appraoch because it already inherits QTabBar and therefore can not inherit AnimatedHeightWidget) | |||
| 2023-06-04 | Update my eMail to the KDE-provided one | Felix Ernst | |
| GIT_SILENT NO_CHANGELOG | |||
| 2022-09-26 | Remove unused includes | Laurent Montel | |
| 2022-08-14 | Improve naming consistency and leave mode on Escape | Felix Ernst | |
| 2022-08-14 | Improve code quality | Felix Ernst | |
| 2022-08-14 | Better separation of classes | Felix Ernst | |
| Make obvious when actions trigger selection mode. | |||
 |
index : dolphin | |
| Patched KDE Dolphin with Pixel Scaling | Conway |
| summaryrefslogtreecommitdiff |