The terminal panel is supposed to show the same location as the
currently active Dolphin view at all times.
However there was an issue when the terminal is supposed to
quickly switch to a new location and then back again to the old
one. The terminal ignored the switch to the old location unless it
had already fully switched to the new location. Because it isn't
particularly fast at fully switching to the new location, it would
never do the expected thing of switching back to the old location.
This commit makes it so the switch to the old location is only
ignored if there are no in-progress switches to a different
location.
BUG: 391380
BUG: 416690
FIXED-IN: 22.04.2
Not totally sure if this fixes everything but it seems like an improvement.
Currently, Dolphin doesn't have the ability to sort by file extension (sorting by type means that files will be sorted by mimetype but not by extension). This MR fixes this shortcoming.
BUG: 429579
(Part of my work towards !273)
Currently, when items are selected and a user right-clicks a selected item
while having the Ctrl key pressed down, the item is first
deselected and then a context menu is opened that doesn't involve
the item that was just deselected.
This is slightly confusing because normally one right-clicks an
item to see its context menu. Right-click being able to deselect
an item seems like unintended functionality in the first place but
in this scenario it also means that the intended opening of a
context menu for the pressed item doesn't even happen.
There is a good chance that nobody is even aware of this behaviour
because the normal way to deselect an item would be to
Ctrl+Left-Click if anything. Why would someone choose to open a
context menu and deselect items in a single step? Why would they
have selected an item they don't want to open a context menu for in
the first place?
Because of a discussion in this merge request deselecting on Ctrl+Middle-Click was also
removed for consistency with Ctrl+Right-Click and
Ctrl+Shift+Middle-Click.
This commit also makes a later implementation of a selection mode
more straightforward.
Accepts Ark's special dnd mime types so that archive contents can
be dragged onto a place to extract and/or (mount and) switch to the
hovered location.
There have been some reports that users were unable to figure out
that the padding on the left of the left-most "name" column can be
used for deselecting or for dropping file items. All of these
reports were by people using a Dolphin version in which that
padding was way too narrow because of a regression (that has since
been fixed). Nonetheless this highlights the potential problem that
some users might be unable to notice/figure out the usefulness of
the left padding.
This commit adds a similar area on the right side of the view when
the column widths are set automatically by Dolphin. The width of
the right padding column mirrors the width of the left padding
column when sized automatically. Both can manually be hidden or
resized similarly to resizing other columns.
There are various usability advantages to having this padding by
default on both sides of the view and not only on the left:
- The right margin is more discoverable since the item highlight
ends right before the padding column
- Less mouse travel time to reach either of the areas
- More than double the likelihood of users figuring out the
advantages of these padding areas for deselecting or dropping
- More visual symmetry
I had suggested also having this kind of right padding even before
the initial implementation of the left padding. The contributor
implementing it was in favour of it. It only wasn't implemented
because the contributor said it was impossible without a lot of
work. Turns out adding two characters at the right position seems
to suffice in most ways.
This commit does not contain the string change of renaming "Leading
Column Padding" to "Column Padding" (since it changes two paddings
now) to not infringe on the string freeze.
BUG: 452273
Since d383961719 dragging the
highlighted row of already selected items in the details view mode
will begin a drag operation of all selected items.
As a unintended side-effect of this change, dragging the row of a
previously unselected item while holding the control key would also
begin a drag operation.
After this commit, dragging the row of a previously unselected item
while holding the control key in details view mode will instead
create a rubberband. Ctrl-dragging the item's icon or text directly will drag the item as expected.
With this change, using multiple rubberbands to select scattered
items among a list of items should be as convenient as it was
previously.
BUG: 452181
This reverts commit 3ce9d1d19e.
This reverts commit ddba4f5fd8.
Aside from the two bugs mentioned below, this also fixes another
regression: The spacing on the left of the view does now once again
follow the size of its column header.
BUG: 451704
BUG: 451341
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.
Since KIO 5.85, this new file location is preferred over the
KServiceTypeTrader results.
With this change, single desktop files from the KDE store are installed
in the correct location. If however a custom install script is used,
developers need to adjust their scripts.
Because the "kio/servicemenus" locations is different than the one
KAuthorized allows by default, we have to mark the file as executable.
Task: https://phabricator.kde.org/T14543
This reverts b7fbd19a76 but creates the
widget only once and then reuses it.
However, ownership of a parent-less widget is transferred to the
`KToolTipWidget` but since we first request metadata, then show the
tooltip (or won't if the mouse moved on since), we cannot rely on
the `KToolTipWidget` exclusively.
Instead, when we still delete the widget ourself until we have
shown the `KToolTipWidget` once at which point it will handle the
life time for us.
This fixes parenting the widget to `DolphinView` which would make
it appear as a broken line in the top left of the window.
