Drew Naylor comments

Results 218 comments of


                                            Drew Naylor

Major known issue: Apparently the unofficial ProtonMail desktop client's locale manifest's resulting filepath when extracted is too long for Windows without using the long file paths Registry key.

I have just improved this so that it properly stops letting you know that it couldn't extract files with paths that are too long if long file path support is...

Major known issue: Apparently the unofficial ProtonMail desktop client's locale manifest's resulting filepath when extracted is too long for Windows without using the long file paths Registry key.

It's in v0.4 now.

Maybe plugins would be useful, perhaps with features like getting the package list?

Could probably use VS-MEF, as it's apparently the newest iteration of MEF and supposed to be the fastest when caching the list of plugins being used or something: https://www.nuget.org/packages/Microsoft.VisualStudio.Composition I...

Maybe plugins would be useful, perhaps with features like getting the package list?

Should probably restrict the ability to load and use plugins/extensions to when we're running from Program Files/Program Files (x86), like Notepad++. Not sure how to handle portable installs, if anyone...

winget now has the ability to pin package versions, so I should add menu items to pin, unpin, and list pinned packages.

Actually, the way I can do this is by having "Pin package..." and "Unpin package..." items in the package context menu and the menubar menu, which both open a window...

The winget PowerShell commandlets now use C#, so I should add an option for people to use them instead of my own code where available (mainly when getting the list of available packages, which would be way faster and I should be able to still get manifests somehow, or at least the descriptions and most-used parts of the manifests, out of another command).

Wait, I could just do the command and have PowerShell convert it to JSON without having to add PowerShell's libraries directly and I can keep using .NET Framework. Just will...

The winget PowerShell commandlets now use C#, so I should add an option for people to use them instead of my own code where available (mainly when getting the list of available packages, which would be way faster and I should be able to still get manifests somehow, or at least the descriptions and most-used parts of the manifests, out of another command).

Wait, they don't have a way to get the description yet, so I'd have to still deal with the winget.exe output or extract the manifests. Could always do that thing...

The winget PowerShell commandlets now use C#, so I should add an option for people to use them instead of my own code where available (mainly when getting the list of available packages, which would be way faster and I should be able to still get manifests somehow, or at least the descriptions and most-used parts of the manifests, out of another command).

Oh, I just realized I can use this to say which applications in the list are installed using `Get-WingetPackage` (will probably have to go check each package against that commandlet...

When updating the progress bar while loading the package list, get the length of the number of packages we need to load minus 1 or maybe 2, and use that many zeroes after a 1 so it scales better if the total number is larger than what I already accounted for so it doesn't update the UI as often.

Probably would have to ensure we sync the threads or something when updating the progress bar so there's no race condition. Delegates would be necessary to prevent cross-thread issues.

Try using a different thread to go through the list of packages to add packages to the DataGridView so we don't have to lock up the UI, and use events from that thread to update the progress bar.

I'd have to use delegates for this so that it doesn't complain about cross-thread stuff. Maybe a thread-locking thing, too. Would need to do the same for #170 somehow, too....