Questions about the FileBrowserComponent

Hi JUCErs,

I need your advice on a piece of GUI I’m working on.

It is a Preset Library, that I am implementing. I need to fit the Preset Library within a tight, taller-than-wide space, so I decided to split it into 2 panels within a Concertina.

First (top) Panel is for location of the preset (namely 2-level deep directory structure - 1st level being the Bank and 2nd level being a Category) represented by a custom FileBrowserComponent.

Second (bottom concertina) panel would be a grid (table) with presets of the selected locations from the first panel.

I’ve been looking in the Projucer for its implementation in the sidebar, since it looks similar. But I find it way too complicated for my pretty fixed scenario, so I abandoned my efforts to try and replicate that (it’s a design of… 20+ types and for the Projucer that may be reasonable, but I don’t think I need that much complexity for this simple, fixed scenario).

For the Location Panel (Bank/Category) I now have a custom FileTreeComponent showing only directories.

While I don’t expect anyone to implement this for me, I am hoping to get your input on best strategies and pointers for these features:

  • √ expand the whole TreeView at init - in the constructor of the FileTreeComponent I don’t have anything loaded yet and I don’t see a notification for the tree being loaded, so I can’t traverse it and expand once the async load is done (when is it done?);
    • tree->setDefaultOpenness (true); does the job.
  • √ remove the change of root (entering a dir) behavior on double click and replace it with toggle of the open state (expand/collapse).
    • changing root happened with FileBrowserComponent (what I used initially), but doesn’t happen with regular FileTreeComponent.
    • To get the folding - I have a custom versions of FileListTreeItem (DirTreeItem) and in DirTreeItem::itemDoubleClicked () I call itemOpennessChanged (! isOpen ()); to toggle the state. I think there is a bug here - I think I am supposed to use setOpenness (), but that doesn’t change the state.
  • √ remove arrows and change icons:
    • To remove the arrows - tree->setOpenCloseButtonsVisible (false);.
    • To change the dir icons, I’ve altered the DirTreeItem::updateIcon ().
  • X CRUD operations on the tree items (dirs), except the Factory branch.
    • Decided I will not allow CRUD operations through the TreeView.

I have checkmarked everything that I manage to get done with an explanation on how.

I decided I don’t need to implement the CRUD on the tree and there simply will/can be multiple Default banks and a single User bank.

So I switched to the next thing on the agenda which is to load 2 different dirs (not sharing a root) within the TreeView and this turned out to be quite a mess…

I think the design of the TreeView is wrong to assume there always will be 1 root and from that stem a ton of problems.

Definitely quite frustrating experience for such a simple scenario… I think data and UI tight coupling combined with the design decision for single root add up to a pretty inflexible result.

Update: There are quite a lot of changes that needed to be made in order to get this working. Basically I added the option for an item to be “virtual” and it doesn’t trigger the background loading of files. Only the root item is virtual. Then on construction of the TreeView, I would add the subnodes of the virtual root (passed as an argument of the constructor) in the same way they would’ve been added if the DirTreeItem uses the product of its DirectoryContentsList. I also had to alter (make a custom version of) the base type DirectoryContentsDisplayComponent - by default it also expects a single root directory. AND because of that change I had to add a method for the item paint that copies the base one (the one on L+F_V2).