Jump to content
GuiB

Bug with sending to an Input Object after using QuickLook [Fixed 3.5 b867 pre-release]

Recommended Posts

There's a bug with Input Objects when arriving into one after having looked at a file using QuickLook in a Script Filter. Or maybe it's just the way the Script Filter is sending to the other objects...

 

In short, when accessing a file using a script filter, everything works great if I don't press the shift key to have the quicklook popup to see the content of the file (the flow goes to the next object in the Workflow has it should). However, if I QuickLook the file, then after pressing enter to go to the next object in the Workflow, then I see Alfred reappear, but closes immediately. Also, with most objects this is happening when I change the {query} to an empty one using a "Arg and Vars" object, but the "Call External" sending into an "External" object to go into another input object, then just the sending break the flow.

 

Here is a workflow to show you multiple situations. Again, it is not working just when you press 'shift' to have the QuickLook popup. If you try without showing the QuickLook, then everything works.

 

https://nofile.io/f/ySkDQe6D1Cd/QL+Problem+When+Sending+to+Input+Objects.alfredworkflow

 

Procedure to reproduce the bug:

(it's the same procedure using 'qlt' or 'qlt2' or 'qlt3' -> the different keyword for the Script Filter)

  1. Pop Alfred (alt+space or your keyboard shortcut for it)
  2. Type the script filter keyword: qlt (You should now see a "Desktop" item in Alfred)
  3. Use QuickLook on the "Desktop" item (press: shift or cmd+y)
  4. Close the QuickLook popup (using 'shift' again or the escape key)
  5. Press Enter to go into the next object in the flow (the flow should break)

 

Let me know if something isn't clear enough! I'm using this kind of flows to work with files, so I like having a look at some of the files when I navigate.

 

Like always, thanks for your help :) 

 

P.S. I have tested sending to some other objects and this seemed to be fine; ex: post notification or LargeType object work fine, but may have missed some that didn't work. But it seems to be only when sending to an object that pop Alfred again

 

[ Using Alfred 3.4.1 build 860 ]

Edited by GuiB

Share this post


Link to post
Share on other sites

Double-clicking the connection coming out of your first Script Filter(s) and selecting "Don't close the Alfred window on actioning result" fixes the issue (i.e. Alfred stays open).

 

I realise there's technically still a bug, but you should be selecting the above option whenever you pass control from one visible element to another to stop the "flash" of Alfred closing then re-opening.

Edited by deanishe

Share this post


Link to post
Share on other sites

Great, thanks @deanishe for the tip! I didn't use this feature yet

 

However, this help partially and seems to only work when not actioning with a modifier key (when this modifier key is set inside the script filter). I often use a modifier key when pressing Enter to navigate in my Workflow. But, as an example, here is a new version of the workflow with a script filter that looks a little more how I use it ('qlt4'), the normal actioning with just Enter works fine with your tip, however the flow still breaks when actioning with the 'shift' key. It seems to break since the 'shift' key action is specified inside the script filter and not outside like the 'alt' key (who is set outside and working also with your tip)

 

Workflow: https://nofile.io/f/weodEKn3o2M/QL+Problem+When+Sending+to+Input+Objects.alfredworkflow

 

Share this post


Link to post
Share on other sites

Heh. Looks like @Andrew's gonna have to fix it then :) 

 

Wonder what the difference is between setting the modifier via JSON and explicitly on the connection. In any case, I use modifiers-via-JSON a lot, so I guess many of my workflows are also affected by the issue, even though nobody has ever noticed it before.

Share this post


Link to post
Share on other sites

Interesting, and a simple logic issue to fix in Alfred's framework. Essentially, when deciding if Alfred's window should close, I hadn't taken into account a mod override with no matching mod connection needing to use the default connection "don't close" state.

 

The reason this is manifesting when using quicklook is a little more bizarre. It looks like macOS shifts the focus differently after QuickLook which means when Alfred is hiding for a fraction of a second after using quicklook (because the logic above was broken), the timing prevents Alfred from continuing to be visible.

 

Either way, nicely spotted @GuiB - this will be sorted in the next pre-release!

 

Cheers,

Andrew

Share this post


Link to post
Share on other sites

This should now be fixed in the 3.5 pre-release. If you have a mod defined in the Script Filter JSON but with no [mod] related connection, Alfred uses the "don't close" setting from the default connection.

 

Cheers,

Andrew

Share this post


Link to post
Share on other sites

×
×
  • Create New...