Version: unspecified OS: Linux No sort by custom option in document view in kate 3.6.0 Only "Document name" , "Document path" and "Opening order" exist. In setting same applies, except there its "Url" instead of "Document path" Reproducible: Always OS: Linux (x86_64) release 2.6.34.7-0.7-desktop Compiler: gcc
I confirm this one too. The "custom" sort option in Kate has disappeared :( I really liked that option so i hope it'll reappear... OS : Fedora 14. Kate : kdesdk-4.6.1-1.fc14.x86_64
I can also confirm that the sort by custom is missing in Kate v3.6.2. This is a very useful feature that I hope can be added back to the next release.
Can I +infinity points to this bug? I recently upgraded from KDE 4.2, and I used the custom sort every day. When I have 50 or so files open, dragging the order around makes programming a lot easier. Thanks!
Its a valid wish, but if nobody steps up to integrate that again, we won't have it. I know, it is kind of regression, but on the other hand the new file tree solves a lot of other issues.
Hi I'm in trouble with this removed features too... in the past years, I used to manage file orders with kate-file-list plug-in... then it was removed and I switch to kate sessions... but now (if I'm not wrong) there is no way to obtain a custom file order at all... best regards Giampaolo
I miss a feature like this too. Instead the option to "sort by mimetype/extension" would also be great.
Hi there, does anyone have a screenshot how the custom order was configured? I might be able to reimplement the feature, but failing to install working older version to check how it was done.
*** Bug 318746 has been marked as a duplicate of this bug. ***
I also confirm the lack of "sort by custom", I really miss that feature. Anyone found a workaround, a patch, some way to add it back, maybe a plugin for that? Thanks!
Currently: latest Ubuntu 64bit (14.10) Kate 3.14.1
Still missing. Arch Linux 64-bit Kate 16.04.2 KDE Frameworks 5.22.0 Qt 5.6.1 xcb wm
Dear user, this wish list item is now closed, as it wasn't touched in the last year and no contributor stepped up to implement it. The Kate/KTextEditor team is small and we can just try to keep up with fixing bugs. Therefore wishes that show no activity for a years or more will be closed from now on to keep at least a bit overview about 'current' wishs of the users. If you want your feature to be implemented, please step up to provide some patch for it. If you think it is really needed, you can reopen your request, but keep in mind, if no new good arguments are made and no people get attracted to help out to implement it, it will expire in a year again. We have a nice website https://kate-editor.org that provides all the information needed to contribute, please make use of it. Patches can be handed in via https://phabricator.kde.org/differential/ Greetings Christoph Cullmann
Hi, dear Buovjaga, are you willing to provide a patch for this or is there a specific reason this report was re-opened again? As you can read in my comment, that the wish is valid is not the issue, but that nobody has time to take care (or interest). Has this changed?
(In reply to Christoph Cullmann from comment #13) > Hi, dear Buovjaga, are you willing to provide a patch for this or is there a > specific reason this report was re-opened again? > > As you can read in my comment, that the wish is valid is not the issue, but > that nobody has time to take care (or interest). > > Has this changed? What does it matter? You said we can reopen the requests and I did it. Frankly, what you are doing is completely unreasonable and against any normal bug/RFE tracking practice. You risk a big negative backlash from the user community, if you continue like this.
> What does it matter? You said we can reopen the requests and I did it. I don't really think this is a nice way to respond to my question, but what does that matter :-) I said you can do so, if you really think this is needed. Given you didn't even write a comment (in any of the bugs you just re-opened) I can only guess that this is very important for you. I think at least some comment would be appropriate if you want to attract attention to get this ever implemented. Just changing the bug status without any comment really doesn't communicate a lot, I didn't just close away the old wishes without some (hopefully) understandable comment. > Frankly, what you are doing is completely unreasonable and against any normal > bug/RFE tracking practice. You risk a big negative backlash from the user > community, if you continue like this. We did the same things some years ago, just we never followed up to do this regularly. I have seen no big negative backslash the last time. It is just honest. Look at the "real" bugs we have open and we don't get time to fix. Just pretending this will ever be done just because we let this ticket rot here doesn't help users. But I keep my word, the issue is open again, I won't just close it again without letting a year pass.
I have no personal stake in these wishlist items. I am only notified of their closing, because I did triage for them in 2016. My concern is that your reputation will be tarnished by this very user-hostile move. If you think no one will mind (based on previous experience), then I guess there will be no ill effect. I still don't understand how keeping reports open is hurting anybody. I am a proponent of limiting feature requests on the grounds of having a clear product vision. It would be just fine by me to close wishes with "this is out of scope" or "not a good idea" etc. - this would allow future duplicates to be closed with existing good arguments.
Another +1 from me on this. I would love to make the jump from sublime over to Kate, and Kate has everything i'm looking for, but the inability to sort the documents by custom order is really frustrating. The Documents sidebar makes for a fantastic tree style/vertical tabs view, and makes it much easier to navigate and search through open files than using the top tabs. I have the top tabs disabled and am just using the documents view.
> sort the documents by custom order is really frustrating. Can you expand a bit more on this? What do you mean by custom sort order? How do you expect it to work? What UI? Things like this help if someone wants to work on it.
Sure thing, This is my second post on this forum, so thanks for the patience. As the very first comment in this thread states: While in the document view you only have an option to sort the documents in this followings ways: > Sort by "Document name" , "Document path" and "Opening order" exist. > In setting same applies, except there its "Url" instead of "Document path" I would like to request another option called "manual" or "user", when selected, lets you drag the documents around and arrange them in any custom order that you prefer. This way the user has full manual control of the sorting instead of being stuck with the 3 options that exist. For the UI, i imagine just another dropdown option next to the others named "manual", and when selected it lets the users free drag the documents around. Hopefully that clears things up.
That's a different request. This request says "No sort by custom option", what is that custom option? I don't understand and I don't have a 10 year old kate installation to find out what it was like before.
I found this old blog post talking about the old feature and it sounds like Yman is describing (drag'n'drop): https://kate-editor.org/2010/09/12/kate-tree-view-plugin-update/ > There’s now a list mode (which was surprisingly easy to do), as well as the tree mode and I’ve extended the sorting support to include all but the “custom sort order” option of the original file list (it’ll take a bit more work to support that, if its something people actually use, I just haven’t felt like doing the work to get drag and drop to work, and before now it didn’t make much sense to add).
So basically its reordering using DND, and not "sort by custom option". Would such a feature make sense for tree view too? And should the reordering persist after filtering for e.g?
> Would such a feature make sense for tree view too? I don't think it would make sense in tree view, as that view is hiarchichal, unless when you drag and drop a file it also moves it to a different directory. > And should the reordering persist after filtering for e.g? Can you clarify what you mean by "filtering". I do not see an option for that in the documents view.
> Can you clarify what you mean by "filtering". I do not see an option for that in the documents view. Look at the bottom. Line edit to filter.
(In reply to Waqar Ahmed from comment #22) > (In reply to Waqar Ahmed from comment #24) > > Can you clarify what you mean by "filtering". I do not see an option for that in the documents view. > > Look at the bottom. Line edit to filter. Ahh! Thank you. > persist after filtering for e.g? Yes in my mind it would make sense for it to persist. I drop and drag into an arrangement and then I filter it, and then I drop and drag it around again it would then become attached to maybe the file above it? That way when i remove the filter, it is next to at least one of the item as it was before. I'm not sure what would make sense more, attached to the file above it or below it. Or if both should exist as an option for the user to choose.
A possibly relevant merge request was started @ https://invent.kde.org/utilities/kate/-/merge_requests/810
Git commit 75d88783cd2a5e9f6f72eb81ad5933715dc63957 by Waqar Ahmed. Committed on 21/07/2022 at 11:50. Pushed by waqar into branch 'master'. DocumentsTree: Allow rearranging items by DND M +17 -5 addons/filetree/katefiletree.cpp M +1 -0 addons/filetree/katefiletree.h M +1 -0 addons/filetree/katefiletreeconfigpage.cpp M +74 -14 addons/filetree/katefiletreemodel.cpp M +7 -0 addons/filetree/katefiletreemodel.h M +0 -5 addons/filetree/katefiletreeplugin.cpp M +1 -0 addons/filetree/katefiletreeproxymodel.cpp M +2 -0 addons/filetree/katefiletreeproxymodel.h https://invent.kde.org/utilities/kate/commit/75d88783cd2a5e9f6f72eb81ad5933715dc63957