Cross-Platform-OutGridView #203
Conversation
|
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 |
|
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. |
| ### Web | ||
|
|
||
| An interesting concept, particularly interesting for the ability to integrate directly into VSCode. | ||
| However, the dependency on having a browser pre-installed makes it less than ideal. |
There was a problem hiding this comment.
I don't understand this comment.
Certainly in the primary use-cases (core on Windows, core on Mac, core on WSL, core on Linux desktop) a browser will already exist. I find it unlikely that, in other cases where a graphical interface is needed, a browser won't exist.
I don't think it's reasonable to assume that Out-Gridview would be used in a nginx container. :-)
There was a problem hiding this comment.
Yes that's a fair point.
I will say...
Leveraging a web stack for a true Out-GridView that allows options like -PassThru to work is a lot of extra work because it involves having to leverage a web server in order to send the results from the web back to the PowerShell process which is hosting a web server.
I've personally looked into this, and it's a good chunk of work.
Leveraging a GUI framework that works nicely in process is much easier to manage.
There was a problem hiding this comment.
Przemyslaw did a great job with Out-HtmlView which is like Out-GridView but doesn't support PassThru - likely because he, like me, realized it's harder than first anticipated.
There was a problem hiding this comment.
Do you have metrics?
I use Out-HtmlView daily. Perhaps because I am aware of its limits, I do not feel constrained by those limits.
How often are other use-cases actually necessary?
There was a problem hiding this comment.
not sure if we have metrics but getting feedback at conferences... they need -PassThru. Lots of folks use it as a filter for what happens next in the pipeline.
example:
stop the processes you want.
Get-Process | Out-GridView -PassThru | Stop-Process
There was a problem hiding this comment.
-PassThru is absolutely necessary. Many IT scripts use it as a way to interactively select objects to act against (like a list of computers or users, etc...).
There was a problem hiding this comment.
I was certainly not coming out "against" -passthru as a requirement.
My point was (and is):
Certainly in the primary use-cases (core on Windows, core on Mac, core on WSL, core on Linux desktop) a browser will already exist. I find it unlikely that, in other cases where a graphical interface is needed, a browser won't exist.
There was a problem hiding this comment.
Right. The point is, though, that getting data back from a browser instance on the command line in a format that is usable (much less even remotely similar to what was originally put in) would be a bit of a tall order, I think.
There was a problem hiding this comment.
The wording of the RFC should be updated to shift focus from the "not having a browser" problem to the PassThru problem.
SteveL-MSFT
changed the title
|
@jzeiders 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.
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:
|
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.
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 ? |
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+ |
|
@TylerLeonhardt i saw it when i play with Avalonia package v0. 8 PS6.1 is EOL on September 28, 2019 |
Thanks! @jzeiders was experiencing an issue with Avalonia when he targeted netstandard2.0... We'll have to open an issue on them.
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". |
@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 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. |
No description provided.