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
Tue, Sep 17
Mon, Sep 16
Ooh, I'm so excited that this will be landing soon!
Sun, Sep 15
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?
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.
- Cool :)
- 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.
- Sure, we could do that.
- 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:
- 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.
- How will you handle tabs? They are not a very discoverable feature now (sadly), and with this change integrating them looks even less promising.
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 :)
Sat, Sep 14
#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?