122fee5625
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 |
||
|---|---|---|
| appiumtests | ||
| cmake | ||
| completions | ||
| doc | ||
| LICENSES | ||
| po | ||
| src | ||
| .flatpak-manifest.json | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .kde-ci.yml | ||
| CMakeLists.txt | ||
| CMakePresets.json | ||
| COPYING | ||
| COPYING.DOC | ||
| DolphinVcsConfig.cmake.in | ||
| logo.png | ||
| plasma-dolphin.service.in | ||
| README.md | ||
Dolphin
Dolphin is KDE's file manager that lets you navigate and browse the contents of your hard drives, USB sticks, SD cards, and more. Creating, moving, or deleting files and folders is simple and fast. See more information on Dolphin's homepage.
User Documentation
See https://userbase.kde.org/Special:myLanguage/Dolphin.
Contributing
Like other projects in the KDE ecosystem, contributions are welcome from all. This repository is managed in KDE Invent, our GitLab instance.
- Want to contribute code? See the GitLab wiki page for a tutorial on how to send a merge request.
- Reporting a bug? Please submit it on the KDE Bugtracking System. Please do not use the Issues tab to report bugs.
- Is there a part of Dolphin that's not translated? See the Getting Involved in Translation wiki page to see how you can help translate!
If you get stuck or need help with anything at all, head over to the KDE New Contributors room on Matrix. For questions about Dolphin, please ask in the KDE File Management room. See Matrix for more details.
Development Philosophy
Dolphin is a file manager focusing on usability. When reading the term Usability people often assume that the focus is on newbies and only basic features are offered. This is not the case; Dolphin is quite full-featured, but the features are carefully chosen so as to not impede any of the users in the target user groups.
Target User Groups
Focusing on usability means that features are discoverable and efficient to use. The feature set is defined indirectly by the target user group of Dolphin:
-
Lisa: Lisa has been familiar with computers for 10 years. From her job, she has experience with Word, Excel and Outlook. At home she mainly uses the computer for browsing the web and writing e-mails. She requires a file manager for managing photos from the camera, documents she gets via e-mail, or PDFs she downloads with a browser. Lisa knows concepts like folders and a file hierarchy, but she is not familiar with the file hierarchy of Linux.
-
Simon: Simon has been a developer at a software company for 8 years. At home he uses a file manager to maintain his large collection of photos and music. Additionally he owns a small homepage and needs to transfer updated files on the FTP server. Moving and copying files are regular tasks in Simon's workflow.
Not part of the target user group of Dolphin are Fred and Jeff:
-
Fred: Fred is 75 years old and is able to write e-mails and browsing the web. He is not familiar with file hierarchies and stores all his documents on the desktop.
-
Jeff: Jeff is Linux-freak since the age of 16 a few years ago. He is a developer and in his spare time he acts as administrator for a small company. Jeff has two monitors to keep the overview about his huge number of opened applications.
This does not mean that Fred or Jeff cannot work with Dolphin. But there might be features and concepts of Dolphin that overburden Fred. Also Jeff might miss some features which are a must-have for his daily work. This is acceptable; there are other tools that cater specifically to their needs.
Non-Intrusive Features
Before a feature is added in Dolphin, check whether the feature is mandatory for the target user group. If this is not the case, then this does not mean that the feature cannot be added; first it must be clarified whether the feature might be non-intrusive, so that it adds value for users outside the primary target user group of Dolphin. The term "non-intrusive" is mainly related to the user interface. A feature that adds a lot of clutter to the main menu, context menus or toolbar might harm the target user group. In this case the feature should not be added.
A good example of a feature that is non-intrusive is the embedded terminal in Dolphin. It only requires one entry inside a sub-menu, but adds great value for Jeff, who is not part of the target user group.
Options
Options are mandatory as the "average Joe" user does not exist. Still it is not the goal of Dolphin to offer options for all kind of things. Again the focus is on the possible needs of the target user group. Each additional option makes it harder finding other options, so the same rules for features are applied to options too.