New and improved DevTools.

[grokys]

What does the pull request do?

Re-implements DevTools with a few new features:

• Adds a built-in console using roslyn scripting which allows running arbitrary code
• Allow editing of property values
• Improved display and grouping of control properties
• Filtering control properties
• Maintain selection when switching between logical/visual tree

Breaking Changes

Avalonia.Diagnostics is now a separate NuGet package so if you're using AttachDevTools you'll have to add a reference to that.

[kekekeks]

Adds a built-in console using roslyn scripting which allows running arbitrary code

Can we have that part to be pluggable? Preferably shipped in a separate package. So people won't need to ship the entire compiler with the app to use dev tools. Also not that it's not really linker-friendly and definitely not iOS-friendly

[grokys]

Can we have that part to be pluggable?

We could yeah, but I've got a bunch of stuff to finish that I think are higher-priority (such as ItemsRepeater as ItemsPresenter, fixing selection, fixing ScrollViewer etc) so I'm not sure when I'd be able to do it (this code was mostly already written, I just updated it to master and tidied it up a bit).

Given that, I think there are a few options:

• Keep current devtools until I can make the console pluggable
• Merge this devtools but remove the console for now
• Tell people to #if the call to attach the devtools if they don't want a dependency on roslyn scripting

Not sure what people would prefer?

not that it's not really linker-friendly

Are you talking about CoreRT here?

[Gillibald]

Apps don't rely on DevTools so it's fine if the console breaks on iOS. I am sure there will be a solution for iOS the moment iOS support is stable.

[MarchingCube]

I think new DevTools are quite a step forward as it is much more usable interface. Console is also really handy for development. We should give an option to the people to completely remove it, maybe entire diagnostics needs to be pluggable in the end. But for now since we just released new version I think it will be fine to have this for a while until we come up with an idea for separating this feature.

[kekekeks]

Avalonia.Diagnostics library is a part of Avalonia package. So this change effectively adds a dependency on Microsoft.CodeAnalysis.CSharp.Scripting to every single avalonia-based application.

[Gillibald]

And why exactly do we need a dependency on Avalonia.Diagnostics in the core of Avalonia? I think that is the only issue here. This is not required to run an application.

[grokys]

Note that Avalonia.Diagnostics now also has a dependency on Avalonia.Control.DataGrid.

Thing is, afaik there's no so thing as "Debug build-only" dependency. You either have the dependency or you don't. The best you can do it to not reference code in the dependency when you don't want to ship it. Or am I mistaken?

[grokys]

NuGet/Home#5895

[pr8x]

Hi I tested your PR locally and it seems to be working fine so far, except some smaller things.

• Editing Color (via hex value), Size and some other types is broken
• I would suggest adding the Type of the property (Property.PropertyType.Name) in the DataGrid as well. This will make editing a bit easier, because you don't have to manually lookup the type of the property. Also making the column headers visible and resizable would be great as well.

• The GridSplitter on the event page seems to be locked somehow - You can't move it.

[MarchingCube]

One extra potential improvement: Allow for searching for event types in the Events tab. It quickly gets tedious to find wanted event type every time you open DevTools.

[kekekeks]

Note that Avalonia.Diagnostics now also has a dependency on Avalonia.Control.DataGrid.

We probably need to extract it to a separate package then.

[grokys]

This is now ready for review, I've made most of the suggested changes:

• Avalonia.Diagnostics is now a separate package
• Added "Type" column to show property type
• Editing colors, sizes etc now works

I didn't add the filter to the Events tab yet as that's a bit more involved and I'd like to get this finished for the moment so I can continue with other things.

Note that the DataGrid highlight color is currently set to the same as the TextBox highlight color so editing values looks a bit wrong, see #3564 (comment)

[MarchingCube]

Glanced over, submitting my immediate feedback and I shall return later to evaluate it further :)

Functionality wise LGTM.

[MarchingCube]

Any reason why half the files have license header and half do not?

[grokys]

Simply, the ones where I modified an old file still have headers. I don't bother adding headers to files these days as it just feels like busywork and from what I've read legally it's meaningless.

[grokys]

Maybe I should delete existing headers on modified files? Not sure.

[MarchingCube]

TBH it would be good to be consistent at least. I have no problem with or without license info as long as we stick to one option.

[MarchingCube]

Looks like a great improvement over current one so I see no reason to not merge this in :)

[kekekeks]

Note: we still need to make Roslyn dependency optional if we want devtools to be operational on iOS/WASM.

[grokys]

TBH, I'm not sure how useful it would be there anyway, but yeah we can think about that when the time comes.

[kekekeks]

For mobile the idea was to use our previewer protocol. You know, that one that can show our controls in browser.

[Gillibald]

Currently the app itself shows the dev tools on demand. Why not make this a service you can connect to? So we could integrate this into the Visual Studio Extension or have it standalone.

Snoop for example could just inject itself into the target application and it just worked.