Bugzilla

Early working prototype that is driving me slightly crazy.
I decided to pursue the approach of using a single tree after trying other approaches.
These are my findings:
- The `tree` element uses its own scrollbar, pretty hard to control or disable.
- The `tree` item uses the entire eight of its parent container, so if we wanted to use multiple trees, we would need to have vboxes for each of them, separated by a splitter.
- Having multiple containers with multiple scrollbars is a usability nightmare.
- Having to handle multiple `tree` IDs throughout the entire application is an even worse nightmare.

I think we can discard the approach above.

**Using a single Tree**
With this WIP patch you can toggle on and off multiple modes at once.
Each mode will have its own "Header" row, with a different style to separate the modes.
The header is not visible if you only have 1 mode active.

These are the issues I'm having and bugs I need to address:
- The header row is not super customizable in terms of height or padding, I wish the tree was more flexible but I think that's all we can do.
- The header rows shouldn't be clickable, as there's nothing to load obviously. How can I disable those row items?
- Every time a mode is toggled, the persistent Open and Closed state of the folder goes bananas. I'll try to fix it.
- The view order is dictated by the selection. We should have a fixed order and later on allow users to drag and drop the headers to reorder the lists.

I'm sure there are other thousands of bugs I haven't considered due to this approach, but we can slowly deal with those as we progress.

**In conclusion**
Even if frustrating and hard, I think this approach is doable, with some more rewrite and code clean up.
I saw that m-c is using tables in some areas with long lists, and I wonder if we should maybe try to completely rebuild the Folder Tree and move to tables, which could give us the flexibility we need, but that means rebuilding this essential area entirely from scratch, and I'm not sure I feel super comfortable doing it.

Early working prototype that is driving me slightly crazy.
I decided to pursue the approach of using a single tree after trying other approaches.
These are my findings:
- The `tree` element uses its own scrollbar, pretty hard to control or disable.
- The `tree` item uses the entire eight of its parent container, so if we wanted to use multiple trees, we would need to have vboxes for each of them, separated by a splitter.
- Having multiple containers with multiple scrollbars is a usability nightmare.
- Having to handle multiple `tree` IDs throughout the entire application is an even worse nightmare.

I think we can discard the approach above.

**Using a single Tree**
With this WIP patch you can toggle on and off multiple modes at once.
Each mode will have its own "Header" row, with a different style to separate the modes.
The header is not visible if you only have 1 mode active.

These are the issues I'm having and bugs I need to address:
- The header row is not super customizable in terms of height or padding, I wish the tree was more flexible but I think that's all we can do.
- The header rows shouldn't be clickable, as there's nothing to load obviously. How can I disable those row items?
- Every time a mode is toggled, the persistent Open and Closed state of the folder goes bananas. I'll try to fix it.
- The view order is dictated by the order in which you toggle the modes. We should have a fixed order and later on allow users to drag and drop the headers to reorder the lists.

I'm sure there are other thousands of bugs I haven't considered due to this approach, but we can slowly deal with those as we progress.

**In conclusion**
Even if frustrating and hard, I think this approach is doable, with some more rewrite and code clean up.
I saw that m-c is using tables in some areas with long lists, and I wonder if we should maybe try to completely rebuild the Folder Tree and move to tables, which could give us the flexibility we need, but that means rebuilding this essential area entirely from scratch, and I'm not sure I feel super comfortable doing it.