Based on the comment you made in D10380 it's logical that this commit won't make it as it currently is implemented.
The using line is probably also not the best option if you want to keep the convenience functions, inheriting would be better. But then again, inheriting from an std container gives it's own issues (like no virtual destructor...)

In D10341#202720, @markg wrote:

In D10341#202704, @dfaure wrote:

I like the idea of enabling moves for KFileItem very much.

But here's a fun fact: your unittest passes even without the rest of the patch.

PASS   : KFileItemTest::testMove()

That's because std::move() doesn't move, it only makes the argument eligible for e.g. a move ctor, but will call a copy ctor if there's no move ctor. So that test is not really testing that move works ;)
That's always a bit tricky to test, I guess, because one can't really rely on the state of the moved-from object to be anything in particular. And we want =default, not to implement some counters in there.
Oh well, then maybe there's no real way to unittest that moving works.

I know, i - somewhat - mentioned it ;)
"New test for move semantics (it passes, would probably pass without as well but just be a copy)."

The test might be rather pointless as is, but running that test though callgrind does show move semantics which is why i added it.
Do i just remove it?

Anyhow, the thing I'm wondering is the following: does the rule-of-zero lead to more opportunities for optimizations by the compiler, who can see "from the outside" that the 5 special members are the default generated ones, while your patch "hides" the implementation, lowering the visibility for the compiler in the rest of the code? Well, one could just move the 5 "=default" to the header to fix that.

There was an issue with that... I don't quite remember what it was. Let me try again... (to be continued)

• continued --

It doesn't compile...
I don't know why or how to fix it, you might :)
This is the message:

Get rid of the temp file.

In D10341#202704, @dfaure wrote:

I like the idea of enabling moves for KFileItem very much.

But here's a fun fact: your unittest passes even without the rest of the patch.

PASS   : KFileItemTest::testMove()

That's because std::move() doesn't move, it only makes the argument eligible for e.g. a move ctor, but will call a copy ctor if there's no move ctor. So that test is not really testing that move works ;)
That's always a bit tricky to test, I guess, because one can't really rely on the state of the moved-from object to be anything in particular. And we want =default, not to implement some counters in there.
Oh well, then maybe there's no real way to unittest that moving works.

In D10325#201884, @broulik wrote:

Would it be possible to show it as if it were locked? That would solve all the issues with it, right?

I don't get it. That "lock" feature is entirely a Dolphin invention. It does exactly what I do here:

void DolphinDockWidget::setLocked(bool lock)
{
    ...
        if (lock) {
            ...
            setTitleBarWidget(m_dockTitleBar);
            setFeatures(QDockWidget::NoDockWidgetFeatures);

with m_dockTitleBar being a custom widget for some added padding

Why does it show the panel as if it were unlocked?
Your before image looks exactly like an unlocked frame in Dolphin.

Hmm, weird. In my eyes the knovi thumbnail in the before image looks sharper than the after one. It's just blurred in the after one, not better.
I'm guessing the QML smooth property has a fairly naive implementation (in Qt).

In D10314#201419, @ngraham wrote:

Fixed it!

Changing Dolphin to Alt-P would open a can of worms since the other panels are triggered with Function keys, so I think F11 makes sense here.

In D10314#201388, @ngraham wrote:

I use F11 to be consistent with Dolphin, where F11 toggles the information panel. It's not exactly the same thing, but I figured re-using existing KDE muscle memory was worthwhile. Alt-P could work too though, and would probably conflict less. Easier to type on a laptop with shared function keys, too.

Any ideas on the "ambiguous shortcut" issue?

Makes sense imho.

+1 for the idea, just a question about the key.
Windows uses ALT+P: https://lifehacker.com/5811238/quickly-show-the-preview-pane-in-windows-7-with-alt-%252B-p
I don't know what Finder uses, you can probably tell ;)

Please add a comment to the code for that.
It might be obvious now, but the next person that looks at that code without knowledge of this change probably has a "huh, what is that?" moment and left wondering why it's done.

In D10288#200610, @dfaure wrote:

When you measure the number of calls to the copy constructor, is that with a Debug build or a RelWithDebInfo build? The latter optimizes out a large number of calls to the copy ctor, so counting this on a debug build is a rather wrong measure.

+1 from me.
Don't ship it yet though. Wait for at least @elvisangelaccio for his opinion about it.

• Revert change to CMakeLists.txt

You already have all the information you need. It's just incomplete when it arrives in DragAndDropHelper::dropUrls.

I don't see why you use a QCache as you're not using any of it's features.
If you want to maintain a mapping of QUrl -> bool, just use a QHash.
I think maintaining a QUrl -> bool mapping is fine. What i did in my patch (only a bool) could have been an issue if you for whatever magical reason have a drag enter event with a different url without first receiving a drag close event - aka corner cases.

Looks OK to me.
Had to read up on the KDE urls and local urls first though :)

https://p.sc2.nl/S1yjzuGUz (hacked together, test thoroughly please)
Down to 5000 aka, the base testcase, it cannot go down further :) (did i just make it ~8 times faster? hehe)
And i'm using the QDropEvent isAccepted function now to prevent another call to urlListMatchesUrl.

@jtamate how about this patch: https://p.sc2.nl/HyrIiwfIG
The rationale behind it is as follows. If a paste is allowed is checked upon drag enter and upon hovering a different folder within the drag. That value is stored in a bool.
Upon drag leave the value is always reset to false.

@jtamate, you are trying to make this faster, which is awesome! But i think there is another issue. I just tried to benchmark this as well with a folder of 5000 empty files.
Within DragAndDropHelper::urlListMatchesUrl i see 40.007 calls to QUrl::matches. That smells weird.
Sure, there are probably some extra urls's (don't know where they come from), but that could explain the last 7. But the remaining 40.000 is 8x as much as the number of items that are being dragged. That's wrong!
Note that this is merely with one drag/drop.

Ha, funny. I would say +1 :)
Your idea is good and the default user places could imho be more then what is there by default right now.

In D7700#198179, @ngraham wrote:

FWIW I'm still in favor of putting this in the Places panel via KIO, especially now that we have support for showing and hiding categories. If we make this its own new panel, I'd want to push for adding it to the default layout in Dolphin, or else nobody will ever see it and the work will be wasted.

See previous message (i don't know why phabricator immediately marked it as accepted when re-opening).

I think this commit broke a test.
https://build.kde.org/job/Applications%20dolphin%20kf5-qt5%20SUSEQt5.9/17/testReport/(root)/TestSuite/placesitemmodeltest/

I very much like it!
I among others tried to fix this as can be seen in issue #198175 but gave up due to the wildly different corner cases that would make a small change really complicated.

Ship it from my side.

In D9824#191929, @rjvbb wrote:

I am going to assume you would have said so by now if the fix is not applicable to the QFSW backend because it doesn't do the same costly walk.

> So please MAKE your PATCH TOUCH the QFSW backend AND MEASURE THE IMPACT ON ITS PERFORMANCE

I don't care a rat's ass if that is done in a separate patch or in this one, it just has to be done.

Note: i do think that you need to get an opinion from the Dolphin maintainer before pushing regardless of who else gives a +1 as this change could potentially be quite invasive and is going to change the default look (thumbnails be default).

In D7440#165020, @ngraham wrote:

That was my thought too, but @markg and @anthonyfieroni weren't too keen on all the duplicated code, and it does allow us to centralize the kconfig part rather than duplicating it three times.

Lovely! Less code, more features, those are the cool changes :)
I think it's safe to push.

Ohhh! Nice addition!
+1 for the idea. Code looks OK in my opinion.
Don't push it right away, wait at least a few days or till someone else also gives a +1.

I resign (for now), i need to retest this.
Sars brought up a very valid point that i didn't even consider yet. You do introduce some hybrid between single- and double click flows while potentially breaking current flows.

I have my doubts for this one. The same block of code is now duplicated 4 times.. 3x in Dolphin, 1x in KIO.
Why not wait? Getting this in is not *that* important.. On the other hand i do get that waiting half a year (for applications 18.04) also seems excessively long which is why i understand the workaround.

In D7647#156787, @akrutzler wrote:

In D7647#156773, @markg wrote:

In D7647#156686, @ngraham wrote:

@elvisangelaccio and @markg, how's this looking now?

I don't see the suggested changes so a +1 is a bit premature.

I set all comments to "Done" where I know they are done. There are still some left with no further comments from you guys, so they are done too?

At the very least - regardless of my previous comment - you'd also have to raise the minimum required frameworks version in Dolphin' CMakeLists.txt.
It's the line: set(KF5_MIN_VERSION "5.37.0") which has to be changed to set(KF5_MIN_VERSION "5.40.0").

In D7440#157543, @ngraham wrote:

With dependencies now merged, I think this is ready once more for the firing squad errr I mean review process. :)

Please do make sure (just as a test before you push this) that the default plugins (which now is all except for the text plugin if i recall correctly) are enabled in Dolphin' settings (General -> Previews).

In D8243#157346, @renatoo wrote:

In D8243#157336, @markg wrote:

We have such a nice modular design with panels yet we keep cramming everything in the places panel... Why?
It's not just here, I've seen patches like this for Dolphin as well.

Imho, the places panel should only contain the top places - favorites if you will - that you might want to access quickly. Nothing else and should stay small.
Baloo -> new panel
Devices -> new panel
Remote devices -> Either in Devices or a new panel as well
etc..

Having more panels will give a whole different issues. Scrolling. Since each panel would be relatively small if you add many you will get scrollbars within the panels. Well, lets just get rid of the per panel scrollbar and merely have one for the whole "panel container" (like in macOS finder).

Just my 5 cents...

@markg, I never used macOs finder, but looking at the internet images. This is exactly what I am proposing and what we have on dolphin today. A single list with only one scrollbar split in sections.

I am just trying to keep the same visuals on both (dolphin and file dialog) to avoid confusion for users,  they can get lost if you show different information.

Our final idea is that you will be able to hide sections that you do not want, For example the local devices and network.

We have such a nice modular design with panels yet we keep cramming everything in the places panel... Why?
It's not just here, I've seen patches like this for Dolphin as well.

In D8347#156930, @ngraham wrote:

I still need to add a @since in the header documentation, after which point hopefully @markg will approve. :)

In D7647#156686, @ngraham wrote:

@elvisangelaccio and @markg, how's this looking now?

-1 for the idea as is.

I'm a bit skeptical about this function...
It in fact is all plugins minus (in this case) the text thumbnail with no way to configure it afterwards.
That means a updates blacklist can only be distributed in a new kio release.

I still prefer the old one over the new one.
-1.

In D8303#155858, @ngraham wrote:

Honestly I think it's fine the way it is: in the details view, we have a nice compact string that doesn't make the column too wide, and in the Information Panel, we have a longer string that provides more information and isn't too big since text can wrap there.

I do see your point though, and I agree that the long string should be customizable in some way for people who prefer a shorter string. But that seems out of scope for this change; can we stick to this change here, and discuss that other change (which I do approve of:) ) in another patch or bug report?

In D8303#155840, @ngraham wrote:

@markg I actually like the current verbose format. That's somewhat unrelated to this; can we track that change, if any, with a new patch?

I'm OK with this feature after the code is correct.
So with probably my suggestion and those of @elvisangelaccio

+1 for having this property
-1 for the current rather verbose date format. Look at the "Modified" column in the any dolphin details view. It (on my setup) just shows a date and a HH:MM timestamp. That would be enough information, right?

In D7446#154720, @ngraham wrote:

That said, it's not just me who wants this in Dolphin, too. There's a Bugzilla ticket with one dupe and 32 votes: https://bugs.kde.org/show_bug.cgi?id=357542

Also, we have a semi-functional version of this already in the form of the Places panel's Recently Saved section. So there does seem to be some interest, both historical and current, in having Dolphin show recent files by default.

In D7446#154617, @ngraham wrote:

@markg, I strongly disagree that "recent files" are not useful in open/save dialogs.

As I've mentioned before, a common use case that this enables is when you save an item from one program and need to open it in another without having a Dolphin window open that shows it. One example is attaching files to websites. You just go to the "Recent files" entry in the Open window and voila, your latest saved file is right there on the top. It's a super fast workflow.

There is a reason why "Recent items" is a default entry in the file manager and open/save dialogs in macOS and GNOME. They didn't add it for no good reason.

That is a somewhat cryptic notation. Sure, it tells you exactly what you want to know "if" you know that's what it's telling you.
On the other hand, anything longer might be too long.

Please, change the naming of "fast renaming".
You could also argue that pressing F2 on a selected item (or multiple even) is even faster renaming.

Watch this: https://www.youtube.com/watch?v=T0Jj4lUm_p8
Apple really has done a marvelous job in making tags useful!

-1 for the current version as well.
We've had those frames before. The benefit of locking docks is no frame (for me that is the benefit).

In D7700#148280, @ngraham wrote:

The title is only visible when the panels are unlocked. But in fact, the problem goes away when panels are unlocked; it's only a problem when locked. I'm working on a patch that improves this when panels are locked. Either way, we should continue that discussion in https://bugs.kde.org/show_bug.cgi?id=384999.

In D7700#148276, @ngraham wrote:

If we can make it a separate panel and overcome some of the disadvantages of having multiple panels. I'm fine with it. That means:

1. Make the Tags panel visible by default
2. Include a visible separator between panels (https://bugs.kde.org/show_bug.cgi?id=384999)
   
   I can work on https://bugs.kde.org/show_bug.cgi?id=384999.

Again, same with recentdocuments, if stuff like this is added by default, it needs to work just fine in the normal usecases, otherwise it will cause bug reports which will in term cause the tags part to be disabled by default. Yes, chicken and egg problem plays here as well.

I'm working on improving the tags ioslave. D7855 was a first step on this.

Just curious, i have some files with tags (just added them). Baloo is running, but tags:/ is empty...
System monitor shows a baloo_file running at 100% cpu...

In D7700#148256, @ngraham wrote:

If we make a new panel, we incur the following disadvantages:

1. Lots of extra work, increasing the chance that it won't get done. We already have working code to add it to the Places panel.
2. Assuming we make a new Tags panel, if we don't make it visible by default, almost nobody will ever see it, negating the purpose of adding the feature and keeping the overall Tags feature very un-discoverable.
3. If we *do* make the new Tags panel visible by default, it will compete for vertical space currently used by the Places and Folders panels, and people will probably close it if it's visible by default, and not open it in the first place if it's not.
   
   I know that technically Tags aren't places, but the advantage of putting this in Places is that people will actually see it and use it. If we put it somewhere else, especially in a not-visible-by-default panel, I worry that the work will be essentially wasted.

Sorry for acting like a "protect the places panel" guy again.. but yeah, again :)
Please make a Panel for tags, not slapping it into the places panel. The macOS finder example was shown, that exact result can be achieved by putting it into the places panel, but also by putting it in it's own panel!
Making it's own panel for it is much cleaner and maintainable.

In D7446#148135, @ngraham wrote:

It seems odd to have all of these special KIO URLs that we don't actually want to use because they're rough and underdeveloped. They're rough and underdeveloped because they're hidden by default, so nobody sees them, and nobody files bugs or submits patches for them. But I do see your point.

That said, the advantage to adding this as a Places item is that it shows up in file open/save dialogs for free, which is where it's most useful. If we make this into a whole new panel, we'll have to do a bunch of otherwise unnecessary special work to get it into open/save dialogs. I don't see the advantage.

If the objection is that the content isn't useful (why does it show URLs?), then I can fix that too, but only if by doing so, folks will be amenable to adding a "Recent Documents" entry by default. It really is useful to have recent documents aggregated somewhere.

In D7446#148070, @elvisangelaccio wrote:

Yeah I also find weird to see weblinks in there. Maybe if we call it "History" would be a bit better (and it would also match the History tab in Kickoff).

In D7446#148059, @ngraham wrote:

I don't think this is "semi-useful". " A Recent Documents feature in the file manager and open/save dialogs is IMHO really important, especially for lesst-technical users who use features like this on other platforms expensively instead of making extensive use of folder hierarchies. "The user can add it" is a problematic response since 99.9% of users don't know this exists, and therefore don't know that this functionality is available in the first place (and if they did, they would find it challenging to add).

The file managers and open/save dialogs in macOS and GNOME both have some kind of "recent stuff" feature shown by default, and it's really nice. And ad evidenced by the but report and the fact that people have voted for it, this is a desirable feature to some of our users.

You could continue and add about a dozen more "semi-useful" protocol links (ftp, settings, programs, bluetooth, and much more) ;) .
I don't think that's the route for the places panel to go. Not by default that is.
If the user wants it, it can be added just like any shortcut can be added in the places thingy. By default it should stay rather clean. recentdocuments is (in my opinion) not one that should be there by default. Also, for me personally it seems rather weird as recently visited url's are also in the recent documents.... And files I've accessed on the console don't appear in it at all (understandable though).

Imho, it should just use the one set in system settings. Not hardcode anything besides perhaps a default one if nothing has been set.

Ugh, both don't look that neat to be honest.
But i would still prefer the old one over the softer one. The soft one looks too soft, specially with the tiny thumbnails in list mode, it looks like a weird white area (not as a shadow) while the old one did look like a shadow.

I'm sorry, but i'm very much against adding this feature.
It was shot down by the previous maintainer for (in summary) being a really small feature that a _really_ small percentage of the users would be using (if any).
See Frank's reasoning for closing it as wontfix: https://bugs.kde.org/show_bug.cgi?id=333219

With all the thumbnailers you turned on, i'd be against it.
It's probably not going to slow down scrolling speed because the thumbnail generation is done in another process. Thankfully! Otherwise you would be horrible slow :)
But on large folders it will have an impact on the CPU i think.

A very big +2!
You can wait for Emanuel to chime in and give his opinion.
It seems a bit unlikely that he would chime in anytime soon though. His last mail in the KFM list (either by mail or by comment on reviewboard or here) is from Feb. 18. You can wait for him, but i think he would be fine with fine with the change.

I don't think adding a (rather massive) delay is the real fix here. It only masks the actual issue.