1# Inspector
 2
 3This is a tool for inspecting and manipulating rendered elements in Zed. It is
 4only available in debug builds. Use the `dev::ToggleInspector` action to toggle
 5inspector mode and click on UI elements to inspect them.
 6
 7# Current features
 8
 9* Picking of elements via the mouse, with scroll wheel to inspect occluded elements.
10
11* Temporary manipulation of the selected element.
12
13* Layout info and JSON-based style manipulation for `Div`.
14
15* Navigation to code that constructed the element.
16
17# Known bugs
18
19* The style inspector buffer will leak memory over time due to building up
20history on each change of inspected element. Instead of using `Project` to
21create it, should just directly build the `Buffer` and `File` each time the inspected element changes.
22
23# Future features
24
25* Info and manipulation of element types other than `Div`.
26
27* Ability to highlight current element after it's been picked.
28
29* Indicate when the picked element has disappeared.
30
31* Hierarchy view?
32
33## Better manipulation than JSON
34
35The current approach is not easy to move back to the code. Possibilities:
36
37* Editable list of style attributes to apply.
38
39* Rust buffer of code that does a very lenient parse to get the style attributes. Some options:
40
41  - Take all the identifier-like tokens and use them if they are the name of an attribute. A custom completion provider in a buffer could be used.
42
43  - Use TreeSitter to parse out the fluent style method chain. With this approach the buffer could even be the actual code file. Tricky part of this is LSP - ideally the LSP already being used by the developer's Zed would be used.
44
45## Source locations
46
47* Mode to navigate to source code on every element change while picking.
48
49* Tracking of more source locations - currently the source location is often in a ui compoenent. Ideally this would have a way for the components to indicate that they are probably not the source location the user is looking for.
50
51## Persistent modification
52
53Currently, element modifications disappear when picker mode is started. Handling this well is tricky. Potential features:
54
55* Support modifying multiple elements at once. This requires a way to specify which elements are modified - possibly wildcards in a match of the `InspectorElementId` path. This might default to ignoring all numeric parts and just matching on the names.
56
57* Show a list of active modifications in the UI.
58
59* Support for modifications being partial overrides instead of snapshots. A trickiness here is that multiple modifications may apply to the same element.
60
61* The code should probably distinguish the data that is provided by the element and the modifications from the inspector. Currently these are conflated in element states.
62
63# Code cleanups
64
65## Remove special side pane rendering
66
67Currently the inspector has special rendering in the UI, but maybe it could just be a workspace item.
68
69## Pull more inspector logic out of GPUI
70
71Currently `crates/gpui/inspector.rs` and `crates/inspector_ui/inspector.rs` are quite entangled.  It seems cleaner to pull as much logic a possible out of GPUI.
72
73## Cleaner lifecycle for inspector state viewers / editors
74
75Currently element state inspectors are just called on render. Ideally instead they would be implementors of some trait like:
76
77```
78trait StateInspector: Render {
79    fn new(cx: &mut App) -> Task<Self>;
80    fn element_changed(inspector_id: &InspectorElementId, window: &mut Window, cx: &mut App);
81}
82```
83
84See `div_inspector.rs` - it needs to initialize itself, keep track of its own loading state, and keep track of the last inspected ID in its render function.