microsoft
[Peek] Plugins engine/
Description of the new feature / enhancement
Peek was originally a similar copy of QuickLook. Right now, Peek is a slowly developing plugin within PowerToys. I have an idea to make inside Peek a manager of its plugins and prepare documentation, just like it is implemented in QL. This way the PT community (and it's not small) can write their additions and improve the program in a more simplified way.
Scenario when this would be used?
Suppose we have a bunch of Jupiter Notebook files, and we also have a plugin written by someone to view them. We quietly go through our notebook. Or I want to view an office file, such as word, we put the office plugin and without problems view the file we need without opening it.
Supporting information
No response
@davidegiacometti I'm sorry to tag, but the question is (if not to you, then I'm sorry again), will this feature be added? I just think it's not very convenient to commit each new file type to this repository all the time, but this way we can just make a separate repository of plugins for Peek
Hi @bropines, I agree that having Peek app extensible would be great, but it’s not a current priority. Since the initial release, we’ve added support for many file types and we welcome contributions for improving file support.
Implementation suggestion: allow 2 ways of creating plugins
- "low-level" plugin, using standard UI toolkit
- Webview plugin
Technically the second could be a separate boilerplate project built on top of the first, but this way it would increase complexity of implementations and duplicate code across (possibly) many plugins.
Webview performance will be 💩 ? Possibly, but its better to have something than nothing, and there's always the possibility of creating a "low-level" one if there is demand for such a plugin.
@romulof We already have WebBrowserPreviewer which wraps a web view and which supports HTML, PDF and Markdown, plus the formats that Monaco supports (which is lots). Is there a file type which you were expecting to see supported but which isn't?
As for "low-level" plugins, there is already an IPreviewer interface which the in-built previewers implement, with each exposing which file formats they support by using the IsItemSupported method. Each previewer has its own user control, which has the full WinUI 3 library available for rendering content. I don't think we'd benefit from another layer of abstraction like a UI Toolkit or similar. However we designed it, it would end up being a leaky abstraction.
The real questions here may be around discoverability and dynamic loading. The latter would be a fundamental change in how Peek works because it currently relies on all the previewers being loaded and available at startup. They're hard-coded in PreviewerFactory (an approach that needs replacing anyway).
I have some code which removes the hard-coding and supports dynamic loading of the existing previewers, as part of a wider refactoring project, but that's a way off from being ready. There are also open questions around whether such an approach would prevent full Ahead-of-Time compilation of Peek, which is something we'd like to do for all applications. Also: how would we distribute plugins? The MS Store, like for Command Palette?
Loading custom plugins is not off the cards, certainly, but it's just that it may be more complex than it initially appears because of having to do all the rearchitecting work first.
@daverayment, thanks for the info.
I would also suggest investigating caching. I know that Apple's QuickLook has a daemon what provides some level of caching, so when inspecting something that was inspected not too long ago and the file did not change in-between, re-use what was previously rendered.
I know this is close to impossible with WebBrowserPreviewer, as it is a whole engine running in the background, but offering some mechanism (opt-in) to store the last render as cache might produce good outcomes.