Closed sudara closed 4 months ago
Since it also resets the transforms, I would prefer if the whole dragging/resizing feature could be toggled on off.
Yeah agreed. Moving and resizing might be better as explicitly enabled. Between this and wanting to disable the overlay entirely, I’m starting to feel toolbar vibes…
just keep thinking (along with #50) that there might be a better mental model of what “inspector is enabled” means…
I would steal as much behavior/decisions as possible from established tools, like the chrome inspector. The closer we can get to that, the better. Is familiar and there are often good reasons why things are the way they are.
Maybe even add a “console” for debugging messages (we can add our own log macro).
Is familiar and there are often good reasons why things are the way they are.
Yes, the tool is modeled on figma and safari/chrome web inspector, so 100% with you on that! Devil is in the details though, in particular because the tool started from 0 (for example moving components didn't exist) and is evolving incrementally.
Maybe even add a “console” for debugging messages
Tell me more! What benefits does this bring on top of IDE logging with DBG
? Timestamps? Retention across sessions?
Retention in general, and we use multiple different macros Z_LOG for pure debugging, does nothing in release builds, but Z_WARN and Z_ERROR are always logged and visible to customers.
we can then collate that last 3-4 sessions into one text file and save it. That way customers can provide these to aid in trouble shooting.
Icons are already in place for this in the BinaryData
Figure out a way to disambiguate (defer dragging to the app by default?)