So, after the last project log, it looks like I will have to backtrack to WPF/winforms.
So now, I'm spending my time looking for a syntax highlighter for powershell. For the most part I have been successful.
It looks like the only good ones out there are the ones used by Microsoft. Luckily, at least one of these "highlighters" is open source: PSReadLine.
PSReadLine is a ReadLine parser for PowerShell, and comes included with most instances of PowerShell. It provides a variety of handy features, such as text completion, shell history, and most importantly syntax highlighting.
While I did not make a lot of progress today, I'm hoping my research into PSReadLine will be time well spent
Originally, I thought I was locked down to PowerShell's access to C# and XAML, but with WebView2, I can now use my knowledge of Web Dev, to get this moving faster, except... that WebView2 currently has no support for linux :(
But Photino does! For now, we will write the app using Photino, but backtrack to WebView2 progressively to keep this app MS-purist (keeps the code enterprise-friedly)
I had to make this move, because I could not find any good syntax highlighters for WPF. However, I know of plenty written for HTML.
In terms of performance, going to web tech seems like a down grade, but Edge Chromium is supposed to be extremely performant, and Photino claims to be more performant than Edge!
Hopefully, this will be a "profitable" move -if only I were making money doing this :(
So, I want the UI to mimic the default PowerShell App for the platform. Since, we are currently only designing the menu for Windows PowerShell The GUI will look like it was pulled straight from that application.
I want to have the UI blackened for Ubuntu. I want to also see, if I can implement a detection script that checks for Windows Terminal, and matches the theme.
The first thing that needs to be done is to give PowerShell support for XAML (PresentationFramework) and NotifyIcon/ApplicationContext (System.Windows.Forms):
We will use Application Context to keep the script running, and prevent NotifyIcon artifacts (If we don't run an application context, notifyicon may persist to run even once the powershell script exits)
To create the App Context, initiate it as an object (we will invoke the .run() method at the end of the script):
In Trevor's article, he created the systray icon under the "$Script:" scope, but since this app is gonna serve as a powershell command palette, why not leave it in the global scope for automation?
Now, to make the icon right-clickable:
$QuickTray.Add_MouseDown({
if ($_.Button -eq [System.Windows.Forms.MouseButtons]::Right)
{
<# run some code here... #>
}
})
Now, if you only want a single powershell script to run replace the script with your own code. If not, we will cover creating the WPF/XAML portion of this app in Part 2.
For now, to test that it works you can replace the comment with this:
[System.Windows.MessageBox]::Show("Hello World!")
Now, let's go ahead and see what this looks like by starting the app with these lines:
I want my first set of quick commands to be selenium-based. I need to select a good module/package/library for using them. I would like to use the NuGet version, but I can't quite remember what was required to get that one going... I'll find that out before my next log for the weekend
**NOTE: at time of this log, this command invokes the V2 API despite the V3 API being available. Currently, while that is true, the V3 API isn't as widely supported yet, so V2 is still currently the "most stable"
To check your work, run these commands:
Get-PackageProvider;
Get-PackageSource;
If you need to unregister a package source, you can do so with:
Unregister-PackageSource -Name XXXX
where XXXX is the name listed from Get-PackageSource.
As far as I currently know, the provider field/property returned from Get-PackageSource should match one of the names from Get-PackageProvider