• Content count

  • Joined

  • Last visited

  • Days Won


ClintonStrong last won the day on June 11 2016

ClintonStrong had the most liked content!

About ClintonStrong

  • Rank

Recent Profile Visitors

244 profile views
  1. I haven't had a whole lot of time to work on this workflow lately, but I'm glad you got something working. I've looked over the error reports, but there's nothing that really stands out to me. It's working fine on my system, which makes me think there might be something conflicting with it. I've considered making a new version which uses Safari/Chrome extensions to communicate with them via websockets (should also be faster than using AppleScript). I'll play around with that and report back if it works out.
  2. Could you try this workflow and let me know if it works for you? Install it, type in "example", and hit enter. It should show a dialog saying "It works!". If that works for you, I'll work on changing the way the workflow makes AppleScript calls. Hopefully that'll fix it.
  3. I think you may have to restart your computer for the updates to apply (if you haven't already). I haven't encountered the error on my own system, so I'm not entirely sure if that's the issue, but it's worth a try.
  4. I believe that error's caused by an out of date scripting addition. Try following the steps here to fix it: Let me know if everything works after that.
  5. Oh, right. That happens because the workflow identifies each tab with a URL, but doesn't associate the browser with it. So if you tell it to close a tab, all it knows is that you want to close a particular URL. Alfred used to only be able to copy the "arg" of a result when you hit cmd+c, so while I could have added the browser to the arg, you'd end up copying URLs like "chrome;". I instead opted to only use the URL of the tab as the arg, which unfortunately means you'll have issues like the one you described. I just looked in to it though, and it seems Alfred v2.3 has a fix for this. I'll try to get it updated later today.
  6. Sorry about that. Could you turn on error reporting and let me know what errors are being logged? You can get there by selecting the workflow and pressing the bug icon in the top right corner.
  7. Yosemite no longer includes Ruby 1.8, so extensions relying on that (or frameworks like RubyCocoa that were only installed for 1.8) will no longer work. They've also dropped Python 2.3 and 2.5, but 2.6 (specifically 2.6.9) is still installed alongside 2.7.6. Safari now stores its history in a database rather than a property list, but I expect most workflows searching Safari's history just use a file filter on ~/Library/Caches/Metadata/Safari/History. That still seems to be working.
  8. CocoaDialog isn’t working properly for me. Getting the following error: dyld: Library not loaded: @executable_path/../Frameworks/Growl.framework/Versions/A/Growl Referenced from: /Users/clinton/Dropbox/Alfred 2/Alfred.alfredpreferences/workflows/user.workflow.F57EC135-8D11-4A8B-A313-24C6BCB4D9A1/Resources/ Reason: image not found I tried downloading cocoaDialog myself and that seems to be working fine. I looked into the app package and all the frameworks appear to be included, so I have no idea why it couldn’t load the Growl framework. I’ll try to look in to it some more tonight.Oh, and there’s an error if you’re using Safari as your default browser. I think this happens if you’ve never changed your default browser, but didn’t contain an entry for the http url scheme. You could probably just initialize defaultBrowser to '' to fix that.
  9. Nice! Only issue I ran in to was that it seems to take a while to load the initial results. For example, when I typed 'e', it returned over 6,000 results and took a couple of seconds before any other characters were processed. Unfortunately it doesn't look like you can limit the number of results with mdfind without dipping in to the C/Objective-C APIs. I suppose a quick and easy fix could be to ignore the search if the query's only one character long, since it'll likely be too noisy to find anything anyway. Basically, each script, keyword, action, etc. is stored as an object in a workflow’s info.plist. You can see them listed under <key>objects</key>. The important part is the uid field; Alfred associates each object with a unique ID (I believe it uses UUIDv4). Alfred uses these UUIDs to keep track of each object’s relationship to another, which you can see below <key>connections</key>. Each of these relationships also has a unique ID, stored in the key field. Alfred also keeps track of the graphical representation of the workflow’s objects under <key>uidata</key>. If you’re programmatically adding new objects, you’ll probably want to find the largest ypos of the objects, and increment it by about 120 so it aligns correctly each object is 96 px in height and typically has 26px of padding between other objects (though you can adjust this).
  10. I kept finding myself writing one-off scripts to feed my indecision and make a random choice. I wrote this workflow to automate my indecision. Download | Source Some of these keywords are duplicates of existing workflows, but I wanted to have all my RNGs in one workflow. Feel free to disable any keywords you don’t want or need. Oh, and you don’t have to worry about downloading a light or dark version of the workflow. The icons adjust automatically based on your theme as soon as you start using the workflow. See alfred-icons for more information about how this works. Usage choose Enter a comma separated list of values and pick one at random. roll Roll a die. Enter the number of sides, and have a random number chosen. rand At its simplest, rand just an alias of roll. For example, rand 20 and roll 20 both do the same thing. However, you can define a lower and upper limit with rand. Example usage: rand 20 rand 10-20 rand 50 70 rand 100..1000 flip Flip a coin: heads or tails. should Like flip, but with a yes or no response instead.
  11. Many Alfred workflows out there use monochromatic icons (aka “glyphs”). They look great, but it introduces a problem: you have to maintain two separate workflows. This creates extra work for the developer, and extra work for the user, should they happen to change their theme. This is a script to help solve that problem. Bundle both light and dark icons with your theme, and let alfred-icons decide which ones to use. This eliminates the need to maintain two separate workflows for light and dark themes; it just works. To sum it up: alfred-icons analyzes the background color of the user’s current theme and swaps out the icons based on whether it’s light or dark. Simple. Download | Source How to use To put it in use, you’ll need to conform to a simple naming convention. Alfred already names the icons for you, based on a UUID something like 3A20DDBC-D992-4DD1-9A65-4A1860EEEC7D.png. For the sake of explanation, let’s assume your icon is dark (i.e. designed for light themes). Now add in the light variant of your icon. Give it the same name as the dark icon, but with “-light” appended to the end. For example, you might name the new icon 3A20DDBC-D992-4DD1-9A65-4A1860EEEC7D-light.png. If your default icons are light (i.e. designed for dark themes), append “-dark” instead. So to clarify, add the “-light” prefix to light icons designed for dark themes, and “-dark” to dark icons designed for light themes. Don’t rename the original icons Alfred generates for you. Now that you have the icons set up, download the latest release and place the SetupIconsForTheme script into your workflow’s folder. It’s up to you how you want it to run: you could add in a keyword to manually change the icon colors, or you could automate the process and run it every time your script/script filter is run. Including it in your script In Ruby and PHP, you can run it by including the command in backticks: `./SetupIconsForTheme` In Python, you can use subprocess: import subprocess'./SetupIconsForTheme') In AppleScript: do shell script "./SetupIconsForTheme" You may need to adjust the path if your script is stored in a subdirectory, but you get the idea.Other notes The one drawback and this is still the case even if you have separate “light” and “dark” workflows is that the background color for the selected result might have a dark background, while the rest of the theme is light. This could cause “invisible” or hard to see icons for the selected result, while everything else looks fine. Unfortunately, we can’t change the icon for just the selected result it has to use the same icon for every result. You could work around the issue entirely by adding backgrounds to your icons, but then you lose out on the clean, simple look of monochromatic icons. I’ll leave that decision up to you. Note that there’s a bit of delay before the script recognizes you’ve switched themes. If you’re testing it out and it doesn’t work right away, just give it a few seconds and try again. Ideas for future improvements Use a cache file so it doesn’t run on every keystroke. Maybe limit it to 30 seconds or a minute so it’s still responsive to changes by the user, but it won’t run needlessly. Check if Alfred’s preferences have changed since the last run. If they have, it’s possible the user might have changed their theme. If not, we know the theme didn’t change, so there’s no need to run it again. Generate the dark or light icons for you, without needing an image editor. Not guaranteed, but I’ll consider it for a future release.
  12. Hey there. I created a workflow that does this (and a few other things), called QuickCalc. It still needs some work (there are a few bugs lingering around), but it should be able to accomplish what you're asking for. It doesn't automatically detect locales, so you'll need to manually set the thousands/decimal separators. In Alfred's preferences, find QuickCalc, double click the "qc" script filter, and set the script to the following: export THOUSANDS_SEPARATOR='.' export DECIMAL_SEPARATOR=',' /usr/bin/ruby main.rb "{query}" I just added support for those separators today, so let me know if you find any issues with it. Oh, and one downside to setting the separators like this is that you'll have to re-enter them when you update the workflow. I'll try to find a better solution for that.
  13. It looks like that's being caused by an out of date scripting addition. Try updating it and let me know if that fixes it. If all goes well and it works, you can go ahead and remove the debugging code: ruby filter.rb "{query}"
  14. Hm, would you mind checking if any errors are occurring? For the script filter, change the script to the following: ruby filter.rb "{query}" 2> ~/Desktop/errorlog.txt Run the workflow in Alfred, and check your desktop for a file called errorlog.txt. Let me know if anything's being logged there.
  15. Thanks. Unfortunately, it doesn't look like there's much I can do to speed it up. Most of the time spent is waiting for a call to AppleScript to complete. It is possible to show favicons for websites, but in most cases they just wouldn't look good. Most favicons are small (16x16), so when you display them in Alfred they would look blurry. Another issue is speed. Both Chrome and Safari store favicon data in an SQLite database, but Chrome locks its database while the app is running. If I wanted to access it, I'd have to copy it to some other location on your drive before I could read it, which could potentially be quite slow. I could probably get the favicon data from Safari fairly quickly, but I'd still need to dynamically generate images for each of the icons and store them someone on your drive. I haven't tested the performance on this yet, so I can't say for sure if it'd create a notable slowdown.