I'm not sure if this feature already exists in the status quo. If it does, please let me know.
tl;dr Do 3rd Party plugins have the ability to invoke Out of the Box Plugins to process compatible native file types (such as .png files)? If not, can this functionality potentially be added?
For creating previews of some extension types that are not included Out of the Box, sometimes all that needs to be done is to add some logic for the new extension type in order to simplify the problem to something that an existing Out of the Box (OotB) Plugin is able to handle.
For instance, take the .kra extension, which is the saved form of projects created by the Krita painting and animation application.
As described in this linked feature request (https://github.com/QL-Win/QuickLook/issues/912), .kra files are essentially zip archives that contain (among other things) previews of the rendered file in .png format.
Using some logic code, I was successfully able to extract a relevant .png preview file to a location in the temp folder.
Since .png is supported Out of the Box with the Image Viewer plugin (https://github.com/QL-Win/QuickLook/tree/master/QuickLook.Plugin/QuickLook.Plugin.ImageViewer), it would be great if there was a way to invoke it to present a preview of the temporary file as the preview of the larger .kra file without having to recreate the Image Panel class or any of the other relevant helper libraries.
Describe the solution you'd like
It would be really helpful if there were some way to invoke the existing Out of the Box plugins when a simplified, compatible version of other filetypes is derived from a different file type. This would allow new plugins to be created to cover (among other things) application-specific file types that are simply an existing, compatible file type with additional application-specific functionality. (Please see footnote 1 for examples of other filetypes I think this would allow more efficient implementation of).
Describe alternatives you've considered
The alternative in the status quo that I've been considering have been to either try and dissect the OotB plugin for the relevant info to recreate the intended effect for the simplified file type, or to copy the OotB code in full and add new logic for the specific filetype that you are trying to add compatibility to. Especially because most of the OotB plugins provide support for a plethora of file types, the code is difficult for the unfamiliar to dissect and extract a specific functionality from and implement into a smaller scope.
Another alternative would be to rewrite the original OotB library as a plugin to include logic for the specific new filetype, and to make this a higher Priority Number than the original as to override functionality. The main drawback with this method is that it would result in plugin files much larger than they otherwise need to be, in addition to adding a truckload of redundancy to the application as a whole.
I can clarify or add details as needed. Thank you for taking a look at this!
Footnote 1.
Examples of other file formats that could benefit from this include
Other applications with similar .png previews in their custom file type (Examples include Musescore's . .mscz file extension (which also includes a visual .png preview of the sheet music it contains)),
Various application-specific skin/ theme file types (as they typically are just collections of .png files, of which one significant subfile could be chosen to represent the larger package; examples include DaVinci Revolve's .fuskin file type, and REAPER's .ReaperThemezip file type),
Firmware update files (these often contain some sort of manifest file in .txt or .md format with information about the firmware contained, which could be routed to the OotB TextViewer or MarkdownViewer plugins respectively after some initial logic; examples include Texas Instrument's .tcc2 and .tco2 file types for updating TI-Nspire calculators).
These are just some examples I found in an hour of searching my hard drive; I am certain that there are other categories of file types that could benefit from a feature like this as well.
I'm not sure if this feature already exists in the status quo. If it does, please let me know.
tl;dr Do 3rd Party plugins have the ability to invoke Out of the Box Plugins to process compatible native file types (such as
.png
files)? If not, can this functionality potentially be added?For creating previews of some extension types that are not included Out of the Box, sometimes all that needs to be done is to add some logic for the new extension type in order to simplify the problem to something that an existing Out of the Box (OotB) Plugin is able to handle. For instance, take the
.kra
extension, which is the saved form of projects created by the Krita painting and animation application. As described in this linked feature request (https://github.com/QL-Win/QuickLook/issues/912),.kra
files are essentially zip archives that contain (among other things) previews of the rendered file in.png
format. Using some logic code, I was successfully able to extract a relevant.png
preview file to a location in thetemp
folder. Since.png
is supported Out of the Box with the Image Viewer plugin (https://github.com/QL-Win/QuickLook/tree/master/QuickLook.Plugin/QuickLook.Plugin.ImageViewer), it would be great if there was a way to invoke it to present a preview of the temporary file as the preview of the larger.kra
file without having to recreate the Image Panel class or any of the other relevant helper libraries.Describe the solution you'd like It would be really helpful if there were some way to invoke the existing Out of the Box plugins when a simplified, compatible version of other filetypes is derived from a different file type. This would allow new plugins to be created to cover (among other things) application-specific file types that are simply an existing, compatible file type with additional application-specific functionality. (Please see footnote 1 for examples of other filetypes I think this would allow more efficient implementation of).
Describe alternatives you've considered The alternative in the status quo that I've been considering have been to either try and dissect the OotB plugin for the relevant info to recreate the intended effect for the simplified file type, or to copy the OotB code in full and add new logic for the specific filetype that you are trying to add compatibility to. Especially because most of the OotB plugins provide support for a plethora of file types, the code is difficult for the unfamiliar to dissect and extract a specific functionality from and implement into a smaller scope. Another alternative would be to rewrite the original OotB library as a plugin to include logic for the specific new filetype, and to make this a higher Priority Number than the original as to override functionality. The main drawback with this method is that it would result in plugin files much larger than they otherwise need to be, in addition to adding a truckload of redundancy to the application as a whole.
I can clarify or add details as needed. Thank you for taking a look at this!
Footnote 1. Examples of other file formats that could benefit from this include
.png
previews in their custom file type (Examples include Musescore's ..mscz
file extension (which also includes a visual.png
preview of the sheet music it contains)),.fuskin
file type, and REAPER's.ReaperThemezip
file type),.txt
or.md
format with information about the firmware contained, which could be routed to the OotB TextViewer or MarkdownViewer plugins respectively after some initial logic; examples include Texas Instrument's.tcc2
and.tco2
file types for updating TI-Nspire calculators).These are just some examples I found in an hour of searching my hard drive; I am certain that there are other categories of file types that could benefit from a feature like this as well.