I've submitted a patch to Breeze that resolves the usability issues with having multiple adjacent DockWidget panels: https://phabricator.kde.org/D7957
Seems like a simple solution is to always show the title. That way, it wouldn't scroll away and you would still see it when locked. We would have to remove the redundant title from the Places panel with this, but that's simple enough.
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.
Ideally, the title does not scroll away at all.
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.
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:
- Make the Tags panel visible by default
- Include a visible separator between panels (https://bugs.kde.org/show_bug.cgi?id=384999)
I would be fine with moving it to a separate panel. If we do that, the PlacesPanel, the TagsPanel and a (hypothetical, but I saw people voting for it) BookmarksPanel would share a lot of code. Basically it would be the same View and Controller with different Models. I would suggest to get rid of that redundancy by sharing the View and Controller.
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...
If we make a new panel, we incur the following disadvantages:
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.
FWIW, I've been testing this and it works really well. Nice feature.
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.
Fri, Sep 22
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).
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).
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).
Updating diff to try to get it to apply with arc (will use arc for future revisions)
Thu, Sep 21
Yeah. I don't have a Reviewboard account, and it seems a bit silly to create one seeing as how it's going away soon. Anyone wanna nuke it?
@emmanuelp Ping! It would be great to get your blessing so we can land this.
Fair enough. Thanks for merging the other patch! Abandoning this one.
A better fix is https://git.reviewboard.kde.org/r/123253/
Wed, Sep 20
Diff 19425 and Diff 19660 are identical (save for a whitespace change). Maybe the wrong patch was uploaded?
Nnnope, patch fails to apply for me, on current dolphin master. 😆 https://paste.kde.org/ppx1r8xxl
I can test this a bit later today to verify.
Tue, Sep 19
I don't have time to test now, but i understand you rebased it so if it's good it's good :)
I think the grouping should be moved upstream into the model, too and then be used for file open dialogs to make that visually more similar to what dolphin shows.
@aacid, does it apply now for you?
Mon, Sep 18
@elvisangelaccio: So I was thinking of using KIO::FileUndoManager::undoJobFinished but it unfortunately provides no details as to what job was undone.
A possible option would be to keep the last job recorded so we have the name that the undo-ed item will have after reverting, but this is just hacky and doesn't support more than 1 action. I think best would be if job information was passed from KIO::FileUndoManager and then Dolphin could leverage it. I also tried to leverage selectionManager but to no avail.
@emmanuelp should accept it.
Sun, Sep 17
Looks good to me. @anthonyfieroni?
Any further objections/issues/comments?
I'm not sure I agree with this patch.
A standard behavior in other filemanagers when umounting a device is to redirect to the view from the device URL to the home URL.
So imho this patch is using the wrong approach: instead of the mainwindow telling the terminal panel to go to the home, it should be the mainwindow the one that changes its URL to the home.