dolphin/src/dolphincontextmenu.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

137 lines
3.7 KiB
C
Raw Normal View History

/*
* SPDX-FileCopyrightText: 2006 Peter Penz <peter.penz19@gmail.com>
*
* SPDX-License-Identifier: GPL-2.0-or-later
*/
#ifndef DOLPHINCONTEXTMENU_H
#define DOLPHINCONTEXTMENU_H
2015-02-04 07:56:17 +00:00
#include <KFileCopyToMenu>
#include <KFileItem>
#include <KFileItemActions>
#include <QMenu>
#include <QUrl>
class QAction;
class DolphinMainWindow;
class KFileItemListProperties;
class DolphinRemoveAction;
/**
* @brief Represents the context menu which appears when doing a right
* click on an item or the viewport of the file manager.
*
* Beside static menu entries (e. g. 'Paste' or 'Properties') two
* dynamic sub menus are shown when opening a context menu above
* an item:
* - 'Open With': Contains all applications which are registered to
* open items of the given MIME type.
* - 'Actions': Contains all actions which can be applied to the
* given item.
*/
2014-10-10 21:36:36 +00:00
class DolphinContextMenu : public QMenu
{
Q_OBJECT
public:
/**
* @parent Pointer to the main window the context menu
* belongs to.
* @fileInfo Pointer to the file item the context menu
* is applied. If 0 is passed, the context menu
* is above the viewport.
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
* @selectedItems The selected items for which the context menu
* is opened. This list generally includes \a fileInfo.
* @baseUrl Base URL of the viewport where the context menu
* should be opened.
*/
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);
~DolphinContextMenu() override;
protected:
bool eventFilter(QObject *object, QEvent *event) override;
private:
/**
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
* Adds all the actions and menus to this menu based on all given information.
* This method calls the other helper methods for adding actions
* based on the context given in the constructor.
*/
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 addAllActions();
void addTrashContextMenu();
void addTrashItemContextMenu();
void addItemContextMenu();
void addViewportContextMenu();
void insertDefaultItemActions(const KFileItemListProperties &);
bool placeExists(const QUrl &url) const;
QAction *createPasteAction();
KFileItemListProperties &selectedItemsProperties() const;
/**
* Returns the file item for m_baseUrl.
*/
KFileItem baseFileItem();
/**
* Adds "Open With" actions
*/
void addOpenWithActions();
/**
* Add services, custom actions, plugins and version control items to the menu
*/
void addAdditionalActions(const KFileItemListProperties &props);
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
private:
void addDirectoryItemContextMenu();
void addOpenParentFolderActions();
struct Entry {
int type;
QString name;
QString filePath; // empty for separator
QString templatePath; // same as filePath for template
QString icon;
QString comment;
};
enum ContextType {
NoContext = 0,
ItemContext = 1,
TrashContext = 2,
TimelineContext = 4,
SearchContext = 8,
RecentlyUsedContext = 16,
};
DolphinMainWindow *m_mainWindow;
KFileItem m_fileInfo;
QUrl m_baseUrl;
KFileItem *m_baseFileItem; /// File item for m_baseUrl
KFileItemList m_selectedItems;
mutable KFileItemListProperties *m_selectedItemsProperties;
int m_context;
2015-02-04 07:56:17 +00:00
KFileCopyToMenu m_copyToMenu;
DolphinRemoveAction *m_removeAction; // Action that represents either 'Move To Trash' or 'Delete'
KFileItemActions *m_fileItemActions;
};
#endif