Open
Bug 1214318
Opened 9 years ago
Updated 2 years ago
Create a TreeList Widget
Categories
(DevTools :: Shared Components, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: jsantell, Unassigned)
References
(Blocks 1 open bug)
Details
Lists can be trees that are all top level items. I think this widget should handle both scenarios. We should have a consistent way of rendering our trees and lists with default rendering for consistency, as well as able to be extensible for our current uses. We have a many implementations (abstract tree widget, treewidget.jsm, variablesview, JSONResponseViewer, and Heap Tree View from memory tool prototype), that can be implemented with the same core and extended as needed.
VariablesView may be it's own thing and should not be migrated to this.
Current table usage:
* Storage Tool (TreeWidget.jsm)
* Resources/new StyleEditor view (Alex working on?)
* JIT Optimizations (TreeWidget.jsm)
* Webconsole (custom)
* VariablesView in webconsole, web audio, storage, scratchpad, tooltips?, netmonitor, debugger, webide
* Debugger (global search, watch expressions, results panel) using SimpleListWidget
* Performance tool and a few others use SideMenuWidget.
* JSON Response Viewer (custom)
* Performance tool waterfall view, Abstract Tree Widget
* Performance tool call tree, allocations, memory tool heap view all use Abstract Tree Widget, but are table-tree views and should be handled differently (?)
New TreeList widget requirements
* Expandable/collapsible rows
* Filter data via predicate
* Extensible to support complex scenarios like waterfall view
Reporter | ||
Comment 1•9 years ago
|
||
More requirements: should only render what's in view
Comment 2•9 years ago
|
||
I'm not sure if this is now a dupe, moving to shared components component
Component: Developer Tools → Developer Tools: Shared Components
Updated•6 years ago
|
Product: Firefox → DevTools
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•