locate widget on flutter inspector through something like break point

[devdoomari3]

Use case

Finding widget-code through UI already exists. But finding UI through widget-code doesn't exist yet

Proposal

in VSCode quick-fix, add these when a user selects a widget in code.:

• locate/highlight widget inside inspector
• flash widget on view for 1 sec"

(there should be something similar on android studio, but my laptop dies when I try)

[kenzieschmoll]

@jacob314

[InMatrix]

Is this issue the same as #2033?

[devdoomari3]

@InMatrix if "select a widget" means selecting a widget in code, then yes!

ps: possible places to put this feature I can think of:
1). break-point (right-click)
2). quick-action
3). right-click on widget

[InMatrix]

@devdoomari3 Yes, I was referring to selecting a widget in code.

ps: possible places to put this feature I can think of:
1). break-point (right-click)
2). quick-action
3). right-click on widget

Are these places ordered by your preference? If so, why do you like triggering this feature on break-point than other methods?

[devdoomari3]

@InMatrix no those are ordered by whatever comes to my mind ¯\_(ツ)_/¯

(breakpoints will be horrible for 1-liner multi-widget-embedding codes:

SomeGrandParent( SomeParent ( SomeChild ( 5 ) ) ) // breakpoint on this line: which one?

quick-action /right-click seems better. But then, it becomes a matter of discoverability:

• I don't reach for quick-action unless some light-bulb icon comes on
• I don't do right-clicks on code

( so even I won't be able to "self-discover". )

Some random thoughts:

• give random light-bulb on widgets to give "hints" about this feature (like intellij tips, but subtler)
• when the user "stays" the caret long enough on the widget code, turn on the lightbulb icon
• give highlight-color / add "text-box-border" styling to indicate which widget is which
  (click on the widget-code to change style/color / etc)

[jacob314]

We don't currently expose it in the IDEs but the protocol supports multiple breakpoints on a line so you could set breakpoints on each of those widgets for the multiple widgets on a line case.

One option to improve self-discover is to flash the widget on the device for 1 second any time the user navigates in the source code rather than waiting for a specific interaction. Performance for that option should be fine and flashing the widgets on the device should not cause a problem as the user was mainly interacting with the code editor not the device.

[InMatrix]

flash the widget on the device for 1 second any time the user navigates in the source code

This sounds reasonable. It should be easy enough to avoid triggering it as well.

[pq]

Related to the legacy inspector; closing as stale.