phyllisstein

Hey Andrew and Vero! This is a kinda petty whinge, but I noticed a little glitch with Alfred's Music feature under Catalina. The first time I popped it open, Catalina asked if I would permit Alfred to control Music. The permission prompt locked Alfred up, but appeared behind him: I couldn't dismiss the player while Alfred was waiting for clearance, nor could I grant clearance while the player was in the way.

Ultimately not a big deal, just took me a minute to get reoriented.

It's been about five years since I touched it so I'm not sure it's still any good, but you could see if https://github.com/phyllisstein/Workflows/tree/master/OpenMeta%20Tags does what you're looking for.

Sweet fancy Moses, Andrew, this just about shatters all my personal records for density and foolishness. I didn't even know that checkbox existed, let alone how it got checked. Thanks for bringing it to my attention—all appears to be well now.

Hey Andrew! Long time no see! I hate to play the bad penny, but after a shameful dalliance with the Spotlight redesign I've come crawling back and reinstalled Alfred under the latest Yosemite Developer Preview—build 14A298i, allegedly; I think that's DP4—and noticed a little glitch. When I look up a word with the dictionary shortcut, Alfred shows a link to the definition but not the definition itself. I'm attaching a screenshot, in case that's helpful. Not by any means a pressing problem, natch, and one that I arguably brought on myself by jumping at a prerelease OS like a dog at a leg, but if you have any suggestions I'd be only too glad to hear them. Thanks in advance for your help; and thanks, as always, for all your hard work on Alfred!

Thanks for the small correction. I will say tho, on the larger topic, that I at least could use some guidance on dealing with dependencies. Attempting to wrap the packages in the workflow simply didn't work for me. For whatever reason, relative imports constantly failed. My attempts to help users download required packages to their comp are also hit or miss. 

The specific problem comes when you rely on highly specific packages for certain tasks. In my case, I MUST use pyzotero, a Python package for interacting with Zotero's API. This is a complex package and I can't avoid the non-standard dependencies. Still a relative noob in Python, I feel underskilled to provide a bug-free workflow that nonetheless relies upon non-standard packages. I have to imagine that I'm not alone in this position. Any thoughts or ideas on creating a water-tight, user-friendly system for dealing with Python dependent workflows are highly welcome.

Assuming that you're invoking your Python scripts from within a shell script, you might have better luck changing the PYTHONPATH environment variable than trying to muck around with sys.path. You could either standardize on a common path, as the invaluable @nikipore suggests, or use your personal workflow's storage path, then prepend it to PYTHONPATH before calling Python. Then, from within the script, it'd be a matter of wrapping your import in a try/except block that downloaded, extracted, and re-imported the dependency. Not sure if that's super-helpful, though, or even the best way of going about it.

Edit: Or better yet, do all the checking and downloading from within your shell script, then just write the Python script assuming the module is already there. That's almost guaranteed to be simpler.

Hah, yeah... my first few workflows, and I think a fair number of others at the time, were very Web-centric; and since bundling Requests was actually a bigger chore than I'd expected, and involved a lot of weird bespoke changes to how it imported its own dependencies, I thought it would be more helpful than not. By the time the winds changed, I'd accidentally gotten a day job and left alp to languish; so there Requests stays. Is the story there.

Hah, no worries! I appreciate the frankness. I'll have to see if I can't find some time to correct (or, as you point out, not!) the error on my own. Please do scavenge whatever seems useful for your own module. Working the whole thing in as a submodule is smart; when I was working on alp, we were all trying to keep zipped workflows under 1MB, so deleting git's voluminous histories always made more sense, but I don't think that's a concern anymore. Good luck, and thanks again for the pointer!

Ah! Thanks for the tip. This is extraordinarily lazy of me, but as I've sort of abandoned that particular darling of mine in a basket on the broader community's doorstep, could I ask you to fork the repository and submit a pull request? I can merge it and add a note in the README crediting you for the fix, but I don't personally have the spare cycles to dig into it myself.

Hi there,

As I've said in a few other places, the reservoir of time that allowed me to maintain, troubleshoot, and update these workflows has long run dry. I've uploaded big chunks of the code, though overlooking the Info.plist files, along with all the .alfredworkflow packages, to Github, if you'd like to take a crack at improving them. All I can suggest is that you remove any update.json files in my own workflows and keep an eye on your logs.

The Github repo is at https://github.com/phyllisstein/Workflows and there's a link in my sad little modified signature. All the .alfredworkflow files are there, as well as much of the code---though as Alexander noticed, not the raw Info.plist files.

Aha, that's right—I didn't commit any of the Info.plist files. Schoolboy error on my part. For the time being, I'm just going to pull in the binary, which'll have your Github username on it, as well as add a little note to the README about your contribution. I'll add redoing the repository so that it includes all the relevant files to my (ever-growing) todo list.

Thanks so much for your majorly helpful contribution, Alexander. (Not least because it makes the workflow usable for me again!) I was definitely hoping the Github repo would encourage people to pick up where I'd left (often abruptly and clumsily) off. Not having the time to look after my hatchlings breaks my heart, so it's good to know they're taking flight on their own. If you're on Github, I'd encourage you to fork the repository and send a pull request, so that others can reap the fruits of your labor and so that you'll continue getting credit for it.

Yeah… I've been playing musical chairs with Web servers again, and things aren't always coming back online fast. Although it's actually sort of salutary, since I no longer plan on maintaining my workflows or the website where they used to live. You can find them, including this one, on GitHub at https://github.com/phyllisstein/Workflows—but they're no longer actively supported or updated.

I've been having some server-side issues that are probably causing my own download links to fail, along with any Alleyoop-configured workflows by me personally---however, that wouldn't affect other developers' workflows at all. I'll be doing one last server migration soon that will hopefully correct the problem on my end; in the meantime, I suggest you check the log files in the workflow's folder to see which ones are bombing. If you don't want to delete a whole workflow just because Alleyoop isn't updating it---and why should you?---just open the workflow's folder and delete update.json. Alleyoop only tracks the workflows for which it can find that file. Note that you may have to force a cache reset with oop! in order to see any changes.

debug.log should give you some clues; if not, then feedback.log might. As for additional features, rumor has it that replacement options are coming down the pipe, and so I think I'll probably freeze this workflow but for bug fixes.

Thanks for the heads-up! I've been having to do some server migration for a couple of side-projects, and the Alfred stuff kept getting pushed down my list in favor of work stuff. (On top of the fact that learning nginx has been giving me a greasy headache.) Should be back up shortly, though.

Alright, I'm gonna submit this to the bash scripters out there who are smarter than I—which isn't hard, when it comes to bash scripting. Given a {query} that looks like this:

/Users/danielsh/Dropbox/Writing/Schreber/Schreber.sublime-workspace:::3

…this script is failing to open the workspace correctly:

SUBL_V=`echo -n "{query}" | sed "s/\(.*\)\(:::\)\([23]\)/\3/"`
SUBL_F=`echo -n "{query}" | sed "s/\(.*\)\(:::\)\([23]\)/\1/"`

if [ $SUBL_V -eq 3 ]; then
	/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl -n --stay "$SUBL_F"
else
	/Applications/Sublime\ Text\ 2.app/Contents/SharedSupport/bin/subl -n --stay "$SUBL_F"
fi

I know the conditional statement is fine, because if I add a notification as output and write something like this, it works:

SUBL_V=`echo -n "{query}" | sed "s/\(.*\)\(:::\)\([23]\)/\3/"`
SUBL_F=`echo -n "{query}" | sed "s/\(.*\)\(:::\)\([23]\)/\1/"`

if [ $SUBL_V -eq 3 ]; then
	echo -n "$SUBL_F"
else
	/Applications/Sublime\ Text\ 2.app/Contents/SharedSupport/bin/subl -n --stay "$SUBL_F"
fi

# Result: notification reading "/Users/danielsh/Dropbox/Writing/Schreber/Schreber.sublime-workspace"

So the problem must be with how I'm invoking Sublime, but I just don't see it. I'm sure it's a schoolboy error of some kind, but I keep missing it. Thoughts, community?

hm, it looks like my sed command was adding a weird newline to every filename. Lemme see what I can do about it.

Just released: v2.0 of this workflow adds functionality to list projects that have been opened in both ST2 and ST3, and opens the project in the appropriate version without any adjustment on the user's part. It also, thanks to @chrisyipw's pointers, opens .sublime-workspace files, which retain information about opened tabs and all that jazz, rather than .sublime-project files, which do not. It can be downloaded via Alleyoop or at http://alfred.daniel.sh/Workflows/OpenInSublime.alfredworkflow

That's interesting. Since the first time I installed Sublime Text 3, it has been that way. The first install actually did not have the space before the 3, but I added it for consistency. I did not realize they had dropped the number completely, expect I did notice the title bar no longer has the number.

Maybe you hopped onto an earlier beta build than I did, but I don't remember that. I do recall people being incensed at the dropping of the number, and Jon having some kind of particular reason for it. And I just checked a fresh disk image that has it as plain old unadorned Sublime Text.app. At any rate, the version I just uploaded ought to require less hacking around—though it still uses the paths that I believe to be the default, so you may have to adjust those. (Or switch your Sublime filename.)

`subl` can work fine with `.sublime-workspace`. I tried to run `subl project.sublime-workspace` in Terminal, Sublime Text did what I expected.

Well I'm just learning new things all over. I'll look into implementing this, then.

Hi,

 

I just updated the workflow. It does not show deleted projects anymore. Thanks!

 

But, to get it to work with my Sublime Text 3 install instead of the Sublime Text 2 install, I had to edit the workflow. You can get it here:

 

https://www.dropbox.com/s/oqmixhnr9j79b2j/Open%20in%20Sublime.alfredworkflow

 

Maybe you can see what I am doing wrong that makes each of your updates only open Sublime Text 2. Since I run both, it would be nice to have a switch for which Sublime to use in the workflow. Some packages I like still only run in Sublime Text 2. There could be a sublime setup keyword for setting which install of Sublime to use, save that to a data file, and use it in all the other scripts. Then you would not have to test each time as well. Just a thought!

It looks like you've installed ST3 to /Applications/Sublime Text 3.app, whereas by default it installs to /Applications/Sublime Text.app. Although that's a non-standard setup, I can support both by checking for the presence of the ~/Application Support/Sublime Text [n]/ folder rather than the application itself. Since I'm already making changes, I'm also implementing a way to force 2 or 3. Should be posted in just a minute or two.

Alfred: 2.0.5

Sublime Text: 3 3048

 

When opening a project, can't restore all the tabs.

 

Tried to modify proj.py L32 `projPath = os.path.join(projPath, projTitle + ".sublime-project")` to `projPath = os.path.join(projPath, projTitle + ".sublime-workspace")`, still not working.

I'm afraid that's an issue with Sublime. It also doesn't restore open tabs, as far as I know, if you simply double-click the .sublime-project file on your hard drive. Opening the .sublime-workspace file would work—something that I wasn't aware of till just now!—but the subl command doesn't know how to deal with workspaces and they're not bound to open with Sublime in OS X. You'd have to take either of the latter issues up with jps, I think.

It would be nice to remove projects that have been deleted. But, I guess that is more an issue with Sublime than this workflow.

It would be! And, although that's sort of a Sublime issue, it's also one that that workflow can easily compensate for with a quick call to os.path.exists. See the original download link, or Alleyoop, for an update.

Ugh, Bartender's one of the few things Mavericks straight-up broke.

Aha! Thanks! I didn't even think to look there.

I normally take great comfort in seeing Alfred's jaunty chapeau in the menu bar, but it sometimes seems a bit superfluous. It'd be neat if we could toggle a setting to hide it.

Hey Andrew,

I just noticed that Alfred's dictionary search seems to be a bit wonky under Mavericks. He doesn't show the definition in the result subtitle, which he always did under 10.8. Thought you might like a heads-up!