Debugger accordion: show counter on closed accordion headers
Opened this issue · 2 comments
In #102 we're proposing removing the "+" button on one accordion header, and using an always-visible text input in the accordion content instead.
If we can do something similar for all sections (including the "Log" checkbox for Events, which could be moved to a content checkbox like the one in Breakpoints), we can reclaim the right header space for: counters.
The idea is to show a count of active elements when a section is collapsed:
- Watch expressions: number of expressions
- Breakpoints: number of active breakpoints (not counting unchecked ones), plus one if "Pause on exceptions" is checked
- XHR Breakpoints: number of items, plus one if "Pause on any URL" is checked
- Event Listener Breakpoints: if we count all checked boxes the count could go very high, maybe count only first-level ones that are checked or in undetermined state (some children are checked)?
The blue highlight could be used when we're currently paused on a breakpoint, to highlight the section where this breakpoint is.
When a section is expanded, should we still show the count? I'd rather be minimalist and hide it, but open to ideas.
Feedback on the idea:
- @digitarald and @violasong have expressed support.
- @jasonLaster @darkwing @bomsy what do you think?
The idea is to show a count of active elements when a section is collapsed
great idea.
Event Listener Breakpoints: if we count all checked boxes the count could go very high, maybe count only first-level ones that are checked or in undetermined state (some children are checked)?
It might be a perfect solution. Anyway, if we count all checked boxes, I would not see a big number as a problem.
When a section is expanded, should we still show the count? I'd rather be minimalist and hide it, but open to ideas.
I am a bit more for the "show the count always" option. I see a small benefit of always being able to see the state at a glance, no cost; I don't see the benefit of hiding it, and I see a small cost, which is the UI change to process for the user.
Love this! What's the red for? If we're indicating the cause of a pause, maybe I'd use blue instead.
This observation by @violasong about the color made me wonder if we could help the user better see the UI state when the code execution stops on a breakpoint. Would it be useful to use a common color for the elements the arrows point to in the screenshot below?
By the way, I did not realized it (maybe it was in my subconscius 😉 ) but Chrome is doing something close to what I was wondering
