Can confirm. Also, I'd make the tap and hold indicator a bit smaller, maybe half of the size it currently has :-)

I want to see the indicator under my finger, at the current size I can almost see it (maybe my fingers are too thick)

Landed in release/20.04
https://invent.kde.org/system/dolphin/commit/99cf24c03def1c0722ba8dbd86a27b9dbc521f43
And synched in master:
https://invent.kde.org/system/dolphin/commit/a058c64eba30f11bfa87ac097371c04437d0471e

@meven Yes please. The patch may be small, but it's not trivial. Smaller atomic changes are always easier to review.

Very nice. Please push to release/20.04. Thanks!

fix indentation

Thanks, it applies now. Everything works great, except that the two-finger swipe gestures aren't recognized for me either.

I wonder if it would be better to use a single-finger swipe for navigation, and require a very fast motion, like a flick rather than a tap-and-drag, to differentiate it from a horizontal scroll in horizontally scrollable views. What do you think?

I don't think it will work, because Qscroller uses a flick to do an autoscroll very quickly, so the problem is to be distinguished: the user wants to scroll quickly or wants to swipe.

Please update the text of the revision and the commit message, as they don't make much sense. Please mention that it fixes a crash in case ddjvu is not installed, by avoiding executing it, and using _exit() to not run atexit handlers in case execvp() fails.

Review feedback

Thanks @pino

This change is definitely not correct.

Avoid displaying the extension if it represents more than a third of available space

Yeah, I feel bad about this. Nobody liked the change and I feel like I can understand the complaints. This looks like a better solution to me. Nicely done!

Can confirm. Also, I'd make the tap and hold indicator a bit smaller, maybe half of the size it currently has :-)

Improve function naming

Clean up

We would need a custom elideText function to solve https://bugs.kde.org/show_bug.cgi?id=404955
Original Qt function :
https://code.woboq.org/qt5/qtbase/src/gui/text/qtextengine.cpp.html#_ZNK11QTextEngine10elidedTextEN2Qt13TextElideModeERK6QFixediii

I'm seeing that the touch-and-hold indicator sometimes gets stuck:

Thanks, it applies now. Everything works great, except that the two-finger swipe gestures aren't recognized for me either.

In D29488#671753, @nikolaik wrote:

In D29488#671698, @meven wrote:

Commit message should be updated with latest changes.

Ready to land.

In D29488#671698, @meven wrote:

Commit message should be updated with latest changes.

• rebase
• add a TapAndHold indicator, to give the user a visual feedback for a successful TapAndHold gesture
• tweak swipe gesture recogniser

Commit message should be updated with latest changes.

Update in response to review.

Update in response to review comments.

Thank you!

Done :)

• Renaming of functions

Actually sorry, I have a few more comments before I think this can land:

Thanks!

In D29006#671172, @ngraham wrote:

Nice feature. I would rename the menu items a bit:
"Move to inactive split view"
"Copy to inactive split view"

No need to mention "the selection" because it's implicit. And I would mention that this is about the split view, or else when not using the split view feature, it's not clear how to enable the menu items. If you mention splits in the name though, it's advertising the split view feature for whose who haven't found it yet.

• Minor renaming of text and the according variables
• Merge remote-tracking branch 'origin' into arcpatch-D29006

Nice feature. I would rename the menu items a bit:
"Move to inactive split view"
"Copy to inactive split view"

two fingers swipe gesture to left, right and up as shortcut to navigate back, forward and up

In D29634#670485, @feverfew wrote:

In D29634#670419, @meven wrote:

In D29634#670377, @ngraham wrote:

Nice work.

In D29634#670159, @feverfew wrote:

I imagine something similar should be done for FileJob::write?

Yeah.

I guess you meant FileProtocol::write.
There is no need there, it uses QIODevice::write directly.

Sorry, I meant kio_sftp's implementation of this: https://api.kde.org/frameworks/kio/html/classKIO_1_1FileJob.html#a481871536fb9471ccb64929792f31165

In D29006#670660, @meven wrote:

Rather than merging master into your branches, I would recommend you rebasing ;)

thanks for testing this patch.

Rather than merging master into your branches, I would recommend you rebasing ;)

Looks like this needs a rebase.

Everything works for me, except two finger gestures

In D29634#670419, @meven wrote:

In D29634#670377, @ngraham wrote:

Nice work.

In D29634#670159, @feverfew wrote:

I imagine something similar should be done for FileJob::write?

Yeah.

I guess you meant FileProtocol::write.
There is no need there, it uses QIODevice::write directly.

In D29634#670377, @ngraham wrote:

Nice work.

In D29634#670159, @feverfew wrote:

I imagine something similar should be done for FileJob::write?

Yeah.

Nice work.

In D29562#670167, @feverfew wrote:

Hmmmm, this looks like a poor man's priority queue, would std::priority_queue not be appropriate here? (I'm not blocking here, idm tbh but it just seems more natural here to me). Also means that you don't have to explicitly enforce it all the time the queues are used, the priority is decided only in one place.

In D29213#670124, @ngraham wrote:

+1, though I see a brief flicker of the widget when I switch between two views where it's hidden, such as recentlyused:/files/ and recentlyused:/locations/ can you reproduce?

Hmmmm, this looks like a poor man's priority queue, would std::priority_queue not be appropriate here? (I'm not blocking here, idm tbh but it just seems more natural here to me). Also means that you don't have to explicitly enforce it all the time the queues are used, the priority is decided only in one place.

I imagine something similar should be done for FileJob::write?

+1, though I see a brief flicker of the widget when I switch between two views where it's hidden, such as recentlyused:/files/ and recentlyused:/locations/ can you reproduce?

Personally I don't really see the need.

You do seem to calculate the deviceWidth and height an awful lot, it makes reading a bit clunky. I'd much rather have the multiplication done once and then always use the var instead. In fact, perhaps it'd make sense to have createV3 feed the values into the implementations? Currently they all repate the same two lines over and over.

• rejigger write segmentation into new sftpWrite function used by both the put() and write()
• fix length calculation
• refine buf size comment

Well apart from the length of data needed to be reduced as we progress, all this makes sense.

Hide spaceBarSpaceInfo when size is unknwown

• Renamed to destinationUrl

Update in response to review.

In D29562#669044, @elvisangelaccio wrote:

Use QVector instead of QQueue to avoid adding to the queue twice the same dir for subsequent scanning.

Add a priority queue for path that were not already present in cache.

Can you split these two things into different commits? Or are they related?

In D29213#669068, @ngraham wrote:

Sounds to me like we should just hide the widget entirely when there's no size available, or a size calculation doesn't make sense given the context.

Sounds to me like we should just hide the widget entirely when there's no size available, or a size calculation doesn't make sense given the context.

• Merge branch 'master' of https://anongit.kde.org/dolphin into arcpatch-D29006
• Merge branch 'master' of https://anongit.kde.org/dolphin into arcpatch-D29006
• Rename to (copy|move)SelectedItems

Use QVector instead of QQueue to avoid adding to the queue twice the same dir for subsequent scanning.

Add a priority queue for path that were not already present in cache.