I don't know why, but i already have this by default in my Dolphin... (ArchLinux user here, i don't think they add it explicitly as they try to stay as true to upstream as possible).
So, err, don't know why.

It makes sense to me now. Thank you for elaborating on the timer.

In D11204#233997, @dfaure wrote:

Thanks !

Do you have a contributor account for pushing the commit, or do you need someone else to do it?

Ping.

I wonder if the fix is really fixing an issue here or just masking it?
You're not setting the style if it's already set. That indicates something somewhere tries to set it when it was already set and that something should not do that.

In D11245#226542, @michaelh wrote:

There's more to consider. With D10803 coming up tooltips may be overwhelmed with info when they continue to follow the settings in baloofileinformationrc. In the long run we'll probably need separate settings for tooltips and infopanel. baloo-widgets has to offer that option of course. (I'm willing to adapt it)

In D11354#226546, @rominf wrote:

OK, the main problem from your comments is that it's enabled by default. I followed the example of Okular with it's hjkl keys for movements (those keys are enabled by default, you can test it).

But it's not a big deal, I can make it an option that's disabled by default.

@mmustac OK, it indeed breaks select-as-you-type feature. As a workaround, it's possible to use / to invoke a filter panel.

In D11354#226530, @markg wrote:

I'm also not sure if this would be accepted. Not every feature request should be implemented.
Things like this would be perfectly suited for a plugin, too bad Dolphin has no plugin support ;)

Kate and Okular have a plugin system, although they have vi-mode builtin. What's wrong with having a functionality what's disabled by default?

In D11354#226534, @ngraham wrote:

I'm also not even sure how much sense this makes conceptually. vi is a text editor; Dolphin is a file manager. The concepts don't really mesh very well.

From a vi user perspective, vi-mode make sense in any application. See those two lists.
As for file managers, look at ranger. It's one of the most popular console file managers.

So, will you accept this if I make it optional and disabled by default?

-1 as is.
It's not a "mode" as you currently implemented it. It's a "always on" thingy.
It should be behind a switch somewhere and off by default.

@elvisangelaccio do you have more for this?

In D11245#226020, @ngraham wrote:

In D11245#225997, @markg wrote:

In D11245#224414, @ngraham wrote:

I think having it in the context menu makes enough sense; the toggle for the preview is already there, so there's already precedent for having the Information Panel's UI be controlled via context menu. +1.

@broulik and I seem to think that it should be in the settings, not under the RMB.
To be fair, i'm trusting your judgement so i'm fine either way, but i'm "leaning" towards in the settings as well.

If we go down that path, I would argue that it makes sense to relocate the [ ] preview checkbox that's currently in the context menu to that window as well for consistency's sake. I'd be fine with it as long as we do that to maintain consistency.

I did a clean rebuild as well, now it works.
Just one more question about a change i don't get.

In D11245#224414, @ngraham wrote:

I think having it in the context menu makes enough sense; the toggle for the preview is already there, so there's already precedent for having the Information Panel's UI be controlled via context menu. +1.

@dfaure I've been looking over the file.cpp and file_unix.cpp code a bit and i'm rather surprised that UDS_HIDDEN isn't being set at all here. Which makes me wonder, why is the hidden logic missing and how is it working now?
I don't know for the "why", i'm hoping you can share some insight on this?
I do know for the "how"; "KFileItem::isHidden()" is taking care of that. It checks the first character for a dot and returns true if it does (thus hidden for any app that uses KFileItem).

Why directly in the RMB menu?
It's not like users will often do that (i think).
Is there a reason for it not to be in the settings for that panel?

In D10804#223410, @rominf wrote:

In D10804#223394, @markg wrote:

@rominf if i restore from within the trash (trash is empty after restoring), the trash icon in the places menu and the "Empty Trash" button both stay active.
Could you take a look at that?

It works for me. Can you check it again (I rebased this on master).

@rominf if i restore from within the trash (trash is empty after restoring), the trash icon in the places menu and the "Empty Trash" button both stay active.
Could you take a look at that?

Large review!
I was going to give a ship it till i compile tested it. It failed!
You can find the output here: https://p.sc2.nl/HJDBOJmtM

In D10804#223339, @rkflx wrote:

No time to test in-depth right now, but UI-wise I like it now, so +1.

(Still even after a very brief test run, something is still off, not sure which Diff this belongs to: Restore everything, button is still enabled while it should be disabled as the trash is empty now.)

+1, finally :)
Nice job, @rominf!

I just tried it, works neatly.
It also looks kinda fancy (even though it was not my first choice of having it next to the urlbar, it looks nice)

@elvisangelaccio with your suggestions the generic methods are basically handled like if it were a namespace.
The only reason for the class to exist now is because of the signal in there.

Please do the next patch in a way that we can actually see what's happening, that's for D11216. I'd recommend following what @rkflx said for followup patches.

I think it gets complicated now.
This patch and D11216 are now both not correct anymore (they are both the same, both do too much).

-2 in my opinion.
KFileItem should know nothing about NTFS.

As Plasma itself depends on Qt 5.9, having Qt 5.8 in here as minimum is perfectly fine :)
It looks OK to me. Push it.

In D11012#222620, @rkflx wrote:

In D11012#222615, @markg wrote:

I think that's about it though. I have no further requests, the code looks OK to me (i did not test it).

Uh oh, testing is sometimes kinda important ;)

After this last comment it's a +1 from me.

Note that you can "resign" if you don't want to "accept" after "requesting changes", so arc land won't block.

I do prefer if someone else also gives a +1 before you push it. @rkflx perhaps?

Sorry, I'm currently not available for in-depth code review in Dolphin, only some random UI comments in-between…

or @elvisangelaccio

I think that's about it though. I have no further requests, the code looks OK to me (i did not test it).
After this last comment it's a +1 from me.
I do prefer if someone else also gives a +1 before you push it. @rkflx perhaps?

Isn't this better suited for KCoreAddons?

In D10832#218767, @rominf wrote:

What about this diff? Will this be accepted if I revert all enums that require static_cast?

As you now also have D11012, please clean this commit up.
This one should only add the button now (and handle it), not add the class with it's helpers.

Now it makes more sense.
Careful with arc ;)

-1 this is totally unrelated. For future reference, i see new functions being added (setFocus and hasFocus and the addition of an action.

Could you not do this please?
The revision i reviewed was a lot different then the one that's up now. You even fix different things compared to what i first saw.
This should have been a new review i think, not an update.

In D10742#218171, @dfaure wrote:

Can someone explain to me how switching from pointers to values is making anything faster, or is a first step towards making anything faster? This step in itself can only make things slower due to more "copying" (refcount updating).

In D10985#217573, @rominf wrote:

In D10985#217572, @markg wrote:

In D10985#217567, @rominf wrote:

Can somebody land it for me? I have some problems:

$ arc land
Landing current branch 'remove-unused-includes'.
 TARGET  Landing onto "master", the default target under git.
 REMOTE  Using remote "origin", the default remote under git.
 FETCH  Fetching origin/master...
Usage Exception: There are no commits on "remove-unused-includes" which are not already present on the target.

In D10985#217571, @elvisangelaccio wrote:

In D10985#217567, @rominf wrote:

Can somebody land it for me? I have some problems:

$ arc land
Landing current branch 'remove-unused-includes'.
 TARGET  Landing onto "master", the default target under git.
 REMOTE  Using remote "origin", the default remote under git.
 FETCH  Fetching origin/master...
Usage Exception: There are no commits on "remove-unused-includes" which are not already present on the target.

It looks like you already pushed it? https://cgit.kde.org/dolphin.git/commit/?id=848abc5922167a467bb73107ee6b72e9af3c8317

Exactly what i was going to type :)

Well. I don't know how did that happen. Maybe I was unconscious.

In other words, how to close this diff?

In D10985#217567, @rominf wrote:

Can somebody land it for me? I have some problems:

$ arc land
Landing current branch 'remove-unused-includes'.
 TARGET  Landing onto "master", the default target under git.
 REMOTE  Using remote "origin", the default remote under git.
 FETCH  Fetching origin/master...
Usage Exception: There are no commits on "remove-unused-includes" which are not already present on the target.

In D10990#217446, @rominf wrote:

In D10990#217438, @markg wrote:

I'm not so sure if this is a feature worth having.
Dolphin also works under windows, it doesn't know symlinks (something like it, yes, but it's not a symlink as it is under linux).

Also, is it worth exposing that technical detail (symlink is quite technical) to the user?
Is a good solid reason for having this? Or would this just satisfy a edge case used by very few people (if ever)?

Suppose I have file A and symlink B -> A. I want to copy file A to the FAT formatted flash drive using symlink B. I get an error because FAT doesn't support symlinks. Ooops... Leaked abstraction.

I'm not so sure if this is a feature worth having.
Dolphin also works under windows, it doesn't know symlinks (something like it, yes, but it's not a symlink as it is under linux).

This is really great! Nobody every cleans up unused includes because it's tedious i suppose.
But having this done is just awesome, good work!

Ha, funny. I didn't even know there was an old syntax for this. I've always used the + syntax.
I ran it and it seems to be working just fine (just tested a few shortcuts, not all).

I've updated the description. I'm not entirely sure if this is how i should update it (never played with phabricator tasks before). Everything i added is obviously after the "Addition by @markg".
And added @ngraham for input :)

Looks fine, nice to have :)
Feel free to ship it without updating the review for that one little pointer position change.

In D10804#216635, @rominf wrote:

In D10804#216484, @markg wrote:

Is the singleton class really needed? It imho seems a bit overkill for merely the trash status.
On the other hand, it does neatly move some trash functionality in it's own little space. But a class?..
The functions are also all self contained so it might be better suited in it's own namespace (say a TrashHelper::<youFunctions>).

Yep, a singleton is needed, though I don't like it too. I have a signal to emit. That means I have to have QObject. Nobody can emit signals from static functions, hence I need a singleton.

In D10857#216725, @dfaure wrote:

I cannot confirm that stable_sort is faster, on the contrary. http://www.davidfaure.fr/2018/qsort_performance.cpp updated, says (repeatedly)
"std::sort took: 5003 ms"
"std::stable_sort took: 7490 ms"

Maybe on specific data (the actual filenames you're testing this with), stable_sort ends up being faster, but this isn't true in general (with random data).

Is the singleton class really needed? It imho seems a bit overkill for merely the trash status.
On the other hand, it does neatly move some trash functionality in it's own little space. But a class?..
The functions are also all self contained so it might be better suited in it's own namespace (say a TrashHelper::<youFunctions>).
Also, don't forget the const correctness. All you functions are const functions (they don't change class members).

In D10804#215803, @rkflx wrote:

Maybe, but your code does not work all that reliably either. I think the best approach is to fix the bug, and then handle the trash state uniformly in Dolphin's existing code as well as your patch.

@markg Any pointers to help fixing the bug?

+1, but wait till someone else had a look as well.

@ngraham would it be acceptable to have a "bar" above the trash exactly as Finder shows it?
Imho it would be a bit redundant as the breadcrumb bar also shows it, but it looks a lot better.

In D10857#214867, @jtamate wrote:

In D10857#214607, @dfaure wrote:

I'm not opposed to the idea, but measuring CPU usage is a rather misleading indicator. What if it takes 10 times longer, because it's progressing much more slowly? ;)

Please at least measure with QElapsedTimer around the sorting (not to be committed, just to gather numbers about the actual performance of this from a user's point of view).
I'm interested in the result ;)

The results are strange. All the results are measured sorting 50.000 small files:

Both Qt are the same version from opensuse.

In an i5, why the difference is so big? recent cpu bugs?
qSort in i3
274764, 276060 (with 3 directories), 365878, 424506 (without directories)
std::sort in i3
940, 995 (with 3 directories), 2472, 2539 (without directories)

In AMD the results are closer, qSort wins
qSort in AMD
658, 726, 695, 683, 676, 666, 649, 684, 666 (without directories)
std:sort in AMD
843, 839, 878, 896, 925 (without directories)

+1, also for what @apol said.

I seem to be making a mess of this commit. Sorry for that.
https://p.sc2.nl/B13Etcldf with the changes.

In D10702#213845, @dfaure wrote:

"unlink() in most of the modern filesystems is not affected by the size of the file" doesn't match my experience, I have seen konqueror/dolphin freeze for 10s while deleting a 8GB file (on a somewhat old system, no SSD). And that would actually be the reason for this patch to go in. But on the other hand, I have a hard time believing that this patch doesn't make things slower for the case of many small files, due to the communication overhead with the kioslave (and that's the reason I wrote this code in the first place).

Maybe the right solution is to use QFile::remove if the file is small, and use the kioslave if the file is big. But finding the file size in the first place takes a little bit of time too :-)

In D10832#213675, @elvisangelaccio wrote:

Thanks for the patch.

I agree we should use enum class for new code, I'm not sure it's worth porting to old enums though.
The problem is that this diff is huge and it will make git blame harder to use, for little gain.
@markg @rkflx toughts?

That said, if we really want to do it, please get rid of those static_casts where possible, they will only reduce the readability of the code.

In D10702#212753, @meven wrote:

In D10702#211236, @markg wrote:

While this might give you the expected result, it feels like a workaround.

I'm assuming the fast path is there for a reason and is really substantially faster then going through the job route.
If that is the case then the proper fix would be to make that code part async. That is obviously much more complex (otherwise it would've been done already).
Think of using std::async and a QEventLoop. Sounds difficult, right? It is :) But I've been playing with that kind of stuff lately so i'm happy to share an example that you can use as a starting point.
Here it is: https://p.sc2.nl/BygE-Oiwz

I wanted to paste it inline, but that already got quite big so a link it is.
I've added a bunch of comments in the code to explains what it's doing.
Note that the example does make a "QEventLoop", you should not do that within the if statement, but rather outside the while loop and simply call exec() and quit() every time (not making a new QEventLoop for every delete)

Lastly, please benchmark this fast pats (as it currently is) compared to your KIO version and my async version to see if the fast path really is the fast path. As we just don't know and that kinda influences which route to choose here.

Please correct if I am wrong but kio::file_delete will, in the end, calls FileProtocol::deleteRecursive(const QString &path) which works the same way using QFile::remove as before.
So I have the hypothesis that they should not be much difference in performance if any.

It could be impactful because of the KIO::file_delete call and I don't know precisely how expensive such a kio call is.
Or because they are more jobs class instanciated.
But those KIO::file_* calls are already used in a lot of cases in CopyJobPrivate::copyNextFile for instance to recursively copy files, so I know that at least in some cases it is ok.

Please correct me wherever I am wrong I am new in the KIO codebase. I am learning as I go.

The main drawback in this version of the patch currently, is that we loose progressive status update when a lot of files are being removed (slotReport was called each 300 deletion before).
And since needs to be fixed this at least.

Looks good to me.

I unfortunately have no clue how to answer your questions.

While this might give you the expected result, it feels like a workaround.

@bcooksley Ah, i see you just fixed this by using kiotesthelper.h (which includes kioglobal_p.h).
According to Jenkins, all is OK now :)

In D10414#208515, @bcooksley wrote:

Looks like QT_LSTAT doesn't exist on Windows - see https://git.reviewboard.kde.org/r/127727/

In D10617#208703, @elvisangelaccio wrote:

In D10617#208513, @ngraham wrote:

The shortcut won't affect other apps since the file dialog its its own context. Even if the host app uses F12 for something, the file dialog will grab the key first, so there's no "ambiguous shortcut" issue.

Yes, you won't get the ambiguous shortcut dialog but it'd be a bad idea to use F12 for two different things within the same app (the file dialog is part of the app).

Right, it didn't fix it... https://build.kde.org/job/Frameworks%20kio%20kf5-qt5%20WindowsMSVCQt5.9/195/console
Could someone with a windows setup (compiler and kio) compile kio and tell me what is wrong here?

Right, this one is my fault: https://build.kde.org/job/Frameworks%20kio%20kf5-qt5%20WindowsMSVCQt5.9/193/
Weird that QT_LSTAT is no problem on linux without including qplatformdefs.h, on windows it apparently is.
I pushed the fix: https://cgit.kde.org/kio.git/commit/?id=11051f3709cdc651a68990a9c17a69c33d5812db

Add @since lines where for the move assignment operator and constructor.
Typo fix.

Fine by me.
I do wonder why it used to be in an if statement though. It would have added a nullptr if the "if (showHidden)" check failed (which would fail when it's a nullptr).

Looks good to me.

As this is a no-go, rightfully so! Abandoning it.

@dfaure What's your preference here?
I do "want" to work on this, no promises though. It could take a very long while ;)

Ahh, will fix that when i get home.
I missed the @since lines in KFileITem as well. Is it OK if i just add them outside of phabricator? They will get an "@since 5.43" i think.

I'm not afraid of the compiler generating wrong code. That is the least of my worries :)
What i am afraid of (which is why i suggested the copy test) is a wrong optimization at some point (like adding a pointer member but forgetting to properly copy it) which would break the UDSEntry.
But a test for that would probably deserves its own review independent of this.

Fix a typo and replace QCOMPARE with QVERIFY for the file open check.

In D10437#204416, @chinmoyr wrote:

In D10437#204402, @markg wrote:

I just tried this:
kdesu gwenview (type root password and go to the root homefolder).
In gwenview i can now go to that folder.
In dolphin (started as user, not root) i can't get into that folder.

I don't really see what you try to fix here as it seems to be working just fine here.
Or i don't understand it.. In that case, please provide reproducible steps.

Currently file ioslave does not support reading contents of a locked(is this the right word?) folder. So no file operations are possible.

I just tried this:
kdesu gwenview (type root password and go to the root homefolder).
In gwenview i can now go to that folder.
In dolphin (started as user, not root) i can't get into that folder.

@dfaure i can make the test much more complete if you want.. But it's more complex thus i left it out.
I can store the UDSEntry in a QDataStream which would be backed by a QByteArray. That can be hashed!
Then i can do the same after moving operations and compare the hash. That way i would know for sure the UDSEntry objects match perfectly.

Seems my unittest skills have become a bit rusty over the years of basically not contributing patches to KDE ;)
Thank you for the comments, David!

Update test.

Remove comment about compiler generated functions.

Just a note.
The fact that currently no code is structured in a way that move semantics are used is... slightly annoying ;)
No as in not when running dolphin with it and profiling it to see UDSEntry uses. There "might" be code that uses move semantics when this patch is applied, but i haven't seen it yet.

Fix indentation.