Bug 1163555 Comment 31 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I'm still working on this as I'm encountering various issues that might affect the way we approach this.
Before moving too forward, I think a bit more of brainstorming to find the optimal approach should be done.

Here's a bunch of questions and issues I stumbled upon while working on this implementation.

**Multiple Views Solution**
Upon looking at this section, and the way the listed add-on was handling the implementation, going the route of having multiple views seems to be the only acceptable one.
Multiple views means having completely separated XUL `tree` elements we can show/hide accordingly.

We reached this solution because a single `tree` doesn't offer the flexibility we need, due to the current limitations:
- We can't have identical folders repeated in the same `tree` element (eg. the same account inbox listed in both recent and favourite lists).
- We can't create "headers" to separate the different lists (eg. All Folders, Favourite, etc., like in the mock-up).
- We can't easily prevent a drag&drop action between folders in different lists without stumbling upon multiple issues.

Using a multiple view solution with completely separated `tree` elements, will remove the issues listed above.
These are the questions/issues I'm encountering with this approach:

- Having all the currently supported modes as standalone `tree` XUL elements in the XHTML file means all of those will be loaded on startup, impacting performance. I think I can solve this by tweaking the load method to not run if the element is hidden.
- Our current is limited to 1 `tree` element in the entire application, which is referenced by its id "folderTree". Having multiple tree views will force us to rewrite/update a lot of parts and all the methods touching the `gFolderTreeController` or directly using the "folderTree" id as a selector. This is gonna be pretty massive.
- How do we handle scrollbars? Should all the view be in the same scrollable area or each view should have its own scrollbar? (I suggest a single scroll area)
- Do we allow manually changing the height of each view with a splitter, or each view will grow in height to show the entire content? (I suggest to go for the latter, as it's easier and similar to what other apps do)

Thoughts, suggestions, or recommended approaches?
I'm still working on this as I'm encountering various issues that might affect the way we approach this.
Before moving too forward, I think a bit more of brainstorming to find the optimal approach should be done.

Here's a bunch of questions and issues I stumbled upon while working on this implementation.

**Multiple Views Solution**
Upon looking at this section, and the way the listed add-on was handling the implementation, going the route of having multiple views seems to be the only acceptable one.
Multiple views means having completely separated XUL `tree` elements we can show/hide accordingly.

We reached this solution because a single `tree` doesn't offer the flexibility we need, due to the current limitations:
- We can't have identical folders repeated in the same `tree` element (eg. the same account inbox listed in both recent and favourite lists).
- We can't create "headers" to separate the different lists (eg. All Folders, Favourite, etc., like in the mock-up).
- We can't easily prevent a drag&drop action between folders in different lists without stumbling upon multiple issues.

Using a multiple view solution with completely separated `tree` elements, will remove the issues listed above.
These are the questions/issues I'm encountering with this approach:

- Having all the currently supported modes as standalone `tree` XUL elements in the XHTML file means all of those will be loaded on startup, impacting performance. I think I can solve this by tweaking the load method to not run if the element is hidden.
- Our current implementation is limited to 1 folder `tree` element in the entire application, which is referenced by its id "folderTree". Having multiple folder tree views will force us to rewrite/update a lot of parts and all the methods touching the `gFolderTreeController` or directly using the "folderTree" id as a selector. This is gonna be pretty big.
- How do we handle scrollbars? Should all the view be in the same scrollable area or each view should have its own scrollbar? (I suggest a single scroll area)
- Do we allow manually changing the height of each view with a splitter, or each view will grow in height to show the entire content? (I suggest to go for the latter, as it's easier and similar to what other apps do)

Thoughts, suggestions, or recommended approaches?

Back to Bug 1163555 Comment 31