Jump to content

Some questions about Script Filters


Recommended Posts

Hey,

 

I noticed that with Alfred 5 we can write scripts directly in Swift - no need for compiling an executable! This got me excited and I ended up trying and implementing several things. At some point, I decided it was about time I got at grips with the ins and outs of Script Filters. I took inspiration from @deanishe in two respects. I really like the behavior of his Unicode workflow and wanted to create something that performed similarly, and since his Duden workflow is broken, reviving it seems like a good place to start.

 

I was able to recreate most of what I had in mind. However, there is something that eludes me still. With the Unicode workflow, once a selection is made and the hex representation gets expanded (.u cat -> .u 0x1F408 / ), the previous state immediately gets restored if I hit backspace. Something appears to immediately trigger an autocomplete as soon as the structure of ".u 0x1F408 / " is compromised:

 

  •  How do I instantly trigger some autocomplete without user confirmation (hitting enter on some returned item)?

 

I have attached two previews of the Duden workflow I am experimenting on. At (1), when I hit backspace into (Geige /syn -> Geige /sy⌫) , I would like the previous state to be restored (Geige / ).

 

While I am at it, a few more questions:

  • Is there a way to override or set an autocomplete with a modifier? Say, with cmd "A" becomes the autocomplete, with alt "B".
  • Is there a way to influence the appearance of specific items, say, set the background color, font, text size?
  • Is there a way to get the NSRect for the items (or perhaps just the window width)? This could be interesting for playing with vertical alignment (center, trailing).

 

That's all for now. Merci!

 

1

Lgk5fMG.gif

2

kL7Zmd9.gif

Edited by zeitlings
Link to comment
  • zeitlings changed the title to Some questions about Script Filters
On 7/26/2022 at 9:01 PM, zeitlings said:

the previous state immediately gets restored if I hit backspace.

 

You’ll notice it’s not quite immediate, it takes a beat and flashes Alfred. A way to achieve the behaviour would be to check if the script input ends in /, and if it does call Alfred via AppleScript with the previous text, which was saved after the first ↩. That would explain why the Script Filter has an Inbound Configuration.

 

On 7/26/2022 at 9:01 PM, zeitlings said:

How do I instantly trigger some autocomplete without user confirmation (hitting enter on some returned item)?

 

So it is not autocompleting. Rather, it is reinvoking Alfred with different text, which it also understands. You can “trick it” (Unicode Workflow) by selecting the space and / and deleting both at once.

 

On 7/26/2022 at 9:01 PM, zeitlings said:

Is there a way to override or set an autocomplete with a modifier? Say, with cmd "A" becomes the autocomplete, with alt "B".

 

Yes. See autocomplete and mods in the Script Filter JSON Format documentation.

 

On 7/26/2022 at 9:01 PM, zeitlings said:

Is there a way to influence the appearance of specific items, say, set the background color, font, text size?

 

No. The user’s theme is independent from Workflows.

 

On 7/26/2022 at 9:01 PM, zeitlings said:

Is there a way to get the NSRect for the items (or perhaps just the window width)? This could be interesting for playing with vertical alignment (center, trailing).

 

There’s no official API. See alfred-cal for a Workflow which does something like that by checking the font’s width.

Link to comment

Hey vitor,

 

thanks for the clarification! I will look into inbound configurations and external triggers.

 

On 7/28/2022 at 1:01 AM, vitor said:

Yes. See autocomplete and mods in the Script Filter JSON Format documentation.

 

 

I am still stuck at this. According to the documentation I can set arg, subtitle, icon, variables and valid for modifiers. If I just add autocomplete as a parameter, Alfred doesn't complain but actioning the item or hitting tab with the mod active does nothing. Is there a trick to it? 

 

About the window bounds question, I found a way to extract them with Swift and some core SDKs. Here's a functioning snippet in case someone stumbles over this and has use for it:

 

import CoreGraphics
import Foundation.NSArray

func getAlfredWindowWidth() -> Float? {
	let options: CGWindowListOption = .init([.excludeDesktopElements, .optionOnScreenOnly])
	if let windowInfo: [[String : AnyObject]] = CGWindowListCopyWindowInfo(options, CGWindowID(0)) as NSArray? as? [[String: AnyObject]],
	   let alfredWindow: [String: AnyObject] = windowInfo.first(where: { info in
		   (info["kCGWindowOwnerName"] as? String) == "Alfred" ? true : false
	   }),
	   let bounds: AnyObject = alfredWindow["kCGWindowBounds"],
	   let frame: CGRect = .init(dictionaryRepresentation: bounds as! CFDictionary)
	{
		return Float(frame.width)
	}
	return nil
}

getAlfredWindowWidth() // yields the window width + padding

 

 

 

p.s. what's the formatting syntax for `inline code` call outs like this: 'autocomplete and mods'? Now I just copy-pasted.

Edited by zeitlings
Link to comment
27 minutes ago, zeitlings said:

I am still stuck at this.

 

Apologies, I mentioned that from memory, indeed it doesn’t look to be implemented. While testing now it became immediately apparent why: it wouldn’t work with modifiers like ⌘ (⌘⇥ is used by macOS) and is quite awkward to use. Can you expand on how you’d leverage it?

 

32 minutes ago, zeitlings said:

p.s. what's the formatting syntax for `inline code` call outs like this: 'autocomplete and mods'?

 

[background=#eee][font=courier,monospace]CODE HERE[/font][/background]

 

I don’t write that every time, it’s just the style I decided for MarkdownTransform.

Link to comment
55 minutes ago, vitor said:
[background=#eee][font=courier,monospace]CODE HERE[/font][/background]

 

I don’t write that every time, it’s just the style I decided for MarkdownTransform.

 

Aah, neat. Merci ^_^ 

 

57 minutes ago, vitor said:

Apologies, I mentioned that from memory, indeed it doesn’t look to be implemented. While testing now it became immediately apparent why: it wouldn’t work with modifiers like ⌘ (⌘⇥ is used by macOS) and is quite awkward to use. Can you expand on how you’d leverage it?

 

Aha! I see. What I am interested in are different options to replace the input and thus allow for different ways to act on some piece of base information. For that purpose I agree, 'autocompleting' by hitting ⇥ would be awkward. However, when I set the validity of some item to false, actioning it or hitting ⏎ will also trigger the autocomplete. Allowing that for mods, I think, would not be awkward at all. 

 

You've mentioned alfred-cal above. As it happens, my experiments continued with a calendar++ version of it.  I'll use it as an example for how I'd like to leverage modifier-specific autocomplete; have a look at this: 

 

35985941_cal.gif.88757cf36231374188a0ff6ae66bfafe.gif

 

Here I'm integrating calendar events, where the digits of those days with events have an underscore. By actioning a week-of-the-month row that has events, the events of that week are listed (and actioning here will bring you to the event or the day). The original alfred-cal calendar attempts to show the correlating week in the calendar when the row is hit. While this example is somewhat trivial, if the autocomplete could only be triggered while ⌘-modifying the row, the original behaviour could be preserved. Now it's just the other way around. 

 

But that's the idea: Allowing for different intents to be realized depending on the modifier currently used, say, ⌘⏎ -> show events, ⌥⏎ -> show tasks, ⌃⏎ -> show only birthdays, specific calendars, etc.  Ignoring ⇥ as a potential trigger for modifier-autocompletes but allowing ⏎ would be quite useful.

 

 

Link to comment

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...