dolphin/src/dolphincontextmenu.cpp

461 lines
16 KiB
C++
Raw Normal View History

/*
* SPDX-FileCopyrightText: 2006 Peter Penz (peter.penz@gmx.at) and Cvetoslav Ludmiloff
*
* SPDX-License-Identifier: GPL-2.0-or-later
*/
#include "dolphincontextmenu.h"
#include "dolphin_generalsettings.h"
#include "dolphin_contextmenusettings.h"
#include "dolphinmainwindow.h"
#include "dolphinnewfilemenu.h"
#include "dolphinplacesmodelsingleton.h"
#include "dolphinremoveaction.h"
#include "dolphinviewcontainer.h"
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
#include "global.h"
#include "trash/dolphintrash.h"
#include "views/dolphinview.h"
#include "views/viewmodecontroller.h"
#include <KActionCollection>
2011-02-11 18:33:29 +00:00
#include <KFileItemListProperties>
#include <KHamburgerMenu>
#include <KIO/EmptyTrashJob>
#include <KIO/JobUiDelegate>
#include <KIO/Paste>
#include <KIO/RestoreJob>
#include <KJobWidgets>
#include <KLocalizedString>
#include <KNewFileMenu>
#include <KPluginMetaData>
2011-02-11 18:33:29 +00:00
#include <KStandardAction>
#include <KToolBar>
#include <QApplication>
#include <QClipboard>
2014-11-02 16:03:18 +00:00
#include <QKeyEvent>
#include <QMenuBar>
#include <QMimeDatabase>
DolphinContextMenu::DolphinContextMenu(DolphinMainWindow* parent,
const KFileItem& fileInfo,
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
const KFileItemList &selectedItems,
const QUrl& baseUrl,
KFileItemActions *fileItemActions) :
2014-10-10 21:36:36 +00:00
QMenu(parent),
m_mainWindow(parent),
m_fileInfo(fileInfo),
m_baseUrl(baseUrl),
2017-11-21 09:52:14 +00:00
m_baseFileItem(nullptr),
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
m_selectedItems(selectedItems),
m_selectedItemsProperties(nullptr),
m_context(NoContext),
m_copyToMenu(parent),
m_removeAction(nullptr),
m_fileItemActions(fileItemActions)
{
QApplication::instance()->installEventFilter(this);
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
addAllActions();
}
DolphinContextMenu::~DolphinContextMenu()
{
delete m_baseFileItem;
m_baseFileItem = nullptr;
delete m_selectedItemsProperties;
m_selectedItemsProperties = nullptr;
}
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
void DolphinContextMenu::addAllActions()
{
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
static_cast<KHamburgerMenu *>(m_mainWindow->actionCollection()->
action(QStringLiteral("hamburger_menu")))->addToMenu(this);
// get the context information
const auto scheme = m_baseUrl.scheme();
if (scheme == QLatin1String("trash")) {
m_context |= TrashContext;
} else if (scheme.contains(QLatin1String("search"))) {
m_context |= SearchContext;
} else if (scheme.contains(QLatin1String("timeline"))) {
m_context |= TimelineContext;
}
if (!m_fileInfo.isNull() && !m_selectedItems.isEmpty()) {
m_context |= ItemContext;
// TODO: handle other use cases like devices + desktop files
}
// open the corresponding popup for the context
if (m_context & TrashContext) {
if (m_context & ItemContext) {
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
addTrashItemContextMenu();
} else {
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
addTrashContextMenu();
}
} else if (m_context & ItemContext) {
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
addItemContextMenu();
} else {
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
addViewportContextMenu();
}
}
bool DolphinContextMenu::eventFilter(QObject* object, QEvent* event)
{
Q_UNUSED(object)
if(event->type() == QEvent::KeyPress || event->type() == QEvent::KeyRelease) {
QKeyEvent* keyEvent = static_cast<QKeyEvent*>(event);
if (m_removeAction && keyEvent->key() == Qt::Key_Shift) {
if (event->type() == QEvent::KeyPress) {
m_removeAction->update(DolphinRemoveAction::ShiftState::Pressed);
} else {
m_removeAction->update(DolphinRemoveAction::ShiftState::Released);
}
}
}
return false;
}
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
void DolphinContextMenu::addTrashContextMenu()
{
Q_ASSERT(m_context & TrashContext);
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
QAction *emptyTrashAction = addAction(QIcon::fromTheme(QStringLiteral("trash-empty")), i18nc("@action:inmenu", "Empty Trash"), [this](){
Trash::empty(m_mainWindow);
});
emptyTrashAction->setEnabled(!Trash::isEmpty());
QAction* propertiesAction = m_mainWindow->actionCollection()->action(QStringLiteral("properties"));
addAction(propertiesAction);
}
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
void DolphinContextMenu::addTrashItemContextMenu()
{
Q_ASSERT(m_context & TrashContext);
Q_ASSERT(m_context & ItemContext);
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
addAction(QIcon::fromTheme("restoration"), i18nc("@action:inmenu", "Restore"), [this](){
QList<QUrl> selectedUrls;
selectedUrls.reserve(m_selectedItems.count());
2020-10-23 17:48:22 +00:00
for (const KFileItem &item : qAsConst(m_selectedItems)) {
selectedUrls.append(item.url());
}
KIO::RestoreJob *job = KIO::restoreFromTrash(selectedUrls);
KJobWidgets::setWindow(job, m_mainWindow);
job->uiDelegate()->setAutoErrorHandlingEnabled(true);
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
});
QAction* deleteAction = m_mainWindow->actionCollection()->action(KStandardAction::name(KStandardAction::DeleteFile));
addAction(deleteAction);
QAction* propertiesAction = m_mainWindow->actionCollection()->action(QStringLiteral("properties"));
addAction(propertiesAction);
}
void DolphinContextMenu::addDirectoryItemContextMenu()
{
// insert 'Open in new window' and 'Open in new tab' entries
const KFileItemListProperties& selectedItemsProps = selectedItemsProperties();
if (ContextMenuSettings::showOpenInNewTab()) {
addAction(m_mainWindow->actionCollection()->action(QStringLiteral("open_in_new_tab")));
}
if (ContextMenuSettings::showOpenInNewWindow()) {
addAction(m_mainWindow->actionCollection()->action(QStringLiteral("open_in_new_window")));
}
// Insert 'Open With' entries
addOpenWithActions();
// set up 'Create New' menu
DolphinNewFileMenu* newFileMenu = new DolphinNewFileMenu(m_mainWindow->actionCollection(), m_mainWindow);
newFileMenu->checkUpToDate();
newFileMenu->setPopupFiles(QList<QUrl>() << m_fileInfo.url());
newFileMenu->setEnabled(selectedItemsProps.supportsWriting());
connect(newFileMenu, &DolphinNewFileMenu::fileCreated, newFileMenu, &DolphinNewFileMenu::deleteLater);
connect(newFileMenu, &DolphinNewFileMenu::directoryCreated, newFileMenu, &DolphinNewFileMenu::deleteLater);
QMenu* menu = newFileMenu->menu();
menu->setTitle(i18nc("@title:menu Create new folder, file, link, etc.", "Create New"));
menu->setIcon(QIcon::fromTheme(QStringLiteral("list-add")));
addMenu(menu);
addSeparator();
}
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
void DolphinContextMenu::addItemContextMenu()
{
Q_ASSERT(!m_fileInfo.isNull());
const KFileItemListProperties& selectedItemsProps = selectedItemsProperties();
m_fileItemActions->setItemListProperties(selectedItemsProps);
if (m_selectedItems.count() == 1) {
// single files
if (m_fileInfo.isDir()) {
addDirectoryItemContextMenu();
} else if (m_context & TimelineContext || m_context & SearchContext) {
addOpenWithActions();
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
addAction(QIcon::fromTheme(QStringLiteral("document-open-folder")),
i18nc("@action:inmenu",
"Open Path"),
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
[this](){
m_mainWindow->changeUrl(KIO::upUrl(m_fileInfo.url()));
m_mainWindow->activeViewContainer()->view()->markUrlsAsSelected({m_fileInfo.url()});
m_mainWindow->activeViewContainer()->view()->markUrlAsCurrent(m_fileInfo.url());
});
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
addAction(QIcon::fromTheme(QStringLiteral("window-new")),
i18nc("@action:inmenu",
"Open Path in New Window"),
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
[this](){
Dolphin::openNewWindow({m_fileInfo.url()}, m_mainWindow, Dolphin::OpenNewWindowFlag::Select);
});
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
addAction(QIcon::fromTheme(QStringLiteral("tab-new")),
i18nc("@action:inmenu",
"Open Path in New Tab"),
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
[this](){
m_mainWindow->openNewTab(KIO::upUrl(m_fileInfo.url()));
});
addSeparator();
} else {
// Insert 'Open With" entries
addOpenWithActions();
}
if (m_fileInfo.isLink()) {
addAction(m_mainWindow->actionCollection()->action(QStringLiteral("show_target")));
addSeparator();
}
} else {
// multiple files
bool selectionHasOnlyDirs = true;
for (const auto &item : qAsConst(m_selectedItems)) {
const QUrl& url = DolphinView::openItemAsFolderUrl(item);
if (url.isEmpty()) {
selectionHasOnlyDirs = false;
break;
}
}
if (selectionHasOnlyDirs && ContextMenuSettings::showOpenInNewTab()) {
// insert 'Open in new tab' entry
addAction(m_mainWindow->actionCollection()->action(QStringLiteral("open_in_new_tabs")));
}
// Insert 'Open With" entries
addOpenWithActions();
}
insertDefaultItemActions(selectedItemsProps);
addAdditionalActions(selectedItemsProps);
// insert 'Copy To' and 'Move To' sub menus
if (ContextMenuSettings::showCopyMoveMenu()) {
2015-02-04 07:56:17 +00:00
m_copyToMenu.setUrls(m_selectedItems.urlList());
m_copyToMenu.setReadOnly(!selectedItemsProps.supportsWriting());
2015-02-04 07:56:17 +00:00
m_copyToMenu.setAutoErrorHandlingEnabled(true);
m_copyToMenu.addActionsTo(this);
}
// insert 'Properties...' entry
addSeparator();
QAction* propertiesAction = m_mainWindow->actionCollection()->action(QStringLiteral("properties"));
addAction(propertiesAction);
}
Refactor DolphinContextMenu so its actions are retrievable 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.
2022-04-02 17:00:58 +00:00
void DolphinContextMenu::addViewportContextMenu()
{
const KFileItemListProperties baseUrlProperties(KFileItemList() << baseFileItem());
m_fileItemActions->setItemListProperties(baseUrlProperties);
Clean up hamburger menu and viewport and single-folder context menus Summary: Dolphin's hamburger and context menus have grown organically over time, becoming a bit messy and somewhat visually overwhelming. This makes them harder to parse and more intimidating to use. This patch cleans up the hamburger menu and viewport and single-folder context menus to group items more logically, and remove items that aren't actually relevant to the context. The hamburger menu part of the patch is fairly significant, and draws from the principle of only showing actions with a global scope that are not already accessible from another visible method (e.g. via the default toolbar). In the end, it manages to be shorter than the current hamburger menu with expose actions that are more relevant. A visible method to display context-specific actions should be explored separately (see https://bugs.kde.org/show_bug.cgi?id=411500). Depends on D23945 Test Plan: Before, hamburger menu: {F7334178} After, hamburger menu: {F7350958} Before, viewport: {F7324802} After, viewport: {F7330109} Before, one folder selected: {F7324798} After, one folder selected: {F7341163} No change for the context menus shown when selecting a single item, multiple items, or multiple folders Reviewers: #vdg, #dolphin, meven, elvisangelaccio, GB_2 Reviewed By: #vdg, #dolphin, meven, elvisangelaccio, GB_2 Subscribers: GB_2, mmustac, elvisangelaccio, meven, ndavis, kfm-devel Tags: #dolphin Differential Revision: https://phabricator.kde.org/D23757
2019-09-06 16:08:58 +00:00
// Set up and insert 'Create New' menu
KNewFileMenu* newFileMenu = m_mainWindow->newFileMenu();
newFileMenu->checkUpToDate();
newFileMenu->setPopupFiles(QList<QUrl>() << m_baseUrl);
Clean up hamburger menu and viewport and single-folder context menus Summary: Dolphin's hamburger and context menus have grown organically over time, becoming a bit messy and somewhat visually overwhelming. This makes them harder to parse and more intimidating to use. This patch cleans up the hamburger menu and viewport and single-folder context menus to group items more logically, and remove items that aren't actually relevant to the context. The hamburger menu part of the patch is fairly significant, and draws from the principle of only showing actions with a global scope that are not already accessible from another visible method (e.g. via the default toolbar). In the end, it manages to be shorter than the current hamburger menu with expose actions that are more relevant. A visible method to display context-specific actions should be explored separately (see https://bugs.kde.org/show_bug.cgi?id=411500). Depends on D23945 Test Plan: Before, hamburger menu: {F7334178} After, hamburger menu: {F7350958} Before, viewport: {F7324802} After, viewport: {F7330109} Before, one folder selected: {F7324798} After, one folder selected: {F7341163} No change for the context menus shown when selecting a single item, multiple items, or multiple folders Reviewers: #vdg, #dolphin, meven, elvisangelaccio, GB_2 Reviewed By: #vdg, #dolphin, meven, elvisangelaccio, GB_2 Subscribers: GB_2, mmustac, elvisangelaccio, meven, ndavis, kfm-devel Tags: #dolphin Differential Revision: https://phabricator.kde.org/D23757
2019-09-06 16:08:58 +00:00
addMenu(newFileMenu->menu());
// Show "open with" menu items even if the dir is empty, because there are legitimate
// use cases for this, such as opening an empty dir in Kate or VSCode or something
addOpenWithActions();
Clean up hamburger menu and viewport and single-folder context menus Summary: Dolphin's hamburger and context menus have grown organically over time, becoming a bit messy and somewhat visually overwhelming. This makes them harder to parse and more intimidating to use. This patch cleans up the hamburger menu and viewport and single-folder context menus to group items more logically, and remove items that aren't actually relevant to the context. The hamburger menu part of the patch is fairly significant, and draws from the principle of only showing actions with a global scope that are not already accessible from another visible method (e.g. via the default toolbar). In the end, it manages to be shorter than the current hamburger menu with expose actions that are more relevant. A visible method to display context-specific actions should be explored separately (see https://bugs.kde.org/show_bug.cgi?id=411500). Depends on D23945 Test Plan: Before, hamburger menu: {F7334178} After, hamburger menu: {F7350958} Before, viewport: {F7324802} After, viewport: {F7330109} Before, one folder selected: {F7324798} After, one folder selected: {F7341163} No change for the context menus shown when selecting a single item, multiple items, or multiple folders Reviewers: #vdg, #dolphin, meven, elvisangelaccio, GB_2 Reviewed By: #vdg, #dolphin, meven, elvisangelaccio, GB_2 Subscribers: GB_2, mmustac, elvisangelaccio, meven, ndavis, kfm-devel Tags: #dolphin Differential Revision: https://phabricator.kde.org/D23757
2019-09-06 16:08:58 +00:00
QAction* pasteAction = createPasteAction();
if (pasteAction) {
addAction(pasteAction);
}
Clean up hamburger menu and viewport and single-folder context menus Summary: Dolphin's hamburger and context menus have grown organically over time, becoming a bit messy and somewhat visually overwhelming. This makes them harder to parse and more intimidating to use. This patch cleans up the hamburger menu and viewport and single-folder context menus to group items more logically, and remove items that aren't actually relevant to the context. The hamburger menu part of the patch is fairly significant, and draws from the principle of only showing actions with a global scope that are not already accessible from another visible method (e.g. via the default toolbar). In the end, it manages to be shorter than the current hamburger menu with expose actions that are more relevant. A visible method to display context-specific actions should be explored separately (see https://bugs.kde.org/show_bug.cgi?id=411500). Depends on D23945 Test Plan: Before, hamburger menu: {F7334178} After, hamburger menu: {F7350958} Before, viewport: {F7324802} After, viewport: {F7330109} Before, one folder selected: {F7324798} After, one folder selected: {F7341163} No change for the context menus shown when selecting a single item, multiple items, or multiple folders Reviewers: #vdg, #dolphin, meven, elvisangelaccio, GB_2 Reviewed By: #vdg, #dolphin, meven, elvisangelaccio, GB_2 Subscribers: GB_2, mmustac, elvisangelaccio, meven, ndavis, kfm-devel Tags: #dolphin Differential Revision: https://phabricator.kde.org/D23757
2019-09-06 16:08:58 +00:00
// Insert 'Add to Places' entry if it's not already in the places panel
if (ContextMenuSettings::showAddToPlaces() &&
!placeExists(m_mainWindow->activeViewContainer()->url())) {
addAction(m_mainWindow->actionCollection()->action(QStringLiteral("add_to_places")));
}
addSeparator();
// Insert 'Sort By' and 'View Mode'
if (ContextMenuSettings::showSortBy()) {
addAction(m_mainWindow->actionCollection()->action(QStringLiteral("sort")));
}
if (ContextMenuSettings::showViewMode()) {
addAction(m_mainWindow->actionCollection()->action(QStringLiteral("view_mode")));
}
if (ContextMenuSettings::showSortBy() || ContextMenuSettings::showViewMode()) {
addSeparator();
}
addAdditionalActions(baseUrlProperties);
Clean up hamburger menu and viewport and single-folder context menus Summary: Dolphin's hamburger and context menus have grown organically over time, becoming a bit messy and somewhat visually overwhelming. This makes them harder to parse and more intimidating to use. This patch cleans up the hamburger menu and viewport and single-folder context menus to group items more logically, and remove items that aren't actually relevant to the context. The hamburger menu part of the patch is fairly significant, and draws from the principle of only showing actions with a global scope that are not already accessible from another visible method (e.g. via the default toolbar). In the end, it manages to be shorter than the current hamburger menu with expose actions that are more relevant. A visible method to display context-specific actions should be explored separately (see https://bugs.kde.org/show_bug.cgi?id=411500). Depends on D23945 Test Plan: Before, hamburger menu: {F7334178} After, hamburger menu: {F7350958} Before, viewport: {F7324802} After, viewport: {F7330109} Before, one folder selected: {F7324798} After, one folder selected: {F7341163} No change for the context menus shown when selecting a single item, multiple items, or multiple folders Reviewers: #vdg, #dolphin, meven, elvisangelaccio, GB_2 Reviewed By: #vdg, #dolphin, meven, elvisangelaccio, GB_2 Subscribers: GB_2, mmustac, elvisangelaccio, meven, ndavis, kfm-devel Tags: #dolphin Differential Revision: https://phabricator.kde.org/D23757
2019-09-06 16:08:58 +00:00
addSeparator();
QAction* propertiesAction = m_mainWindow->actionCollection()->action(QStringLiteral("properties"));
addAction(propertiesAction);
}
void DolphinContextMenu::insertDefaultItemActions(const KFileItemListProperties& properties)
{
const KActionCollection* collection = m_mainWindow->actionCollection();
2020-08-26 00:37:31 +00:00
// Insert 'Cut', 'Copy', 'Copy Location' and 'Paste'
addAction(collection->action(KStandardAction::name(KStandardAction::Cut)));
addAction(collection->action(KStandardAction::name(KStandardAction::Copy)));
if (ContextMenuSettings::showCopyLocation()) {
QAction* copyPathAction = collection->action(QString("copy_location"));
copyPathAction->setEnabled(m_selectedItems.size() == 1);
addAction(copyPathAction);
}
QAction* pasteAction = createPasteAction();
if (pasteAction) {
addAction(pasteAction);
}
// Insert 'Duplicate Here'
if (ContextMenuSettings::showDuplicateHere()) {
addAction(m_mainWindow->actionCollection()->action(QStringLiteral("duplicate")));
}
// Insert 'Rename'
addAction(collection->action(KStandardAction::name(KStandardAction::RenameFile)));
// Insert 'Add to Places' entry if appropriate
if (ContextMenuSettings::showAddToPlaces() &&
m_selectedItems.count() == 1 &&
m_fileInfo.isDir() &&
!placeExists(m_fileInfo.url())) {
addAction(m_mainWindow->actionCollection()->action(QStringLiteral("add_to_places")));
}
addSeparator();
// Insert 'Move to Trash' and/or 'Delete'
const bool showDeleteAction = (KSharedConfig::openConfig()->group("KDE").readEntry("ShowDeleteCommand", false) ||
!properties.isLocal());
const bool showMoveToTrashAction = (properties.isLocal() &&
properties.supportsMoving());
if (showDeleteAction && showMoveToTrashAction) {
delete m_removeAction;
m_removeAction = nullptr;
addAction(m_mainWindow->actionCollection()->action(KStandardAction::name(KStandardAction::MoveToTrash)));
addAction(m_mainWindow->actionCollection()->action(KStandardAction::name(KStandardAction::DeleteFile)));
} else if (showDeleteAction && !showMoveToTrashAction) {
addAction(m_mainWindow->actionCollection()->action(KStandardAction::name(KStandardAction::DeleteFile)));
} else {
if (!m_removeAction) {
m_removeAction = new DolphinRemoveAction(this, m_mainWindow->actionCollection());
}
addAction(m_removeAction);
m_removeAction->update();
}
}
bool DolphinContextMenu::placeExists(const QUrl& url) const
{
const KFilePlacesModel* placesModel = DolphinPlacesModelSingleton::instance().placesModel();
const auto& matchedPlaces = placesModel->match(placesModel->index(0,0), KFilePlacesModel::UrlRole, url, 1, Qt::MatchExactly);
return !matchedPlaces.isEmpty();
}
QAction* DolphinContextMenu::createPasteAction()
{
2017-11-21 09:52:14 +00:00
QAction* action = nullptr;
KFileItem destItem;
if (!m_fileInfo.isNull() && m_selectedItems.count() <= 1) {
destItem = m_fileInfo;
} else {
destItem = baseFileItem();
}
if (!destItem.isNull() && destItem.isDir()) {
const QMimeData *mimeData = QApplication::clipboard()->mimeData();
bool canPaste;
const QString text = KIO::pasteActionText(mimeData, &canPaste, destItem);
if (canPaste) {
if (destItem == m_fileInfo) {
// if paste destination is a selected folder
action = new QAction(QIcon::fromTheme(QStringLiteral("edit-paste")), text, this);
connect(action, &QAction::triggered, m_mainWindow, &DolphinMainWindow::pasteIntoFolder);
} else {
action = m_mainWindow->actionCollection()->action(KStandardAction::name(KStandardAction::Paste));
}
}
}
return action;
}
KFileItemListProperties& DolphinContextMenu::selectedItemsProperties() const
{
if (!m_selectedItemsProperties) {
m_selectedItemsProperties = new KFileItemListProperties(m_selectedItems);
}
return *m_selectedItemsProperties;
}
KFileItem DolphinContextMenu::baseFileItem()
{
if (!m_baseFileItem) {
const DolphinView* view = m_mainWindow->activeViewContainer()->view();
KFileItem baseItem = view->rootItem();
if (baseItem.isNull() || baseItem.url() != m_baseUrl) {
m_baseFileItem = new KFileItem(m_baseUrl);
} else {
m_baseFileItem = new KFileItem(baseItem);
}
}
return *m_baseFileItem;
}
void DolphinContextMenu::addOpenWithActions()
{
// insert 'Open With...' action or sub menu
m_fileItemActions->insertOpenWithActionsTo(nullptr, this, QStringList{qApp->desktopFileName()});
}
void DolphinContextMenu::addAdditionalActions(const KFileItemListProperties &props)
{
addSeparator();
QList<QAction *> additionalActions;
if (props.isDirectory() && props.isLocal() && ContextMenuSettings::showOpenTerminal()) {
additionalActions << m_mainWindow->actionCollection()->action(QStringLiteral("open_terminal"));
}
m_fileItemActions->addActionsTo(this, KFileItemActions::MenuActionSource::All, additionalActions);
const DolphinView* view = m_mainWindow->activeViewContainer()->view();
const QList<QAction*> versionControlActions = view->versionControlActions(m_selectedItems);
if (!versionControlActions.isEmpty()) {
addActions(versionControlActions);
addSeparator();
}
}