* 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
In KF6 KMoreTools should become it's own library and thus the KNS3 prefix should get removed.
Considering that the classes are not in any namespace, having a namespaced include is not needed and only causes noise.
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.
By defining the KF_DISABLE_DEPRECATED_BEFORE_AND_AT and QT_DISABLE_DEPRECATED_BEFOREvalues,
the deprecated overloads are hidden. This way we only have the un-deprecated one visible.
Dolphin still uses KToolInvocation::invokeTerminal() which is
deprecated and requires KInit. However Dolphin was ported away from
requiring it in other ways, so it is now possible to have Dolphin
running but not KInit, which breaks the "Open in Terminal"
functionality.
Using KTerminalLauncherJob fixes this. It was introduced in Frameworks
5.83, so the CMake dependency version is accordingly increased.
BUG: 441072
FIXED-IN: 21.12
Since KIO 5.82, KCoreDirLister (the base class of KDirLister) emits a jobError()
signal when the ListJob used internally emits an error.
Drop KFileItemModelDirLister class, now redundant.
This also bump the KF version to 5.82.
This commit replaces an error-prone usage of KIO::StatJob::exec() in
DolphinView with the recommended KIO::StatJob::start().
The containing method DolphinView::statusBarText() is changed to be a
method without return value: requestStatusBarText()
The new status bar text is instead returned through a new
setStatusBarText() signal that will be emitted asynchronously if
necessary.
The calling code that deals with status bar text is refactored to
correctly work despite the new asynchronicity. The helper method
calculateItemCount() is moved into requestStatusBarText() and some
other code from requestStatusBarText() is moved into a new helper
method emitStatusBarText().
The documentation of KIO::KJob::exec() explains why it should be
avoided. A reproducible crash is the reason for this commit.
It's a very useful facilitity, and having a history of entries and being
able to recall earlier ones makes it even more useful for repetitive
operations.
Summary:
Port QRegExp::exactMatch() with QRegularExpression::anchoredPattern().
Port QRegExp::Wildcard with QRegularExpression::wildcardToRegularExpression().
Note that QRegularExpression::wildcardToRegularExpression() returns an anchored
pattern.
Test Plan:
Using the filter bar in dolphin works as before.
All unit tests pass, except:
- kfileitemmodeltest (which is unrelated AFAICS); it fails on master too
- placesitemmodeltest, which fails on master too
Reviewers: #dolphin, elvisangelaccio, meven
Reviewed By: #dolphin, elvisangelaccio
Subscribers: kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D26215
Summary:
I chose CommandLauncherJob rather than ApplicationLauncherJob
because that would require either looking up org.kde.kfind.desktop
(with a risk of failure) or duplicating the icon name...
Test Plan:
commented out the if() block of the slot, to make sure we end
up launching kfind with this code. Then konqueror /, and Ctrl+F.
Reviewers: broulik
Reviewed By: broulik
Differential Revision: https://phabricator.kde.org/D28810
Summary: The old icon was a color icon, which does not match the style of other toolbar/menu buttons
Test Plan: {F7321334, size=full}{F7321319}
Reviewers: #dolphin, #vdg, ngraham
Reviewed By: #dolphin, #vdg, ngraham
Subscribers: ngraham, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D23740
QGuiApplication::queryKeyboardModifiers() does not work on Wayland [1].
We don't need it in the first place, since we already know (thanks to
the key events) whether Shift has been pressed or released.
So we can just pass this information to DolphinRemoveAction::update().
BUG: 354301
[1]: https://bugreports.qt.io/browse/QTBUG-62786
Differential Revision: https://phabricator.kde.org/D7519
It was introduced in kconfig(widgets) 5.25. Using the standard action
results in less code and no need to hardcode the F2 shortcut.
Differential Revision: https://phabricator.kde.org/D6777
It was introduced in kconfig(widgets) 5.25. Using the standard action
results in less code and no need to hardcode the Del shortcut.
Test Plan:
- Change shortcut in System Settings -> Shortcuts -> Standard Shortcuts
- Make sure the new shortcut is used by dolphin.
Differential Revision: https://phabricator.kde.org/D6778
Summary:
It was introduced in kconfig 5.25 and it properly handles the shift+del
shortcut (together with kxmlgui >= 5.30). This allows us to drop the
custom delete shortcut as well as the shift+del workaround in
DolphinMainWindow.
Test Plan: Shift+Del still deletes files, without the 'ambiguous shortcut' warning dialog.
Reviewers: emmanuelp
Differential Revision: https://phabricator.kde.org/D5010
The KAuthorized key to prevent shell access according the documentation
is simply "shell_action" not "action/shellAction" so should use
authorize not authorizeKAction
This appears to have come about as part of a porting bug when going from
KApplication::authorize to KAuthorized in kdelibs3 to kdelibs4.
To currently block shell access a sysadmin currently needs to
have both keys set already, so we can be confident it won't have any
actual compatibility problems.