Add QuickLook support

[VictoriousRaptor]

Refined version of #859. Too many merging conflict so I just create a new branch instead. Compatible with our preview function.

Changes

• Add a property FilePath for Result.Preview to indicate what file should QuickLook preview.
  • Explorer Plugin support
• An option to choose using QuickLook or not. Default is false.

Behavior

• Preview Hotkey is used to toggle QuickLook in Flow.
• If built-in preview is already open, QuickLook won't be triggered before user closes built-in preview. It's to deal with "Always Preview" option and switching between results that supports QuickLook or not.
• When a result has non-null Preview.FilePath try to use QuickLook to preview.
• Flow's preview and QuickLook don't open at the same time. If a result has non-null Preview.FilePath pressing hotkey only triggers QuickLook.
• When QuickLook is unavailable, a notification is sent to tell users to check status.
• QL is forcibly closed when hiding flow.
• If Flow "thinks" QL is open, a lost focus won't close Flow. This is to make sure users can interact with QL's UI controls. But when QL is closed by clicking its close button, opening QL again and interact with it will close Flow.

Problems

• Should "Always Preview" open QuickLook? No
• When "Always Preview" is on (which means internal preview is on), selecting another result that can use QuickLook triggers QuickLook. Looks bad.
• When "Use QuickLook" is on but QuickLook is not launched or installed what kind of warning should be send to users? Send a notification
• No QuickLook API to set on top. (Open selected result in quicklook #859 (comment)) Manually set it.
• Switching from external preview result to builtin result doesn't properly trigger builtin preview.

TODO

• Roughly tested but need some more tests and code review. Generally looking good so far.
• A better glyph in settings.

[Garulf]

Just got a chance to test run this. It looks very good! I have a few opinions on some of your problems listed:

Should "Always Preview" open QuickLook?

I don't think this works well with quick look as both windows overlap.

When "Use QuickLook" is on but QuickLook is not launched or installed what kind of warning should be send to users?

I think we can resolve this by greying out this option if a QuickLook installation is not detected. This can be tricky though as QuickLook is available in many different forms including the Windows app store.

Instead of tracking all this down we could send a pipe message and check its status to see if quick look is available and determine to enable the option.

No QuickLook API to set on top. (#859 (comment))

This was also an issue with the original PR.

[jjw24]

QuickLook functionality should be provided fully by a plugin. To achieve this we need to use this #1013, and this pr is a working POC already.

[Garulf]

QuickLook functionality should be provided fully by a plugin. To achieve this we need to use this #1013, and this pr is a working POC already.

I don't think @VictoriousRaptor was around for that. But yes as a plugin would be ideal.

Also I would use this PR in favor of my older code. This is more fleshed out.

[jjw24]

Maybe best that @VictoriousRaptor just continue work as is with this one so we can keep the momentum, once I helped onesound I will come back to finishing off that pr 1013 and migrate the finished code here into a plugin.

[VictoriousRaptor]

Maybe best that @VictoriousRaptor just continue work as is with this one so we can keep the momentum, once I helped onesound I will come back to finishing off that pr 1013 and migrate the finished code here into a plugin.

Ok I'll do some more tests on this PR and try to figure out the problems.

[VictoriousRaptor]

When "Use QuickLook" is on but QuickLook is not launched or installed what kind of warning should be send to users?

I think we can resolve this by greying out this option if a QuickLook installation is not detected. This can be tricky though as QuickLook is available in many different forms including the Windows app store.

Instead of tracking all this down we could send a pipe message and check its status to see if quick look is available and determine to enable the option.

Greying out option is good. And what if user enables this option (with QuickLook installed and running), and then quit QuickLook and preview in Flow? Should we fallback to Flow's preview? And what kind of message to tell users we are not able to launch QuickLook? Maybe a notification toast?

No QuickLook API to set on top. (#859 (comment))

This was also an issue with the original PR.

Not a big deal. Just manually set it once and for all.

[bluckholl]

Hi, @VictoriousRaptor,
Is this will support text files with other extensions, like. sql and. md?
Any estimation when it will be available on pre release?
If I want to try using this, I need to download this branch and build solution?
Thanks a lot for your great work 🙏

[taooceros]

Hi, @VictoriousRaptor, Is this will support text files with other extensions, like. sql and. md? Any estimation when it will be available on pre release? If I want to try using this, I need to download this branch and build solution? Thanks a lot for your great work 🙏

You can use the artifact build, but I think they expire now.

[VictoriousRaptor]

Hi, @VictoriousRaptor, Is this will support text files with other extensions, like. sql and. md? Any estimation when it will be available on pre release? If I want to try using this, I need to download this branch and build solution? Thanks a lot for your great work 🙏

Sorry I didn't see this message earlier. I just updated the branch and you can download the artifact build now.

[taooceros]

what's left for this one?

[jjw24]

This is good to demonstrate it can work, but I am not fond of having Quicklook specific code in the codebase for several reasons but main one is this doesn't extend/enable flow to be more capable.

I would still say use this PR #1013 to allow plugins to capture keyboard shortcuts so they can do more, and move this Quicklook specific code into its own plugin.

[taooceros]

This is good to demonstrate it can work, but I am not fond of having Quicklook specific code in the codebase for several reasons but main one is this doesn't extend/enable flow to be more capable.

I would still say use this PR #1013 to allow plugins to capture keyboard shortcuts so they can do more, and move this Quicklook specific code into its own plugin.

That makes sense. Though before we can capture the keystroke and have a relatively sophisticated model for registering hook for plugins, I think it's ok to temporarily make this inside the core?

[jjw24]

That makes sense. Though before we can capture the keystroke and have a relatively sophisticated model for registering hook for plugins, I think it's ok to temporarily make this inside the core?

Not that complicated, it's using the same model as what we currently have.

My main concern is to release this then having to take it away and have users install a plugin instead.

[onesounds]

Is this done? I haven't tested it. If it works, let's just include it.
In my opinion, this functionality does not need to be separated into a plugin. (most programs that support quicklook do. include fluent search.) Just include it as default code. I don't think it's complicated enough to be a plugin, and it don't requires any configuration. Of course, since we're using all the default features as plugins, it would make sense to go with plugins, but it's not required.
We should not delay features that work. Unless raptor makes it a plugin again, or someone else does, it's probably better to just merge this PR. Better to work on separating it into another PR later.

[jjw24]

Last time I tested it it has some bugs and there is no support for downloading and installing Quicklook for user.

[VictoriousRaptor]

Maybe the best idea is to use a separate hotkey to trigger QuickLook. Resolving conflicts with QL and our preview is annoying.

[jjw24]

Can't this be detected from user settings, preview -> built-in or QuickLook

[VictoriousRaptor]

Can't this be detected from user settings, preview -> built-in or QuickLook

This is the current implementation but logic to deciding to use which preview is not clear. I spent quite a lot of time on it.

I don't have time to review this PR this week so if we want to merge now it requires more detailed review from the team.

[jjw24]

Updated this PR with (see commits):

• support plugin with external preview via functionality interface.
• updated preview visibility logic.
• added a QuickLook plugin for testing, but will be a published standalone plugin and not merging with this PR.