I have tested it and it solves https://bugs.kde.org/show_bug.cgi?id=414482
It seems .protocol file support has some issue.

Fix json

@elvisangelaccio, how do you feel about this? I'd like to avoid letting the conversation go in directions you won't be okay with, since you're the maintainer.

In T12308#216391, @The-Feren-OS-Dev wrote:

2. Have the menu appear when pressing ALT and then disappear after being used, like in Windows.

If those ideas are implemented, Dolphin looks just like it does in these concepts layout-wise and Recent is placeable in the Places part as just "Recent" it'd be darn perfect.

Just some ideas I'd also love to see implemented:

1. Have the fallback menu button if no menu is shown be an optional toolbar component that can be moved or removed
2. Have the menu appear when pressing ALT and then disappear after being used, like in Windows.
3. Have the fallback menu button not appear if a Global Menu is used

Thanks, this is much better technically.

Convert to emit signal per @ngraham 's comment.

Given that the down arrow key currently does nothing here, I think that this makes sense conceptually. I'm not a huge fan of this setView() function though. Instead, pressing the down arrow key should emit focusViewRequest(); This is how the filter bar implements this functionality.

No, I think it's nicer to keep it open, even with a bit of flickering.

Create the KFileItemList inline

• Rebase
• Fix build failure
• Update minimum frameworks version

In D26362#586511, @iasensio wrote:

As far as I can tell, currently the focus will change from the searchbar to the view when you press <Enter>.
Would that be an acceptable workflow?

As far as I can tell, currently the focus will change from the searchbar to the view when you press <Enter>.
Would that be an acceptable workflow?

The flickering in the current state is kind of unavoidable.
Every time a tag is clicked and a new search is made, the whole search url is reparsed and the menu gets repainted several times.
It seems to me that it is less annoying when the repainting is done "in the dark" and then show the menu again, that when it's keep visible the whole time.
Due to the way that tags are retrieved (using a KDirLister, as in the context menu) I cannot think of a better while simple way to do it without a major refactor and lots of extra code.

Heh, there still seems to be a bit of flickering here even with this version. However this version has much less code! :D

Thanks!

Sorry, I messed up with the diffs. Back to normal

Going back to the simpler option.
This should have less flickering

In D26343#586117, @ngraham wrote:

Ehhhh, I find the flicker pretty annoying. :/

I think I'll re-upload the first revision so you can try it too, and decide on that.

Not too sure if it helps bug https://bugs.kde.org/show_bug.cgi?id=414482

clean

Fix introduction of BIC method

Ehhhh, I find the flicker pretty annoying. :/

I have uploaded the version with eventFilter so you may try if the flicker is too much to be annoying or it is just me.
I'd still prefer the simplest/maybe hackiest oneliner to just re-show the menu:

• Use eventFilter

In D26343#585839, @broulik wrote:

I think you probably want to use an event filter instead to keep the menu from closing in the first place?

I'm not so sure I want to enter there 😃

I think you probably want to use an event filter instead to keep the menu from closing in the first place?

I'm a bit surprised by all the bad comments concerning an useful feature.
Are you taking people for dumbs that can not understand duplicate would
copy/paste in one go in the source location? macOS has such feature for
years and nobody comes complaining disk would have failed. Also, it does
not mean people will use it many times per day. I personally use duplicate
feature a lot and really miss it from dolphin.

I see. No, I'm not aware that KIO implements that.

In D8208#585655, @dfaure wrote:

Hopefully aunt Debby won't use "Duplicate, then move the duplicate to other disk"

What's the problem with doing that?

Hopefully aunt Debby won't use "Duplicate, then move the duplicate to other disk"

What's the problem with doing that?

• Find XCursor specifically

In D16353#584264, @cfeck wrote:

You marked my issues as Done but didn't change the code there. Please test with CheckColorRoles on Fusion widget style.

You marked my issues as Done but didn't change the code there. Please test with CheckColorRoles on Fusion widget style.

Add a tooltip displaying the % of disk usage

The missing screenshot (with breeze dark) :

Fix percent, improve variable name

In D11382#578198, @elvisangelaccio wrote:

Fair enough.

Please note that I'm planning to rework the dbus handling in global.cpp during the christmas holidays. If you don't mind I'd wait to get that merged and then rebase this patch (which should also become simpler).

Nice cleanup!

In D8208#155926, @elvisangelaccio wrote:

If the main/classic method of copying doesn't work well with many files, imho we should find a way to fix that. So that the use case would be ok for everyone, not just those who have the menubar visible or know the CTRL+D shortcut.

So the threshold is now 50%? Isn't that a bit too low?

Update following review, commandeer revision, rebase

No, that doesn't sound weird, but seems a valid use case. Hopefully aunt Debby won't use "Duplicate, then move the duplicate to other disk" as I remember reading somewhere as a potential use case for users that fear that dragging a file to a different place will destroy the original.

Yes, for the case where you want to make a copy, somewhere else, using copy/paste makes more sense. But this feature is explicitly for the use case where you want to use create a duplicate next to the original, for some subsequent operation (e.g. creating a backup, making a copy that you will then edit in a different way from the original to then later compare the two, etc). I find myself doing this quite a lot. Maybe I'm a weirdo.

But you usually copy here and paste there, not at the same place.

And I still don't think that makes any sense, unless you think that copy-and-paste should do the same thing. This feature is nothing more than a slightly quicker way to create a copy of a file than by doing copy-paste-rename.

I still believe it is wrong. I probably wouldn't object if the duplicate is a hardlink, instead of a physical copy of the file.

Ready for re-review.

Improve API

Add fact that protocol supports truncation

Avoid code duplication

Avoid free(NULL)