Andrew

@kballard this is now sorted if you update to the b837 pre-release. I'm still tempted in raising a ticket with Apple though, as it doesn't feel right that the clip counter can happen before the clip changes are seen as complete. Cheers, Andrew

@GuiB This option is now available under the "Run Behaviour" button within the Script Filter workflow object config sheet if you update to the b837 pre-release

@vitor There is a new Snippet Trigger workflow object coming very soon which carries the same "focused app" variable option that hotkeys do. This will essentially allow you to dynamically create an auto expanding text snippet based on the currently focused app

@GuiB I've added a ticket to look into this. An option may be added as an option under the "Run Behaviour" allowing all typed characters to be preserved (defaulting to the fixed current behaviour). Cheers, Andrew

@GuiB @deanishe Interesting, and something I haven't looked at for quite some time. Firstly, it's correct that Alfred is trying to make things more efficient and prevent scripts from running unnecessarily. I've actually identified a little bug where it's trimming the query instead of trimming the trailing spaces, which is why you're seeing that odd leading behaviour. I've just fixed that. As this is the first time this has come up, could I ask the use case for needing the spaces as being significant? It's possible I may remove the trimming altogether rather than adding an option to make spaces significant. Cheers, Andrew

@kballard hmm, I had (wrongly?) assumed that this would have either been wrapped in a single pasteboard "transaction", or clearContents would have adjusted the clipboard change count (i.e. clipboard changed to empty), then writeObjects would have adjusted it too (i.e. changed to contents). I've had a bit of a play with this and I can comfortably ignore clip counter changes until there are types available. Thanks for highlighting this - I'll have this fixed in the next 3.4 pre-release Cheers, Andrew

Alfred watches the pasteboard change count. It looks like the change count is increased, but nothing is in the clipboard (yet), then a short period later, the data is defined in the clipboard. There is no way to achieve this using the standard pasteboard API, which is why you don't see this behaviour with other apps, so I suspect they may be doing something sketchy behind the scenes. I'm not sure I want to add a fudge into Alfred to cater for this one specific case, but I will raise a bug against Maps.app. Cheers, Andrew

@kballard I've just looked into this and there is definitely something odd going on with Maps.app which initially appears to be a bug. When copying something from Maps.app, there are no types reported in the clipboard. For example, if I copy a URL from Safari (or any other Mac app), I see this: TYPES: ( "dyn.ah62d4rv4gu8zs3pcnzme2641rf4guzdmsv0gn64uqm10c6xenv61a3k", WebURLsWithTitlesPboardType, "dyn.ah62d4rv4gu8yc6durvwwaznwmuuha2pxsvw0e55bsmwca7d3sbwu", "Apple URL pasteboard type", "public.url", "CorePasteboardFlavorType 0x75726C20", "public.url-name", "CorePasteboardFlavorType 0x75726C6E", "public.utf8-plain-text", NSStringPboardType ) And this is what I see when copying from Maps.app using cmd+c: TYPES: ( ) ... But doing a subsequent paste of this copy to e.g. TextEdit, it pastes a stack of stuff. I haven't finished looking at this, but it looks like Maps.app is doing something fudgy and non-standard to get the data / URL into the clipboard. This would explain why there is different behaviour in Maps.app vs other apps. Andrew

Decided to sneak this into the upcoming 3.4 release, this will be in the next pre-release (probably tomorrow), available as an option from the popup menu on the workflow editor canvas It essentially shows guides for the object you are currently interacting with (hover / drag). Cheers, Andrew

@vitor not really related - that post is for Alfred v2 where workflow layout was fixed to 4 pre-defined columns. I've worked on auto layout systems in the past, and these are hardly ever effective, as while you can do some automatic arbitrary layout, you can never get in the head of the user and how they actually want it laid out. @derBingle I'll add a ticket for this, as it's actually something I've thought about a few times in the past Cheers, Andrew

@fakepop oops, thanks! If you update to b834, this is now fixed properly.

@vitor these are now available in the 3.4 b832 pre-release

Note: This is now Fixed in the 3.4 b834 pre-release

Note that this is now fixed in the 3.4 b832 pre-release

@vitor I'm going to move this to noted, but it's unlikely there is anything I'll fix for this. I'm not even sure if it's valid AppleScript, as when I run osascript directly from the command line, I get the same thing: Andrews-iMac:~ andrew$ osascript -e 'open location "https://www.alfredforum.com/"' 0:44: execution error: "https://www.alfredforum.com/" doesn’t understand the “open location” message. (-1708) If I direct the open location to a specific app such as Safari or Finder (i.e. with tell), then it works as expected. Cheers, Andrew

@mpounsett For Sierra, you'll need to be using Alfred 3 directly from our website, which is currently at version 3.3.2. The free App Store version is the original / classic Alfred, at version 1.2. Cheers, Andrew

Hi Vitor, This seems to be working fine for me with RunScript / osascript (AS), but not for Run NSAppleScript. I've actually put a bit of debug code in and NSAppleScript is returning no errors to me, i.e. reporting that it ran fine. I wonder if something has changed in macOS if this previously worked in Run NSAppleScript. I'll continue to fiddle. Cheers, Andrew

Alfred's snippets should work fine as long as you are in 'insert' (or equivalent) mode in VIM. If you are in the command mode and your snippet text is prefixed with a /, then this will run a / command in VIM as it doesn't have the context that you are pasting text. Before using the snip keyword (or an auto expanding snippet), be sure to to press i for insert. Cheers, Andrew

@vitor Ah sorry, I thought you were talking about the "Call External" output. Yep, I can see that there is no errors being output when the External Trigger AppleScript is run on Alfred. I've added the following errors into the External Trigger AppleScript for the next release: Unknown Error: -1 Workflow Not Found: -2 Trigger Not Found: -3 Workflow Disabled: -4 Cheers, Andrew

@vitor Do you mean output an error to Alfred's debugger that no matching trigger was found? I can see it's not doing this, and it should be. Cheers, Andrew

@effe While this isn't possible natively in Alfred, the clipboard database is actually just an SQLite DB, so with a bit of scripting, you should be able to quite easily manipulate the database. You'll find the clipboard db in the following location: ~/Library/Application\ Support/Alfred\ 3/Databases/clipboard.alfdb The database has one table (clipboard) with the following columns: clipboard(item, ts decimal, app, apppath, dataType integer, dataHash); The text data is stored in the "item" column, and you'd probably want to only touch items with dataType = 0 as this is text items. Other items have external dependencies outside the database, such as images. Also worth adding that you fettle with this at your own (low) risk. The worst thing that could happen is you lose your history and have to start again. Cheers, Andrew

@deanishe I'll msg you at some point to pick the conversation up again. I'd rather properly solve the underlying things such as direct execution etc leaving Alfred's main UI to be predictably consistent if I end up changing the focus behaviour.

@deanishe An option could be to use the "Hide Alfred" workflow object after performing something behind the scenes which you know may pull focus from Alfred. Having said that, these magic arguments sound a bit hacky / cludgy - is there a reason it's done like this? (i.e. is there something missing in Alfred Workflows which would allow what you are trying to achieve without needing them)?

@deanishe I'm more specifically talking about the one scenario when focus is unexpectedly pulled from Alfred, and Alfred disappears. In all other scenarios, Alfred would open in the default state as he has done since the start. If I made it such that if Alfred disappeared outside of the user's expectation, then you have a few seconds window to bring the Alfred window back and carry on. This means that any time that you action a result, or simply hide Alfred manually (e.g. by using the hotkey, or pressing Esc), then things would be as they are now. I suspect that (2) above would also be included in this depending on how Alfred is being dismissed from the screen.

Alfred yielding focus to macOS is essentially by design and intrinsic to Alfred's behaviour. Having said that, I've raised a ticket to have a bit of a re-think about this. I can see that it could be very useful for Alfred to keep full state for a short period of time after having the focus pulled from him, making him hide. e.g. if you were to use the main Alfred hotkey within a few seconds of focus being pulled, it would put Alfred back on the screen it its previous state.