| Age | Commit message (Collapse) | Author |
|---|
|
Displays it in the menu like a keyboard shortcut. Otherwise nobody
will ever find this feature.
|
|
GIT_SILENT
|
|
|
|
|
|
This action is shown only if a single folder is selected. The action
opens the selected folder in the inactive split view (and opens the
split view if necessary).
FEATURE: 465500
|
|
Amends 3aa8cf00ee90b0414fa9b17f01eaade4507c4642
|
|
|
|
|
|
|
|
|
|
Looks like I missed it back in
https://invent.kde.org/system/dolphin/-/commit/402f7f3041d45d8c5969f3bc202fe9156891cd2e
— so fixing now :)
|
|
|
|
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
|
|
This commit is the result of a three-way diff that
combines my own initial patch with related changes from
Felix Ernst's MR !545 and further suggestions by Méven Car.
Fixes DolphinMainWindowTest::testNewFileMenuEnabled().
Tests are now passing again for my build.
"Create New" was broken by commit c64059bd which switched to the
new, non-deprecated KNewFileMenu constructor (kio commit 89bc6bad)
that doesn't add itself to the passed KActionCollection parameter.
After the switch, hamburger menu and context menu was still working
as intended but the menu bar was missing the "Create New" menu.
This commit adds the addAction("new_menu") call to the File menu
setup that would have previously been called by the deprecated
KNewFileMenu constructor. The corresponding test can now find
the QObject for the menu's named action again, verifying its
existence and enabled-ness like it did before.
The DolphinNewFileMenu constructor's unused actionCollection
parameter serves no use anymore except to confuse people.
We replace it with a single QAction* parameter, createDirAction,
which gets passed to setNewFolderShortcutAction().
2 out of 3 constructor call sites have access to this action,
while the remaining call site in dolphinmainwindow.cpp must wait
until after it has been initialized by DolphinViewActionHandler.
In this case, setNewFolderShortcutAction() is still called manually
at a later time.
|
|
|
|
|
|
Prevent copying/moving to same folder as origin when copying/moving to inactive split view
BUG: 356436
|
|
|
|
|
|
|
|
The former is deprecated
|
|
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.
|
|
This removes the custom-view engine version of the places panel
and replaces it with the upstream `KFilePlacesView` from KIO.
|
|
The implementation doesn't do anything
|
|
Instead of the KServiceTypeTrader constraint, pass the desktop file name
as part of the exclude list to the method call.
|
|
|
|
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.
|
|
Task: https://phabricator.kde.org/T12164
|
|
|
|
This should have belonged to my previous merge
480b3067d25e4b49ea55285313a7c10e93f98ffd but somehow I managed to
miss this one line.
It was written by Derek Christ as part of
dc3beae3ab2c55cd3501e17f93b51e93e876a177.
|
|
|
|
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.
|
|
BUG: 436323
FIXED-IN: 21.08
|
|
This reverts commit ce3c2435250f5eb8a3c9322359b25c46d2b6fb96.
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
|
|
|
|
`m_context` can also be `SearchContext` or `TimelineContext`, so this
assert has been wrong since 8b0c12a59ccb23f.
|
|
In 9e4642d435085f27134ed6c8431734dcacf65834 support was added for the
NewFileMenu.
This adds support for the Plugins submenu provided they relay their
parentWidget to their own menus.
BUG: 425997
|
|
|
|
BUG: 429762
|
|
|
|
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
|
|
Either the viewport, or the selected folder is used as destination.
The paste action is only added when enabled.
|
|
|
