b3add25694
This mostly red MR should have no visible effect. It is part of my work towards !273. There are two calls necessary to open the DolphinContextMenu: One to construct it and one to execute/show it. Before this commit, the actual populating of the ContextMenu was done on execute. This meant that the actions of the ContextMenu couldn't be looked at or changed without first showing the Menu to the user. It also meant that the construction itself didn't actually do much constructing/populating at all which might seem a bit unintuitive. This commit changes this behaviour so the DolphinContextMenu is actually populated fully on construction. The executing/showing of the ContextMenu now does just that and nothing more. Previously, some actions in the context menu were actually not wired up to anything and instead the DolphinContextMenu or the DolphinMainWindow executed some code after the user had clicked such a dummy action from the ContextMenu. Now all the actions are properly constructed beforehand and no special handling is necessary when the ContextMenu hides itself. This commit removes the pos parameter from the DolphinContextMenu constructor. This parameter contained the position where the Menu would be shown later. This information isn't necessary to have on construction and was already part of the exec(pos) call in the first place. The variable m_pos that stored the value is removed. This commit also removes a "customActions" functionality that can supposedly be used to add further custom actions to the DolphinContextMenu but this functionality isn't ever used anywhere so its usefulness is questionable. It also wouldn't be difficult to re-add this functionality if it was ever required for something. This commit also addresses an old TODO in dolphinpart.cpp that asked for the calls for opening the DolphinContextMenu to actually contain the information for which items the DolphinContextMenu is supposed to be constructed. Before this, only the item that was directly clicked was transmitted and then DolphinContextMenu retrieved the currently selected set of items by itself. It makes more sense that DolphinContextMenu would be informed on construction which items it is supposed to show context actions for. Most of this is necessary so we are able to show the contextual actions anywhere else than in the ContextMenu in the future. I am targeting 22.08 with this MR because it makes no sense to merge a refactor for the upcoming release already. |
||
|---|---|---|
| cmake | ||
| doc | ||
| LICENSES | ||
| src | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .kde-ci.yml | ||
| AUTHORS | ||
| CMakeLists.txt | ||
| CMakePresets.json | ||
| COPYING | ||
| COPYING.DOC | ||
| DolphinVcsConfig.cmake.in | ||
| logo.png | ||
| plasma-dolphin.service.in | ||
| README.md | ||
User Documentation
See https://userbase.kde.org/Special:myLanguage/Dolphin
Development Information
Dolphin's source code can be found at https://invent.kde.org/system/dolphin/
To build Dolphin from source, see https://community.kde.org/Get_Involved/development#Applications
To submit a patch to Dolphin, use https://invent.kde.org/system/dolphin/-/merge_requests/.
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.