Allow control of which DevTools pages open embedded vs externally

[kenzieschmoll]

Some DevTools pages require more screen real estate than an embedded tool window can offer for the ideal user experience (e.g. the performance page). When looking at timeline traces, the more screen real estate the better, and looking at a trace viewer in a small tooling window is not a great UX.

We might want to consider having a set of defaults that can be configurable as a setting, that set the user up for the ideal debugging experience. For example, a user may want to always use the embedded Flutter Inspector but always use the browser version for the Performance and Memory page.

It could also be useful to have a button available in the embedded VS code experience that opens the current tool in the browser. This would conveniently allow the user to open DevTools in the browser if they feel that the embedded experience is not giving them enough space to perform the debugging they need.

[DanTup]

We currently have a setting that lets you choose where to open DevTools:

"dart.devToolsLocation": "active" // active, beside, external 

We could extend this to accept either a string as above, or an object where it can be set per-page (with a default):

"dart.devToolsLocation": {
  "default": "active",
  "cpu-profiler": "external",
}

We could then update the default value to be the object (as shown above) with whichever pages we think should open in a browser by default set that way. WDYT?

Do you have an idea of which pages you think would be better externally?

It could also be useful to have a button available in the embedded VS code experience that opens the current tool in the browser.

sgtm - I've split that into #4389.

[DanTup]

@kenzieschmoll any thoughts on the above? (the mechanism for controlling this, and which pages should open in which mode by default)?

[kenzieschmoll]

Having this be configurable through the settings sgtm. What is the difference between "active" and "beside"? It might make sense to make these a bit more clear if we are expecting users to set them.

Initially, maybe we could prefill each screen with a setting "default" that respects whatever the default setting is, and then users could configure this as they like instead of us getting opinionated right out the gate and upsetting users who want their default setting to be respected for each screen.

[DanTup]

What is the difference between "active" and "beside"? It might make sense to make these a bit more clear if we are expecting users to set them.

These descriptions show up in the tooltips (although how that appears might change a little if we change to object):

		"enum": [
			"beside",
			"active",
			"external"
		],
		"enumDescriptions": [
			"Open DevTools in beside the active editor",
			"Open DevTools over the top of the active editor",
			"Open DevTools externally in its own browser window"
		],

The current default is for everything to be embedded. We can keep that and let users control it, but I thought from the title we the goal was specifically to change this for some of the pages?

[kenzieschmoll]

The current default is for everything to be embedded. We can keep that and let users control it, but I thought from the title we the goal was specifically to change this for some of the pages?

After giving this more thought, I think at least giving users control would get us halfway there. We can put more thought into this in the future if we think users want us to be more opinionated. Are there analytics we can track to see how often user's are modifying these json settings?