Adds QOI support to Peek

[pedrolamas]

Summary of the Pull Request

Adds QOI image files support to Peek!

Light theme

Dark theme

PR Checklist

• Closes: Add QOI support on Peek #29918
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

A couple of notes on this PR:

• I moved the QoiImage and Gcode* classes from PreviewHandlerCommon to FilePreviewCommon, and by doing that, I had to enable <UseWindowsForms>, <AllowUnsafeBlocks> and <Nullable> on the project.
• As I enabled nullable types on the step above, I fixed all the nullable issues on FilePreviewCommon
• FilePreviewCommon has been added as a project dependency to:
  • GcodePreviewHandler
  • GcodeThumbnailProvider
  • QoiPreviewHandler
  • QoiThumbnailProvider
• IFileSystemItemExtensions.GetQoiSize is just going directly to the bytes where we expect the "width" and "height" of a QOI image to be. I did not add a file header validation, but that should be rather trivial to do as it is already implemented in QoiImage.
• BitmapHelper.GetBitmapFromHBitmapAsync has been refactored so that I could extract the code that converts a System.Drawing.Bitmap to a Microsoft.Xaml...BitmapSource <- you might want to take a good look at this one to make sure all is ok!

I understand that Peek can now show Preview Pane Handlers directly, but considering #26726, I think it best to prepare to a situation where PT stops supporting the Preview Pane Handlers completely

Validation Steps Performed

Manual validation with the test images pack in https://qoiformat.org/

[htcfreek]

@pedrolamas
Isn't it ready? Then we can remove the review label. Thought it was ready.

[pedrolamas]

@htcfreek from my part, this PR is ready to go!

[jaimecbernardo]

Thanks for opening the PR, @pedrolamas .
At this moment, we're thinking of reviewing the contribution for 0.77 only. Sorry for the delay. 😄

[pedrolamas]

No problem, thanks for letting me know, @jaimecbernardo

I will try and keep the branch in sync with main branch to make sure it does not have conflicts.

[stefansjfw]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jaimecbernardo]

Hi @pedrolamas ,
Thank you for the contribution!
I've tested and it seems to look good, but it seems to bring a regression:

When the preview pane is on a qoi file, you can't delete that file. This was OK in 0.76.0, it seems. Can you please look into it? I suspect the refactor caused some resources to not be freed correctly.

[jaimecbernardo]

I've merged latest main in and added QOI to the notice section about Peek as well. Running a Dart CI test to check if it still builds OK for release.

[pedrolamas]

When the preview pane is on a qoi file, you can't delete that file.

Thanks @jaimecbernardo, I have a feeling this is due to the fact I changed the BinaryReader in QoiReader to leave the stream open (in theory that makes sense to me as I would expect the stream to be closed upstream, but maybe that is not the case?)

[pedrolamas]

@jaimecbernardo I have now fixed the problem by adding a using to the file stream

https://github.com/microsoft/PowerToys/pull/29919/files#diff-1d420d0e6cfb94016296228da268defbf9677c8414f378b21b45abb19ce22779R66

For the record, my thinking here is that if the Image.FromStream method leaves the stream open, I think it is reasonable to expect the same behavior from QoiImage.FromStream, hence why I changed the BinaryReader to leave it open.

Disposing the FileStream in this case solves the problem very nicely, and I would argue that it is reasonable that (where appropriate) the same change should be made on ALL other preview handlers, what do you think?

[jaimecbernardo]

Solves it for me. Not sure 🤔 . The other previewers don't seem to be suffering from the same issue.

[jaimecbernardo]

LGTM! Thank you for the contribution!