| Age | Commit message (Collapse) | Author |
|---|
|
This MR fixes some issues related to RTL scripts:
- wrong layout in Compact View mode
- broken horizontal scrolling in Icon View and Details View modes
- broken navigation with left and right arrow keys in Details View mode
BUG: 484012
BUG: 449493
|
|
|
|
NO_CHANGELOG
|
|
Before starting autoActivationTimer, check that we're hovering the item on top of a directory.
If we don't check for it, the the autoActivationTimer will try to open the hovered item
in it's default application, which can be distracting and break the actual action
the user was trying to do, like moving the file to a directory.
BUG:479960
|
|
This commit adds an animation for folders that makes clear that
they will open or expand soon. This is the case when the option to
open folders during drag operations is enabled and a user drags an
item on top of a folder.
The animation goes like this:
- Replace the folder's icon with the "folder-open" icon
- Go back to the folder's original icon
- Replace the folder's icon with the "folder-open" icon once more
|
|
While using right-to-left languages most of Dolphin is mirrored.
However, the logic of what happens when the arrow keys are pressed to
move between items in the main view was never adapted to account for
that. Basically nothing works as expected because of this. It's more
like dealing with a psychopath who misinterprets every command you give:
Left is right, right is left, up is most of the time right but sometimes
not, down is most the time left but sometimes not.
This commit fixes and adapts the logic if a right-to-left layout is used.
This fully fixes icon view mode and improves compact view mode, though
compact view mode still has more issues which aren't addressed here.
This work for the benefit of the minority that use right-to-left
languages both in Europe and the world is sponsored by NLnet and the
European Commission which I think is beautfiul.
BUG: 453933
|
|
Before this commit, Dolphin's main view would not react to any
context menu events. It only showed context menus based on
hard-coded mouse or keyboard events i.e. mouse right-click and
presses of the "Menu" key.
This commit removes those hard-coded reactions and instead makes it
so the view shows a context menu whenever a QContextMenuEvent is
received. Therefore, a context menu will now be opened when any
platform- or system-specific context menu triggers are invoked e.g.
the Shift+F10 keyboard shortcut.
Aside from this, the only side-effect is a partial removal of an
unrelated bug: Previously, the hover highlight on items was never
cleared when the header column in details view mode was hovered.
With this commit, the hover is now correctly cleared most of the
time.
|
|
As an unintended side-effect of d9a18b04ea0b1b4e427f45083fdc0cdec87cbbfd
items would no longer be selected in icon view mode when the selection
rectangle intersected with the item's icon. This commit fixes this.
|
|
An item, on being scrolled to, is always located at the nearest edge of
the view. This is not always convenient. Allow specifying where the item
should be positioned with respect to the view in scrollToItem().
BUG: 423884
|
|
|
|
Sets a rectangular, non-full-width rubberband as the new default.
User selection is made wherever the rubberband intersects with the row.
|
|
Allow entering selection mode by touching an already selected item.
BUG: 462778
|
|
Use the screen position for a touch event to calculate the start drag distance.
BUG: 464594
|
|
* 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
|
|
CCBUG: 196772
|
|
If a spacebar is used as a keyboard shortcut to activate the Selection Mode, then allow this shortcut to be triggered only if the view has a keyboard focus.
BUG: 465489
|
|
KFileItemModel::supportsDroppin now returns the rootItem when -1 is passed and checks for write access.
|
|
|
|
Before this commit, the "Space" keyboard shortcut was bound to
triggering selection mode by default. After this commit, pressing
"Space" will only trigger selection mode when the file view area
has keyboard focus.
Pros:
+ Other buttons in the UI can be triggered with Space once again
just like it is expected from an accessibility point of view.
+ "Type-ahead" searching works once more when typing the space
char for file names containing such a space char.
Cons:
- "Space" can no longer be used to add the currently underlined
item to the selection. Instead "Ctrl+Space" needs to be used.
(However, this is the current status anyway unless a user has
manually unbound "Space" as a shortcut from Selection Mode.)
- The Selection Mode action will no longer show "Space" as its
shortcut in menus.
Overall, I see solutions to all of these problems, but they seem
over-engineered for the issues they are trying to solve, so I
believe this somewhat small commit is the best solution for now.
BUG: 458282
BUG: 458281
CCBUG: 463048
FIXED-IN: 23.04
|
|
on long touch (and not on mouse press) don't pop up the context menu
anymore but enter selection mode, similar behavior to mobile applications.
the full context menu is still available from the actions toolbar
appearing in selection mode
|
|
|
|
click-and-holding with a pointing device like a mouse.
This functionality was originally implemented because it seemed
useful to save users the effort of entering selection mode
explicitly by using its corresponding action.
However, click-and-holding to trigger anything is not really an
expected behaviour. (This contrasts with touch devices where
press-and-holding is common to trigger something.)
Aside from the above reasoning, the click-and-hold behaviour was
also buggy so that selection mode was entered in a couple of
situations that weren't strictly about click-and-holding.
So this commit removes the functionality and the bugs.
BUG: 457973
BUG: 458129
CCBUG: 457975
|
|
Now uses the same method as for touch long-press detection.
|
|
- Make Esc leave selection mode and have it only clear selection
when already outside selection mode.
- Let translators know that the "More" overflow button should only
have a short text on it.
- Fix a crash that happened when any code tried to exit selection
mode even though selection mode had never been enabled to begin
with.
|
|
Thanks to Steffen Hartleib for the help.
|
|
|
|
- Various code improvements
- Smoother animations
- The bottom bar in General Mode only becomes visible if items are
currently selected
- Removed the selection mode action from the default toolbar since
it can already be toggled in various ways
- More documentation
- Some cleaning
|
|
The selection mode action is a checkable toggle action named
"Select Files and Folders" which has "Space" as the default
shortcut.
In selection mode a bottom bar with contextual actions is shown.
These should mostly mirror the actions which are available through
the right-click context menu aka DolphinContextMenu.
Resizing of the window might make a overflow button appear in the
bottom selection mode bar.
This commit makes press and hold in the view activate selection
mode. This behaviour is not triggered if the press and hold is
used to either start a rubberband selection or a drag operation
within a short time. The length of the short timeframe is defined
by a QStyleHint. This is currently not implemented in touch
because I can't test it.
Mix the selection mode bars' background colors using a nice
combination of colors from the current color scheme
BUG: 427202
|
|
this enables sandboxed application to receive drop events
|
|
Since d3839617193e92463806580699caa595c892b8a6 in details view mode
clicking anywhere within the row is considered a click on the item.
That commit also changed it so that dropping files anywhere inside
a row would make it so the files are received by the folder of that
row.
This commit reverts the drop behaviour to be identical to the old
one.
I am having trouble explaining why this is better because one can
look at it in different ways. Bottom line is that one doesn't
really feel like one is dropping files inside a folder unless the
mouse cursor is actually directly above a folder's icon or name.
Another argument is that it is normal behaviour to just throw files
onto an application and the files then being opened by it.
Having potentially large parts of the view area covered by the rows
of folders means that there has to be more of a conscious effort to
not drop the files inside one of the folders by accident while with
this commit one has to aim precisely onto a folder to do it
intentionally.
CCBUG: 453700
|
|
If one was fast to open the right-click context menu on the row of
an item in details view mode, the hover highlight would persist
while the context menu for the view was open.
This one-liner makes it so the highlight on the row is always
removed before the right-click context menu for the view is opened
so it is as clear as possible that the newly opened context menu
has no relation to the fileItem.
|
|
Before this change, right-clicking the row of an unselected item
in details view mode would be in a weird state:
- It didn't really count as a click on the item because the item
didn't get selected by this click before opening the context
menu.
- It didn't really count as a click on the view background either
because the actions that showed up depended on the item in
that row.
This commit fixes this by considering a right-click in the same row
as an unselected item as a click on the view background.
The behaviour of right-clicking the icon or name of a file directly
is unchanged.
This fixes the following bugs:
- The Paste action that shows up when right-clicking in the
unselected row of a folder now works (instead of doing
nothing). It now pastes the clipboard contents onto the view
background.
- When right-clicking the unselected row of a file (not a folder)
a Paste action once again shows up.
|
|
(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.
|
|
|
|
Since d3839617193e92463806580699caa595c892b8a6 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
|
|
|
|
The itemHovered signal is emitted whenever the mouses moves causing the
tooltip to close.
|
|
Using the gesture recognizer from KWidgetsAddons, so that the source code for the gestures is only in one place
|
|
There is an unintended side-effect in
d3839617193e92463806580699caa595c892b8a6 which this MR fixes.
Normally in Dolphin, when clicking on an item to open/activate it,
it is both selected by the click and opened/activated.
Prior to this MR, the item wasn't selected when all of these
conditions were met:
- Use ActivateItemOnSingleClick also knwon as single-click mode
- Have more than one item selected already
- Click on an item that was previously not selected
Prior to this MR, the click would deselect all items and
activate the clicked item but not select it.
With this MR, the click will deselect all items, activate
the clicked item and also select it and move the anchor there.
When testing this with folders, make sure to navigate back after activating the folder. The folder should then still be selected.
This is then consistent with the behaviour when the specific
conditions mentioned above are not met.
|
|
This commit implements full-row selection and hover highlights for the
details view mode.
This commit also contains fixes for 444680, 444753, both uncovered
during this change.
BUG: 181438
BUG: 444680
BUG: 444753
FIXED-IN: 22.04
|
|
Use `value_or(-1)` for those functions that don't use `std::optional`.
|
|
and more
|
|
When Ctrl can't cause a change in selection, so instead emit `itemMiddleClicked`.
This way one can Ctrl-click a Place or folder in Folders panel to open it in
a new tab, similar to what web browsers.
|
|
|
|
|
|
Right now the back/foward mouse buttons work, but also if you hold either
of them and move the mouse the rubberband selection is triggered.
This is the correct fix (instead of commit d0c71a1435bc9d), to match the
original code before the touch events patches, we need to check the
back/foward buttons after mouseButtonPressed is emitted and before
triggering the rubberbad selection.
|
|
|
|
This Patch works for Wayland and X.
BUG: 426582
|
|
We need to emit mouseButtonPressed (now in the onPress method) before the
check needed to not select items on back/foward mouse button press events.
|
|
With this patch dolphin now supports the following touch gestures:
* Tap gesture to interact/open with directories, files and so on
* TapAndHold and release gesture for access to the context menu (main window, panel folder, places and information)
* TapAndHold and moving gesture for drag and drop action (main windows, panel folder and places)
* pinch gesture for zoom in main window
* kinetic scrolling (QScroller) for main window, panel folder, panel places, panel information, setting preview and service
* two fingers swipe gesture to left, right and up as shortcut to navigate back, forward and up
* two finger tap gesture to toggle item selection, similar to Ctrl and left mouse click
FEATURE: 385066
FIXED-IN: 20.11.80
You are currently rebasing branch 'touch' on '85241a924'.
|
