FileTreeComponent sort algorithm

Is it possible to specify your own sorting function for the FileTreeComponent? Any examples would be most welcome.

So this isn’t possible? At all?

I just think it’s strange that there is this nice, very customizable component and then it’s lacking this very basic functionality.

In my short look I took at the involved classes, I haven’t been able to find the sorting functionality at all, but clearly the names are sorted alphabetically. I would like to either provide my own callback or extend the existing class so the user (us) can pass our own “compare” function.

OK. I found the FileInfoComparator class (“struct”?) but it’s hard-coded into the DirectoryContentsList::addFile method.

@jules Should I makes this configurable and submit a pull request, or don’t you care about this functionality and I simply extend the DirectoryContentsList and override the addFile method and thus the comparator?

It’s a sensible FR - if you’re in a hurry, quickest way to get us to do something is to send us a good pull request

@jules that sounds good. Can I also suggest other changes about the FileTreeComponent here?

For example, I think it’s wasteful to blindly pull the system-icons for each file, even if they are not displayed. I plan to use this component to show presets (which happen to be files) and I have no intention of displaying their system-icons (Cubase fxp icons), so a simple “enableSystemIcons (const bool onOff)” function would avoid that unnecessary waste of resources (HDD access, memory, rendering etc.)

Similar for the additional file information beyond the name and file-type. I don’t need to display the modification-time, creation-time or file-size. So again this can avoid wasting resources and speed up the scanning process. A simple “enableFileInfo (const bool onOff)” would solve this.

Are these example also reasonable to you?

Let’s assume for a second that I’m not in a huge hurry, how long do you estimate (just roughly) how long would it be before someone get’s around implementing all three feature requests? Are we talking months, weeks or days?

I can live with 3-6 weeks. Obviously faster would be better.

I also just noticed that the DirectoryContentsList class lacks two major functions, so that plugins can update that list without having to rescan everything.

The “addFile” function should be made public but respect the new comparator callback.
There should also be a “removeFile” function, to remove a single entry.

This makes it possible to move, copy, rename and delete entries within the FileTreeComponent, as I would assume that changes to the DirectoryContentsList would be reflected in the FileTreeComponent, making effective file-management (or in my case, preset-management) even possible.

Thanks for listening :smile_cat:

Disabling the system icons seems like a reasonable request. Not sure I understand why you’d want to explicitly add or remove files though, as the whole point of this class is that it reflects what’s on disk, and it shouldn’t be a big deal to have it rescan if you modify a file (?)

Can’t really ever promise about timescales on random little features like this, it just depends when someone on the team has the time/inclination to look into it - that’s why I’d suggest a pull request as the best way to get our attention.

as the whole point of this class is that it reflects what’s on disk

Yeah, I just realized that what it’s supposed to be for the other day, so I guess you can ignore my FR for this class, as I’d rather roll my own based on parts of it.