GuiB Posted August 30, 2017 Share Posted August 30, 2017 The behaviour is quite strange when activating an action with a hotkey that use the selection in macOS and is active when Alfred is in focus... I want to create some actions that work with files when browsing in Alfred using the builtin browser and that are triggered by a hotkey. However, it seems that Alfred doesn't always restore the focused application correctly when the action goes back to Alfred using the "Browse in Alfred" object since the hotkey doesn't always work the second time. Here is a workflow to easily test what I'm describing with different situations that work or not: https://nofile.io/f/AZCX1X9vo6m/HotKey+Issue+In+Alfred.alfredworkflow In short, it always work when I specify to activate Alfred with an applescript or (strangely) when the action trigger a "Run Script" with Applescript / Python / Ruby / PHP / Javascript as language, but not with Bash / Perl / ZSH or by sending the path to browse using the "Arg and Vars" object... Link to comment Share on other sites More sharing options...
Andrew Posted August 30, 2017 Share Posted August 30, 2017 @GuiB All of those hotkey objects are configured to only be active when Alfred is active. macOS window focus identification can be a little weird with floating panel windows such as Alfred, which may be why you are seeing weird behaviour. Link to comment Share on other sites More sharing options...
GuiB Posted August 30, 2017 Author Share Posted August 30, 2017 @Andrew, yes I know this is maybe unusual, but I thought I would let you know in case you find a quick and easy fix. However, yes, don't put this as high priority as there's workarounds to make it works nevertheless and I don't think a lot of people do things like that and just use File Actions instead, but I find it quite great to have some shortcuts like that to work with file rapidly. Thanks again for all your support! Link to comment Share on other sites More sharing options...
Andrew Posted August 30, 2017 Share Posted August 30, 2017 @GuiB Ah sorry, I mis-read your issue - you actually WANT to use these hotkeys within Alfred; yeah this should work hm. Looking a bit deeper into this, I can see what is happening. Alfred simulates a cmd+c when getting the selection in a hotkey and picks up the content. When Alfred is showing and you manually use cmd+c, Alfred automatically hides so you can use what you've copied - These two actions obviously interfere. When Alfred is re-showing again, in some circumstances (e.g. browse in Alfred), the code I have which makes Alfred (being a floating panel instead of a window) be noticed as the active application isn't being correctly run. Link to comment Share on other sites More sharing options...
GuiB Posted August 30, 2017 Author Share Posted August 30, 2017 (edited) @Andrew, then I guess we both mis-read each other I thought you understood me and said that hotkeys that are assigned to Alfred focus could get some unpredicted behaviour since macOS window focus identification is weird with floating panel window... But yes, I want everything to happen inside Alfred (the selection is the selected item in Alfred). Look at my last action in the Workflow to have a better understanding of what I'm doing, but I just want to create shortcuts to an action that works on the selected file in Alfred (ex: create a symbolic link of the selected folder, or create a new file or folder...) I thought this was maybe just a matter of making sure the "Browse in Alfred" always put the focus to Alfred, but I know sometimes it could be more complicated than what we think. So that's why I didn't want to push too much this bug report, but if it's an easy fix then sure this would be appreciated if you can easily fix it at a point Edited August 30, 2017 by GuiB Link to comment Share on other sites More sharing options...
Andrew Posted August 30, 2017 Share Posted August 30, 2017 @GuiB the focus is with Alfred, but because of the conflict I noted above, Alfred's hotkey manager has de-registered the hotkey so it's no longer active. There are a few options for fixing this. The one I'm considering would be to make Alfred not hide when a simulated cmd+c happens, which would be nice as you also wouldn't get a flicker when doing what you want. The down side of this is it may cause regression if somebody is using a hotkey with macOS selection and relying on Alfred from hiding for their action. Link to comment Share on other sites More sharing options...
GuiB Posted August 30, 2017 Author Share Posted August 30, 2017 (edited) That would be great to make it works so Alfred doesn't flicker About your regression... but if Alfred is in front, wouldn't the macOS selection be always the one that is set in Alfred ? I mean, for example, if I have a file selected in Finder and pop Alfred to do something and do a hotkey to run the action. If I set the hotkey to get the selection from macOS and make the hotkey as global (no specific focus), then I would get the item in Alfred that has the selection even if Finder is just behind. I mean, if someone want a hotkey that works with the macOS selection, but want Alfred to hide when triggered, then why would it shows Alfred first? It just needs to trigger the hotkey on the specific application without showing Alfred first Or I just don't get what you said ? Edited August 30, 2017 by GuiB Link to comment Share on other sites More sharing options...
Andrew Posted August 30, 2017 Share Posted August 30, 2017 @GuiB A simple use case... A hotkey wired to take the selection and run a script with it (doesn't matter what). When triggered with Alfred visible on the selected item in Alfred's default results, or Alfred's file system navigation, Alfred hides - this is just the behaviour (wether right or wrong). If a user is expecting this action to happen, and have setup their workflow expecting this to happen, changing the behaviour could break their workflow. I know this could be fixed with adding a 'hide Alfred' object, but that makes it a regression. On another note, I've done a one line code fix which changes internal window event order, so this is essentially fixed now (even though it still flickers). Link to comment Share on other sites More sharing options...
GuiB Posted August 30, 2017 Author Share Posted August 30, 2017 Ah ok, I think I understand, I thought you were talking that this would change the behaviour of the selected item (not getting the same selection), but you mean this is changing the behaviour of Alfred hiding itself (the window would stay there). Then do what you think is best for you and the application. For sure, I wouldn't want a regression that would give you more support work, so I'm fine with having Alfred flicker. Or what about adding an option to the hotkey object to specify if we want Alfred to hide or not ? Then you could keep it to hide by default and if we know that we want to keep Alfred focus, we would just have to change this option (or if not set and want to keep Alfred, then we would just see it flicker as it is). So, this shouldn't break any workflow. Link to comment Share on other sites More sharing options...
Andrew Posted September 4, 2017 Share Posted September 4, 2017 @GuiB If you update to the 3.5 pre-release, the app-contextual hotkeys should work properly Link to comment Share on other sites More sharing options...
GuiB Posted September 4, 2017 Author Share Posted September 4, 2017 Thanks @Andrew! Yes, after some testing, this seems to be working great now! Andrew 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now