BUG: Preview inconsistency with QuickLook

[nanoraptor]

SCREEN_REC.mp4

When I close the preview from the QuickLook, the preview panel is not going away and is very annoying when I hover my cursor over the results. It is prettty self explanatory and reproducable.

Problem Description

I have raised the same issue on the plugin's page. I don't think I am gonna get any reply there. So, I'm duplicating the issue here.

Description

The inbuilt preview panel in flow launcher and preview from QuickLook Plugin makes an inconsistency in previwing files in Flow Launcher. (The preview for programs and other non-file contents are still seen). This also 'forces' me to disable always preview setting in Flow Launcher while having the QLplugin enabled.

Possible Solution

Disable Inbuilt preview while QuickLook is on and vice versa
See QuickLook is a plugin to preview files and explorer related contents. For example, when I jump from a file result to a program result (When QL preview window is already open), it should not trigger the preview of that program in the flow launcher's preview panel even if the user has set always preview on, then those programs can only previewed by disabling QL (Using alt+P)(incase of always preview being on, else it should not turn the preview on). This can be done by separating the shortcuts/call for QL preview and Inbuilt preview of Flow Launcher.

• Conditions
  Even If the inbuilt preview is enabled it should not trigger QuickLook and similarly when QL is on it should disable inbuilt preview even if it is turned on already and should return the setting of default preview(on/off) when it is turned off
  It even makes sense logically as when we are previewing files we don't want the inbuilt preview to interrupt us by showing preview of a program which is useless in that context as the icon of the program is already visible.

Always preview should not trigger QuickLook
It's simple and I guess by following the above steps this will be automatically factored in. QL can only be enabled by only the shortcut. There should be a setting for always preview for QL else it has to be enabled everytime the launcher opens.

*Additional Feature
There should be a shortcut in which holding down the keybinding enables preview and letting it go will close the preview window. Just like what holding down the spacebar in File Explorer does using QL. This reduces jumpiness of the previews and not having to close the QL window everytime to see the file blocked by the window. This should be in addition to what I requested earlier.

An additional thing would be to allow third party plugins to use quicklook as well. So, that it is not only limited to explorer plugin. Ignore this if this is already available.
Any improvisations or ideas for this issue will be highly useful to the developer.

[jjw24]

Do you have always preview turned on?

[jjw24]

You can press ESC to close the QL preview window instead of using the mouse.

[nanoraptor]

Do you have always preview turned on?

No

[nanoraptor]

You can press ESC to close the QL preview window instead of using the mouse.

Yea, It worked but when I control something on the QuickLook window using mouse (e.g. Media Playback) I find it easier to click the cross button rather than pressing Esc key.

[jjw24]

Yeah I understand.

I am afk, but if I remember correctly this is where QL doesn't provide a way to check whether its window is opened or closed, so flow's own code can only manage properly the state when user uses esc/preview hotkey to toggle open/close, and under the hood flow manually tracks the state. This is where if you close the window with the cross, flow won't know that the window is closed and still thinks preview is still on and when you move the mouse afterwards it switches to the preview of another result.

[nanoraptor]

Is it possible to introduce a shortcut that enables QL only while the keybinding is being pressed #4.

[jjw24]

Yes we can either make it default behaviour where if third party preview is used don't use the built-in, or make this an option to use one or both. No need for a keyboard shortcut.

This won't solve the root cause of your problem though because the actual desired behaviour is when always preview is off and you close the preview window with the cross, no preview should be further triggered with the mouse or up down arrow until you reactivate it again (which is the behaviour of closing with ESC/preview hotkey). I guess though in light of what's beyond our control, implementing issue 4 at least helps alleviate your UX problem.

[nanoraptor]

Yes we can either make it default behaviour where if third party preview is used don't use the built-in, or make this an option to use one or both. No need for a keyboard shortcut.

This won't solve the root cause of your problem though because the actual desired behaviour is when always preview is off and you close the preview window with the cross, no preview should be further triggered with the mouse or up down arrow until you reactivate it again (which is the behaviour of closing with ESC/preview hotkey). I guess though in light of what's beyond our control, implementing issue 4 at least helps alleviate your UX problem.

Even after pressing the ESC key, If I hover my cursor to a non explorer result and back to the explorer result, preview window pops up. It is only really turned off by Alt+P.

[jjw24]

If you use only the preview hotkey, assuming it's your Alt + P, it should turn on off properly. I just tested using only preview hotkey and escape, the preview turns off until you toggle with the hotkey again.

[nanoraptor]

QL_BUG.mp4

As you can see when I close quicklook using ESC key when I scroll to a non explorer result the preview turns back on.
I pressed the ESC key at 0:17 and did not trigger the plugin afterwards. But it gets reactivated once I switch to a non-explorer result.

[nanoraptor]

If you use only the preview hotkey, assuming it's your Alt + P, it should turn on off properly. I just tested using only preview hotkey and escape, the preview turns off until you toggle with the hotkey again.

That's what I was telling too. I can only use the alt+P to close the QL from coming up again. But when I interact with the QL window, I need to click flow launcher to get back the focus on the window then press alt+P to remove preview(Pressing ESC does not gurantee to turn preview off as you can see in my previous comment). This should not happen I should be just able to click the esc and close the quicklook window. It is an unwanted process.

[jjw24]

Yeah I think you are right, in my testing looks like only the preview hotkey guarantees properly closing of preview.

Escape doesn't properly turn off due to the fact that it tells QL to close the window, but flow doesn't know that the QL window is closed because there is no feed back to flow or an ability for flow to check QL's window status. This means flow thinks preview is still on and you are just switching to previewing other results. Under the hood the switching preview code is still called every time you hover to a result, it's not showing the QL window because the call sent to QL is for switching, which is ignored by QL process because it's already close the preview window. When you are hovering to a result that can only be previewed by the built-in preview, the switch is successful because it switches to the built-in, that's why you still get the built-in preview.

In a nutshell, if QL can provide a command to return the status of the preview window is opened/closed, this whole experience will be significantly better.

[nanoraptor]

So, the feature cannot be implemented properly???? QL is not updated in a long time. It would've been better to integrate powertoys peek in the plugin as it is constantly getting updated. However I prefer QL more. Is it possible for you/other devs to update this specific part of the QL's code and upload it especially for Flow launcher. If this issue is solved then there is nothing much to change in QL.

[jjw24]

I think QL is a great app and I'd much rather to encourage these changes (save position + window open status feedback) over at repo, or at least get a reply from the authors that they won't add/willing to accept PRs.

[nanoraptor]

I think QL is a great app and I'd much rather to encourage these changes (save position + window open status feedback) over at repo, or at least get a reply from the authors that they won't add/willing to accept PRs.

I do think it's a great app. But, I don't think the authors are gonna help in this one. They haven't been replying to issues for about a year. If you look at the repo it is full of feature requests and enhancements and the plugin support.