What additional disk space requirements would be imposed by using the Avalonia framework? If this results in a significant increase to overall package size, maybe this should be built as a standalone module, in which case would this RFC even be required (although the discussion that comes out of it may be useful)?

The initial intent is that this will ship in the Gallery. The RFC was submitted because it's such a high-profile cmdlet and the discussion will be useful.

I'll let @jzeiders answer the size question.

This looks good especially as it looks like it will be part of a new module which would be on the gallery, which would potentially also allow down level use if all components are packaged with it.

@KirkMunro I guess this would end up being a module that would be added to an inclusion/exclusion list depending on which flavour of PowerShell you go for like @Steve_MSFT has suggested previously in
PowerShell/PowerShell#5681

I like the idea of having a separate module for this. I'm a bit worried though about the fact that the framework only supports 'western' locales, so this will leave out quite some folks that use non-Latin locales on their system. But besides that I'd like to see a first mvp that can be tried.

Avalonia plus dependencies weighs ~186 MB. That hurts a little bit, even in its own module, but the plan is to amortize that over future graphical commands.

@jzeiders Do this RFC support raspberry arm/arm64 ?
What is the backend api on each plateform ?
Do we plan to use GTK for all plateforms or use each native OS UI ?

@fMichaleczek

Do this RFC support raspberry arm/arm64 ?

Looks like it works but it’s a bit clunky at the moment. We’ll probably need to test on a raspberry pi and see what additional stuff we’ll need to do.

What is the backend api on each plateform ?
Do we plan to use GTK for all plateforms or use each native OS UI ?

We live on a layer above this (Avalonia) so this question is more of an implementation detail. That said, here’s what Avalonia’s website says:

We currently have Win32, GTK3 and MonoMac windowing backends plus Direct2D and Skia renderers.

@TylerLeonhardt

looks like it works but it’s a bit clunky at the moment.

The last comment said it works but you have to handle the fonts. That seems normal as Raspberry has a light linux distribution. There is only an arm32 native version and i don't know if it's compatible with arm64. I will try with my prototype written in PowerShell and give feedback.

We live on a layer above this (Avalonia) so this question is more of an implementation detail.

I ask because of the impact on package size.

The RFC doesn't define the targeted PowerShell version(s), it's also an implementation details at this step ?

The RFC doesn't define the targeted PowerShell version(s), it's also an implementation details at this step ?

Expect this to be v7+

Whether that is v7 or v7.1 etc is likely to be determined at later date

@kilasuit This RFC is a module, it's why i ask about target compatibility. Avalonia is compatible with net461/netcoreapp2.0/netstandard 2.0.

Notice that we need to bring back STA before using WinForm.

@fMichaleczek where did you see that Avalonia is compatible with netstandard 2.0?

This will for sure be 7+
possibly 6.2
maybe 6.1
doubtfully 5.1

@TylerLeonhardt i saw it when i play with Avalonia package v0. 8

https://github.com/AvaloniaUI/Avalonia/blob/f5ccc5667e8e1deb0a7e3561684813018e71b397/packages/Avalonia/Avalonia.csproj#L3

PS6.1 is EOL on September 28, 2019
and for PS5.1, i didn't find any EOF ;)

@TylerLeonhardt i saw it when i play with Avalonia package v0. 8

Thanks! @jzeiders was experiencing an issue with Avalonia when he targeted netstandard2.0... We'll have to open an issue on them.

PS6.1 is EOL

EOL doesn't play in here. Just because it's supported, doesn't mean we have to support that version with this module since it's a new "feature".

EOL doesn't play

@TylerLeonhardt As a sysadmin, i have white and black vision about security, if a product's version is EOL, there is no more security updates and it's very weird to add feature on it.

I think @TravisEz13 can confirm.

I agree with what you said. I think we’re saying the similar things.

This will for sure be 7+ because it’s the future
possibly 6.2 since Avalonia supports netcoreapp2.1
maybe 6.1 since Avalonia supports netcoreapp2.1
doubtfully 5.1 because it already has an ogv but if we get netstandard2.0 working with avalonia, then maybe things will just work, but it’s not high pri.

Keep in mind, we’re not adding anything to PowerShell. This will ship on the Gallery.

6.1 is not EOL. 6.1 is in servicing, 6.2 is the stable branch.
https://docs.microsoft.com/en-us/powershell/scripting/powershell-support-lifecycle?view=powershell-6#powershell-release-end-of-life

Most functional fixes only go to the stable branch.
The servicing branch only gets security fixes, unless there is a very good reason.