lilyball

I just hit this issue. I wanted to paste something and then restore the previous clipboard. But Alfred doesn't seem to support that (at least, not without introducing a delay, which I didn't try). If I store the clipboard in a variable, then use Copy To Clipboard w/paste to paste something in the app, and then use a separate Copy To Clipboard action to put the variable back on the clipboard, Alfred runs the second Copy To Clipboard before it pastes in the app. I'd really prefer not to have to fall back to AppleScript just to do this, since it's not all that uncommon of a thing to want.

Also, after reading that, it seems the support you have right now is for copying data from the XML output. That's still not usable for my purposes. I want to be able to run a script action and copy the results of that instead. The reason being I don't want to run the action on multiple different results when the user can't copy them all, and may not even copy any. I just want to run my action once the user has told me that they need the results.

Oh wow when did that documentation show up? I've always used http://www.alfredforum.com/topic/5-generating-feedback-in-workflows/as my source for this stuff, and it doesn't mention that. You should update that forum post to link to the documentation.

Related to this would also be supporting Cmd-L to do Large Type with the output of a workflow command. For example, if I type "=1+2" and hit Cmd-L, it shows "3", but if I run a workflow command instead, Cmd-L just shows exactly what I typed (even for script filter workflows).

When creating a workflow, you can double-click on the Input->Action connection to set up a modifier for that connection and custom subtext. But there's no way right now to run the same script for all modifiers and merely control the action taken, short of duplicating the script (and yes, you can put a common script in the workflow and call it from each action, but that can be a bit annoying). It would be nice if you could instead set the Input->Action connection to a new value "any" and then configure the modifier and subtext on the Action->Output connection. For example, I might have a script that spits out a filename, have the default action do something with that file, and have option-return do something different with that same file.

Various actions in Alfred support pressing Cmd-C to copy them. I'd love to be able to support this in my workflow. Specifically, I'm creating a workflow right now that runs a script with a keyword trigger with the action being Copy to Clipboard & Automatically paste. I want to be able to press Cmd-C to just copy without pasting.

Three thoughts on how to do this:

1. If an action would Copy to Clipboard, support Cmd-C to copy as well without pasting (and without running any other actions). This would only work for actions that already copy though.

2. More generally, Alfred could support just copying the output of any script to clipboard with Cmd-C. The downside here is you'd get the exact output of the script, which may not be correct (e.g. the Copy to Clipboard action may add other text around the {query}).

3. A variant on #1, perhaps the Copy to Clipboard action could gain a new boolean option "Copy only with Cmd-C". This way you could add Cmd-C support to existing workflows but have it only copy on Cmd-C and not on normal action triggering.

When using the iTunes control keywords "next" and "previous", or the Workflow iTunes Command action for Next track / Previous track, it doesn't work at all when listening to an Apple Music album that's not in my library. Triggering it logs an AppleScript error to the Console:

 

8/21/15 10:26:02.091 AM Alfred 2[1567]: [ERROR] AppleScript Error: {

    NSAppleScriptErrorAppName = iTunes;

    NSAppleScriptErrorBriefMessage = "Can\U2019t get index of current track.";

    NSAppleScriptErrorMessage = "iTunes got an error: Can\U2019t get index of current track.";

    NSAppleScriptErrorNumber = "-1728";

    NSAppleScriptErrorRange = "NSRange: {0, 0}";

}

I'm rather curious why it's even trying to get the index of the current track, since iTunes has special AppleScript commands for next / previous track. It also has a separate "back track" command which is preferable to "previous track" because "back track" will rewind to the current track if you're not near the beginning, and will only go to the previous track if you're already at the beginning of the current track (i.e. it behaves like the rewind button in iTunes's UI).

I'm working on a workflow, and I want a script filter result to be invalid, but to be valid if I hold Option. Is there any way to accomplish this?

The context is that holding Option lets you delete a result, but the regular action isn't valid unless you type a second argument.

You are correct, Alfred doesn't use waitUntilExit, he waits until stdout pipe is closed.

 

When I originally used waitUntilExit (Alfred v1), I was seeing hanging / performance issues which ultimately affected the perceptual speed of Alfred. I switched to stdout closing as a marker of being done and haven't seen a performance issue since. This may no longer be relevant in newer versions of OS X and whatnot, but as there isn't much of a call for this, I'm reluctant to make any change in this area.

 

Cheers,

Andrew

You could try waiting until the pipe is closed, and also setting a terminationHandler on the NSTask. If the termination handler fires while the pipe is still open, you could then just drain any available data from the pipe and close it. That should leave the current performance intact (because if, as you suggest, the pipe closes before the task finishes terminating, then it should close before terminationHandler fires), but allow for handling cases like what I've described.

Andrew, I just built a quick test of NSTask behavior under these exact same circumstances, and `waitUntilExit` does indeed return as soon as the "outer" Vim process exits. I'm guessing you're actually waiting until the process stdout pipe has closed? I suppose that suggests the workaround: set stdout to /dev/null. But it also suggests that, once the task has terminated, Alfred should be able to just read any remaining information in the stdout/stderr pipes, and then immediately close them. Adopting this behavior will only affect workflows that spawn sub-processes and exit the parent process, and since doing that normally kills the subprocess as well, it means it really should only affect situations like MacVim where the process daemonizes itself.

Sample code:

import Foundation

func runTask() {
	var task = NSTask()
	task.launchPath = "/Applications/MacVim.app/Contents/MacOS/Vim"
	task.arguments = ["-g"]

	println("Launching task...")
	task.launch()
	println("PID: \(task.processIdentifier)")
	println("Waiting for termination...")
	task.waitUntilExit()
	println("Exit status: \(task.terminationStatus)")

	CFRunLoopStop(CFRunLoopGetCurrent())
}

CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopCommonModes) {
	runTask()
}

CFRunLoopRun()

Andrew, what's the workaround? Vitor hasn't responded, and I haven't come up with anything that I would reasonably expect to work given the observed behavior.

Vitor, what was your workaround?

This was reproduced with Alfred v2.3 (264)

When a Workflow uses a Run Script phase, Alfred seems to wait for all spawned processes to exit before considering the workflow to be finished (which at the very least prevents running the same workflow a second time until the first invocation is considered done).

The problem is that it's waiting for stuff it shouldn't. Specifically, daemonized processes (which is to say, processes that forked and abandoned the process group) are causing Alfred to continue waiting, even though the entire point of daemonizing is to detach from the controlling terminal (and in this case Alfred acts like the controlling terminal).

The specific case I have here is launching MacVim. When launching Vim in GUI mode, it forks and abandons the process group, and the parent process dies. This is done explicitly so the terminal that launched it will return immediately to the command line instead of waiting on the process (it also allows the GUI Vim process to outlive the terminal). But this doesn't work in Alfred.

Here's the spawned process log:

2014 Jun 10 17:12:32 71064 <430> 64b: /usr/local/Cellar/macvim/7.4-72/MacVim.app/Contents/MacOS/Vim -g -c setf test -c startinsert
2014 Jun 10 17:12:32 71101 <1> 64b: /usr/local/Cellar/macvim/7.4-72/MacVim.app/Contents/MacOS/Vim -f -g -c setf test -c startinsert

That first process there, PID 71064, was spawned by Alfred (PID 430). It then forks and runs the second process, PID 71101, which as you can see has a PPID of 1, because it detached from the process group. 71064 then immediately exits (it's not visible in this log, but I verified it with `ps`).

However, Alfred will continue the workflow to be running for as long as PID 71101 lives. If I turn on workflow debugging and add an `echo`, it doesn't print the output until I quit Vim. Similarly, if I try and invoke the workflow a second time, it doesn't actually run the script phase for the second invocation until I've quit the Vim process from the first one.

It's still a valid XML document. And I think Alfred should just strip the string so it can be displayed correctly.

 

The `minidom` library in Python behaves differently in 2.6 and 2.7. These extra new line will be added if use the `toprettyxml` function of minidom in Python2.6.

It may be valid, but it doesn't mean the same thing. You shouldn't be emitting "pretty" XML when sending it to another tool anyway; "pretty" XML is intended for human consumption.

<?xml version="1.0"?>
<items>
  <item uid="rdioartist" arg="r96664" valid="yes" autocomplete="Incubus">
    <title>
            Incubus
    </title>
    <subtitle>Artist</subtitle>
    <icon>rdio-artist.png</icon>
  </item>
  <item uid="albumart" arg="/Users/user/Documents/album.jpg" type="file">
    <title>Incubus Album Art</title>
    <subtitle>Album Art for Science</subtitle>
    <icon type="filetype">public.jpeg</icon>
  </item>
</items>

Seems like Alfred2 doesn't handle newline characters correctly. This XML docunement will get one of the title empty. Please confirm.

 

Probably because you have superfluous whitespace in your <title> tag. It starts with a newline, then a bunch of spaces, before the title you actually wanted. You should rewrite it as <title>Incubus</title>.

It's extremely wacky and very annoying - there is almost no information on this whatsoever! One of the beta releases would allow you to re-normalise {query} to any form you chose but as soon as this was passed to NSTask, it would re-normalise and decomposed. Being naughty and swizzling a few methods managed to 'fix it', but who knows what sort of havoc this could cause which is why I call it a "risky" fix and it was removed.

Did you file a radar on this? If so, what's the number?

During development, I spend a good amount of time playing with Unicode. Alfred uses NSTask which converts arguments using [NSString fileSystemRepresentation]. Internally, this decomposes the UTF-8 to suit the filesystem. Cut a long story and significant investigation short, this decomposition is outside of Alfred's control without a risky overhaul to NSTask / NSString.

 

Your best bet is to re-normalise the UTF-8 into the form you need before using it.

NSTask calls fileSystemRepresentation for arbitrary arguments? That's wacky.

And in my case, the workflow displays information about the unicode characters. It doesn't "want" one particular normalization, it just displays different output for the different normalizations, and this means if I ever actually need to know whether a sequence is composed or decomposed, I'll have to use a different tool. Oh well.

Apologies. This appears to be an error in the documentation. If no icon value is specified, it will show a blank icon as the result. If the icon item is not included at all, it will default back to a folder icon. I'll get the documentation corrected. Thanks.

Folder icon seems like a really weird default. Maybe show the blank document icon? I actually used the filetype public.text for a while to get that, before I got around to making a real icon for my workflow.

Well, if you want to see a workflow that cares, I have one that provides information about unicode characters. You can download the workflow here, and invoke it with `char é`.

What does "Defaults to the script filter extension" mean for icons? If I don't provide an <icon> in my script filter output, the resulting entry always gets the folder icon, even if my workflow has an icon. This holds true even if I give the script filter itself an icon.

I have a workflow that can actually tell the difference between composed and decomposed characters in the query string. The script filter looks like

./command {query}

If I run my script filter with the single character U+00E9 LATIN SMALL LETTER E WITH ACUTE, it actually receives the characters U+0065 LATIN SMALL LETTER E followed by U+0301 COMBINING ACUTE ACCENT.

I really want a way to control the order of the output from my workflow. For the time being I'll go with the suggested idea of using a UUID as the uid, but I really wish just omitting the uid entirely would work.