3. Instead of unconditionally doing q->insertPluginAt(plugin, 1);, you'd want to do something more like this:

if (plugin == "details"  /* this is pseudocode */) {
    q->insertPluginAt(plugin, 1);
} else {
    q->insertPlugin(plugin);
}

I'm actually not sure how to check for what the plugin is though. Maybe someone from Frameworks can help.

Ping.

Alternatively, we could put this on the Behavior tab, or even the Navigation page.

I can look into that.

LGTM too. @bruns any final comments before we land this?

Small ping on this small diff 😃

At the moment I would say yes. :)

https://git.reviewboard.kde.org/r/129383/ had a patch for this but it never got merged. Copying the diff here in case anyone wants to take over:

So should we close https://bugs.kde.org/show_bug.cgi?id=376992 ? ;)

Thanks, that fixed it!

In D24076#534627, @feverfew wrote:

I won't review, but would like to note I think that with KIOFuse, in conjuction with fio we can do some really complex testing on KIO, correct me if I'm wrong.

If I'm right, then we can test KIO nicely, although if we do notice a bug via using fio, it can technically be in any of FUSE/KIOFuse/KIO, but in my experience KIO is the most buggy of the lot.

In D19311#534728, @ngraham wrote:

Just noticed that Alt+left/right shortcuts for back and forward are now broken.

Fix Back/Forward shortcuts

Thanks, cool stuff :)

Just noticed that Alt+left/right shortcuts for back and forward are now broken.

I won't review, but would like to note I think that with KIOFuse, in conjuction with fio we can do some really complex testing on KIO, correct me if I'm wrong.

Restrict the number of navigation entries to 12

Ooh, I'm so excited that this will be landing soon!

Rebased.

If the URL Navigator is moved into the toolbar, isn't it more likely to observe a shortened URL Navigator when the path is barely more than two levels deep?
Would such a move allow people to partially restore the old behavior by creating a separate toolbar? (partially because it won't be possible to have the URL Navigator at the same level of the Places panel as it is now)

Sorry for the delay.

Would it be too noisy if we did something like [ ... > dir1 ] | [ ... > dir2 ] for split views?

In T11663#200463, @IlyaBizyaev wrote:

Just to make sure, do you imagine tab bar placed above the toolbar? That is a familiar browser-like presentation.

I agree, we don't have to do this to make the buttons more discoverable. That's mostly tracked by https://phabricator.kde.org/T11662 anyway.

1. Cool :)
2. Just to make sure, do you imagine tab bar placed above the toolbar? That is a familiar browser-like presentation.

It seems to me that making the URL navigator buttons more discoverable and moving the URL navigator to the toolbar are two orthogonal things.

1. Sure, we could do that.
2. The location displayed in the URL bar would change when the active tab changes. This is what other file managers already do and it's fine IMO.

Couple of questions:

1. Can we keep the URL navigator left-aligned or make it filling width? Unclear what jumps and resizes will happen when a user enters or leaves a subdirectory.
2. How will you handle tabs? They are not a very discoverable feature now (sadly), and with this change integrating them looks even less promising.

Nice!

In D23757#531196, @GB_2 wrote:

Would be nice if you could also made a KIO patch that changes the icon for "Open With" to system-run and the icon for "Actions" to view-more-symbolic.

Ping

No worries! And sorry for rejecting your first patch. D23969 looks much more promising. :)

Thanks for the review and the hints @elvisangelaccio.
Those were some issues I tried to explore when starting the patch but didn't get to work, so I went the hardcoded way.
I hope it is in a better shape now.

• Remove unrelated changes
• Reuse QMovie instance
• Check supported formats instead of hardcoded mimetypes

Okay, I've seen your change. Well, those 2 icons are not needed anymore I think.

Needs one more rebase, sorry

I'm afraid you're slightly too late! :) I just removed those menus from the hamburger menu entirely, replacing them with curated subsets of their content. Rebase on master and you'll see.

Nice, this seems to do the trick :)

Done.

#232627 barely makes any difference compared to #000. Marking this as abandoned for now as it's an old revision.

We could make the menu scrollable rather than expand sideways for this use case. There's a QStyleHint for that IIRC. I think it's a somewhat niche scenario case anyway

Remove uninformative, self-evident comments

What about something like this?

Oh, and you are right again.
The previous solution seems to fix it without a regression, but obviously the code itself feels at the very least "not good".

Actually this introduces a regression, sorry about that. dolphin / will now show "Home" as window title...

Updated!
I didn't think about this solution, thanks, clearly it's way better than mine.

Looks great!

Would be nice if you could also made a KIO patch that changes the icon for "Open With" to system-run and the icon for "Actions" to view-more-symbolic.

Rebase

Thanks

Haven't look at the whole diff yet, since the fix for the duplicates could be quite invasive

Undo another unintentional change

Undo unintentional change

Revert icon and text changes (now done in a separate patch)

Don't show Compare Files

Could you please move the renaming of labels (e.g. "Hidden Files" to "Show Hidden Files") and the addition of icons to different commits? That would make this patch much easier to review.

• Fix Error
• Move "Show Panels" menu out of the view-specific section and into to the section with other global settings