Related to #41384
We should load the `IDetails` from a `IListItem` in the slow pass,
instead of immediately when we load the list of items.
see also #39215
Also adds a lot of logging on our side, which helped ID that it isn't
our fault that the winget APIs are returning slowly. That's tracked
upstream (somewhere)
Seems as though that doing `.ToArray` on the `IIterable<>` things we get
back from the winget API were not trim-safe. I'm not entirely sure why.
But we're totally okay just manually iterating over these things. That
works like a charm.
Closes#41172
As a drive-by, I wrapped the line from #41025 in a try-catch. If that
doesn't fix it, hopefully it at least gives us more logging.
What the title says. 😄
Rather than relying on the potentially overloaded `!=` or `==` operators
when checking for null, now we'll use the `is` expression (possibly
combined with the `not` operator) to ensure correct checking. Probably
overkill for many of these classes, but decided to err on the side of
consistency. Would matter more on classes that may be inherited or
extended.
Using `is` and `is not` will provide us a guarantee that no
user-overloaded equality operators (`==`/`!=`) is invoked when a
`expression is null` is evaluated.
In code form, changed all instances of:
```c#
something != null
something == null
```
to:
```c#
something is not null
something is null
```
The one exception was checking null on a `KeyChord`. `KeyChord` is a
struct which is never null so VS will raise an error when trying this
versus just providing a warning when using `keyChord != null`. In
reality, we shouldn't do this check because it can't ever be null. In
the case of a `KeyChord` it **would** be a `KeyChord` equivalent to:
```c#
KeyChord keyChord = new ()
{
Modifiers = 0,
Vkey = 0,
ScanCode = 0
};
```
Just standardizing built-in extensions to use a `internal sealed class
Icons` for all their non-dynamic icons.
Looks like a LOT of changes, but it's icons all the way down.
**WARNING:** This PR will probably blow up all in-flight PRs
at some point in the early days of CmdPal, two of us created seperate
`Exts` and `exts` dirs. Depending on what the casing was on the branch
that you checked one of those out from, it'd get stuck like that on your
PC forever.
Windows didn't care, so we never noticed.
But GitHub does care, and now browsing the source on GitHub is basically
impossible.
Closes#38081
