This is equivalent to the "Open Terminal Here" feature that existed until Version 20.12.
If the user has selected folders, replace "Open Terminal" in the context menu with "Open Terminal Here".
When more than 5 folders are selected, a modal window will ask the user if they are sure they want to
open all 6 or more terminal windows.
In Detail View, users can also select a file,
which will open a terminal at the location of that file.
BUG: 452637
FIXED-IN: 22.08
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.
With https://invent.kde.org/frameworks/kio/-/merge_requests/411 the
plugin instances can be reused during the lifetime of the
KFileItemActions object. This improves performance and also allows
the plugins to emit errors, even if they run async.
This should have belonged to my previous merge
480b3067d2 but somehow I managed to
miss this one line.
It was written by Derek Christ as part of
dc3beae3ab.
Before this patch, the shift-action modifier in context menus did not
work when a sub-context menu is open, that does not have the main
context menu as its parent.
The new fix installs an event filter on QApplication whenever a new
context menu is opened to make the context menu aware of shift-presses
even when a sub-context menu is in focus.
BUG: 425997
FIXED-IN: 21.04
Right now this action is using the "document-new" icon, which depicts
creating a new file. This is inaccurate, as the menu provides options for
creating more than just files: it has one option to create folders and
three for creating different types of links. In fact, depending on the
set of installed software, there may not be any options to create new
documents at all!
To fix this, the icon would need to be made either more specific or
more generic.
There is no such icon that depicts being able to create a folder, a
document, or a link; such a thing is too specific to be able to
represent with a small icon. So our only real option is to use a more
generic icon.
This commit does that.
To improve usability, the entries in the hamburger menu are
changed. Maybe the biggest fault of the previous menu contents were
that there were too many actions.
The new menu contents are composed of all the actions which are
necessary to use Dolphin and those which are very useful and should
be of interest for most users. Some menu contents change depending
on the state of the application. We can be more bold in only
showing what really seems necessary because this commit activates
the special sub-menu of KHamburgerMenu that helps users discover
all further features of Dolphin.
The hamburger menu is from now on also added to the context menus
in the view when both the menu bar and toolbar are hidden. This
allows users to hide both of them and still use all features of
Dolphin.
This reverts commit ce3c243525.
The apidox of setParentWidget says:
Set the parent widget for any dialogs being shown.
This should normally be your mainwindow, not a popup menu, so that it still exists even after the popup is closed
(e.g. error message from KRun) and so that QAction::setStatusTip can find a statusbar, too.
CCBUG: 425997
This commit add options to hide the following context menu entries:
- Add to Places
- Copy Location
- Duplicate Here
- Open in New Tab and Open in New Tabs
- Open in New Window
- Sort By
- View Mode
The Services settings page is renamed to Context Menu
ShowCopyMoveMenu option is moved from GeneralSettings to ContextMenuSettings
BUG: 314594
In 9e4642d435 support was added for the
NewFileMenu.
This adds support for the Plugins submenu provided they relay their
parentWidget to their own menus.
BUG: 425997
Switching the 'Move to Trash' action to 'Delete' using the shift key
does not work when the mouse hovers a submenu. This fix resolves the
issue by using an event filter instead of the key event functions.
BUG: 425997
This makes a bit easier to handle the stuff.
Also we don't need the `addVersionControlPluginActions` utility method
and we can put it in the new utility method instead.
Right now these actions are in a visual group with "Rename" and "Add to
Places" which is silly as those actions have no logical connection
whatsoever to deletion.
This commits moves those items into the section above, putting them in a
more logical place and leaving the Delete/Move To Trash item in its own
section.
BUG: 429256
FIXED-IN: 21.04
* Adds a "Copy location" item, after the "Copy" Context item and Edit Menu, which will attempt to copy the path of the fist item into clipboard.
## Reasoning
Most File Managers have this option through one or another way.
Also using the default Copy option often results in different behaviour depending on the target software, Konsole will take the path. Other Programs will use the URI. Which ultimately could lead to non optimal User Experience.
## Notes
* Should the target file **not** be on a local hard drive, this fallback to using the remote URL, feedback is wanted on that matter.
FEATURE: 407004
Summary: Adds a Duplicate feature to Dolphin, showing up as a menu item in the File menu that appears when one or more items are selected and the directory is writable. Duplicated items receive the names of the original files with " copy" appended before the file extension, if any.
Test Plan:
{F5201386} {F5201393}
Test cases:
- Try to duplicate when nothing is selected: **PASS**: menu item is grayed out
- Try to duplicate anything on a read-only local volume: **PASS**: menu item is grayed out
- Try to duplicate anything on a read-only samba share: **PASS**: menu item is grayed out
- Duplicate single local file on R/W volume: **PASS**: item is duplicated and named correctly
- Duplicate multiple local files on R/W volume: **PASS**: 3 items are duplicated, named correctly, and selected
- Duplicate single local directory on R/W volume: **PASS**: item is duplicated and named correctly, but a rename operation is not initiated
- Duplicate multiple local directories on R/W volume: **PASS**: 3 items are duplicated, named correctly, and selected
- Duplicate single file on R/W samba share: **PASS**: item is duplicated and correctly
- Duplicate multiple files on R/W samba share: **PASS**: 3 items are duplicated, named correctly, and selected
- Duplicate single directory on R/W samba share: **PASS**: item is duplicated and named correctly
- Duplicate multiple directory on R/W samba share: **PASS**: 3 items are duplicated, named correctly, and selected
- Try to undo a successful duplication: **PASS**: operation is undone
This is my first attempt at a big change like this and I'm sure it's full of issues. I will accept any and all suggestions for improvement. :)
Reviewers: #dolphin, #kde_applications, elvisangelaccio, dfaure, broulik, davidedmundson
Subscribers: kfm-devel, meven, markg, fazevedo, cfeck, #dolphin
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D8208
Summary:
I've seem various complaints from users about the fact that the {nav Create New...} menu
item in the viewport context menu is now below {nav Open With} item. All the other
changes to menus seem to have been well-received but this one has garnered criticism.
Looking through D23757 and D11884, I can't actually see that this was intentional, so
it might even be a bug.
Either way, this patch restores the old position of the {nav Create New} menu items at
the top of the Viewport context menu.
BUG: 417640
FIXED-IN: 20.04.0
Test Plan: {F8093605}
Reviewers: #vdg, #dolphin, elvisangelaccio, ndavis
Reviewed By: #vdg, ndavis
Subscribers: asturmlechner, markuss, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D27267
Summary:
Since Dolphin's default behaviour became opening in new tabs rather than in new windows
(a very positive change, in my opinion), I always find myself accidentally opening folders
in new windows from the context menu. This is because in most browsers with tab workflow
(e.g. Firefox, Chromium, Falkon) the top context menu action is opening in a new tab, and
my muscle memory plays a bad trick :) I'm aware of middle-clicking, but I find it
inconvenient with my touchpad.
I suspect I'm probably not alone in that, so I think it makes sense to swap these actions
in Dolphin to match widely used apps.
Test Plan:
Open Dolphin, right click folders in the main view and in the Places panel, ensure the
actions are indeed swapped
Reviewers: #vdg, ndavis, #dolphin, ngraham
Reviewed By: #vdg, ndavis, #dolphin, ngraham
Subscribers: ngraham, ndavis, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D27318
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
In D22149, a request was made to remove a variable assignment ("action",
on line 389 in src/dolphincontextmenu.cpp. However the change went too
far, and it actually removed the exec() call, not just the assignment
which should have stayed.
This resulted in the context menu not being shown at all.
Adding back exec(m_pos) at least allows for the context menu to show.
CCMAIL: nate@kde.org
Summary:
It's recommended that actions available in context menus be available in the main menu
as well for discoverability's sake. This patch does so for the "Add to Places" action.
The action is moved over to the main window, and accessed in the context menu via the
actionCollection it lives in.
BUG: 390757
FIXED-IN: 19.08.0
Test Plan:
- Action still works
- Action still appears in context menu when relevant
- Action in the File menu only becomes enabled when only a single directory is selected or nothing is selected
{F7143876}
{F7143877}
{F7143878}
{F7143879}
Reviewers: #dolphin, elvisangelaccio
Reviewed By: #dolphin, elvisangelaccio
Subscribers: elvisangelaccio, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D22149
Summary:
Any app that registers itself as able to open directories generally can't do anything
useful with an empty directory. So, don't show the {nav Open With} menu items for them.
Test Plan:
Before: {F6759793}
After: {F6759794}
The {nav Open With} items still appear for non-empty directories.
Reviewers: #dolphin, elvisangelaccio
Reviewed By: #dolphin, elvisangelaccio
Subscribers: trmdi, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D20396
