Jump to content

sfsdfd

Member
  • Content count

    14
  • Joined

  • Last visited

About sfsdfd

  • Rank
    Newbie

Recent Profile Visitors

307 profile views
  1. sfsdfd

    Alfred reviews

    Since earlier discussion about this topic has been censored, I've decided to take the initiative to warn users through other channels. I hope that I can save at least one user the frustration caused by this software. === Alfred has a fatal flaw. Alfred indexes items from a variety of sources: applications, messages, files, scripts, etc. When a user submits a query, it uses an adaptive algorithm to rank the items in terms of the likelihood that the user wanted this item. However, Alfred's matching algorithm is awful. If you execute the same query repeatedly in series, the adaptive algorithm reaches different conclusions about which items you wanted. Even if you TELL it: "When I enter the query 'f,' I mean that want THIS SPECIFIC ITEM," Alfred will ignore your instruction and give you other results that happen to include the term "f". The item you specifically requested *might* be the first result - or it might be the second result, or the *last* result, or nowhere in the list. This bug has been brought to the developers' attention. They are enamored with their adaptive algorithm, so they do not care and will not fix it. Don't use this software. Use another package that respects users' instructions more than its own haphazard guesses. === Posted in several locations, including the Mac App Store.
  2. I've created some workflows that run Python scripts stored at some specific locations. In general, everything's going fine, but there's one thing that's bothering me a bit: I'm running them by choosing "Run Script," selecting the language as Bash, and then entering the script as "/usr/bin/python script_location script_parameters." This just seems clumsy to me because Alfred actually can call the Python interpreter directly, instead of through bash like this. The problem is simply that the "Run Script" dialog has no way to specify a location of a script: you can only specify the actual contents of the script. I don't actually want to store the Python script itself inside the workflow. Does this seem odd to anyone else? Anyone have any solutions?
  3. Oh! I see! I've been too steeped in JavaScript recently. I presumed that {query} was a static variable from the initial trigger, and that it got passed into every further action but wasn't mutable. I see now exactly what you mean: the query or {q} for each step is the output of the previous step. That makes perfect sense and answers a lot of questions, and will help my script development. Thanks very much!
  4. That's what I suspected - thanks for the verification. I'm surprised that Alfred's functionality isn't more robust in this respect. (AppleScript + notification window) and (console session + notification window) must be very routine combinations. Both AppleScript and console sessions can provide output, in the form of stdout. Why not include {output} as an option for the notification center? Seems like a very simple option to implement, and would open up a nice range of functionality.
  5. Er... no. http://imgur.com/a/L1uw9 I tried a few variations, like adding curly braces to denote it as a variable - no improvement.
  6. Very simple question here. My workflow runs a simple script, and assigns stdout to a variable: All I want to do is to show script_output in the post notification, but I can't find any way of doing that, I can set the "Text:" field to either "{query}", which inserts the query text - or I can input raw text, which it just treats as raw text. I can't find any way to specify a variable name other than query, and have Alfred treat it like anything but raw text. Little help? Thanks...
  7. sfsdfd

    Keyword matching is (still) really inconsistent

    That option was set, so I've turned it off to see if there's any improvement.
  8. I have a folder with a lot of subfolders, all of which have well-structrued names - let's say that all of them are three-digit integers (/Files/001, /Files/002, etc.) I'd like to set up an action in Alfred v2 where I can entry a keyword and a query term - e.g., "f 002" - and have it show the contents of that folder in Finder. Unfortunately, I can't find a way to achieve this result: * The "Open URL" action allows the argument for the command to be added to the URL (by inserting "{query}" into the URL), but I can't find a way to use that functionality to open a local folder in Finder, rather than a URL in a browser window. * The "Open File" and "Launch Apps / Files" options will only accept specific files or folders - and these need to be dropped into the pane of the action, so I can't even try using the "{query}" technique to specify the folder name with a wildcard. * I can kludge it with a terminal command, but this option insists on opening a terminal window showing the command, which I then have to close manually. Any ideas?
  9. I've been using Alfred since the v1 days. I've frequently encountered the following problem, and it appears to be worse, rather than better, in Alfred v2. My primary use of Alfred is to accept an assigned keyword, and perform a really simple action: Open File, Open Folder, Open URL, etc. I use that action probably 30 times a day, and I use all of Alfred's *other* functions maybe once or twice a week. However, Alfred's ability to match input in the search box to these keywords is extraordinarily inconsistent. Let's say I've created an action for the input keyword "files", which is linked to opening a folder. Often, typing "files" will result in Alfred suggesting that action first - but not always: * Sometimes, Alfred will show the "files" keyword action as the second, third, fourth, etc. option in the list. Often, the options presented before it are pretty strange - e.g., random filenames that happen to have the word "files" somewhere in the path. * Sometimes, Alfred won't show the "files" keyword action AT ALL - it doesn't appear anywhere in the list. This is especially true for keywords that are a single letter, like "f" or "d" - those keywords don't show up in Alfred's list. * Sometimes, Alfred will show the "files" keyword action as the top option while I partially type the keyword into the search box (e.g., when the search box reads "f", "fi", "fil", or "file") - but when I enter the full keyword "files", Alfred *switches the top option to something else*. This behavior is extraordinarily irritating. * On the off-chance that I happen to select the wrong option (particularly in the latter example), Alfred kind of cements that selection in place: for the next like 10 or 20 times I try typing in the keyword, the wrong option keeps showing up as the #1 suggestion. Frankly, I am mystified as to how such a simple feature could be so totally botched. I understand that one of Alfred's strengths is that it has a learning aspect - but when Alfred "learns" to suggest 10 options before the one explicitly specified option that EXACTLY matches the input string, then Alfred's learning has become a crippling handicap. It shouldn't be difficult to insert a hard-coded rule that if the input EXACTLY matches a keyword, ALWAYS show that option first. Anyone experiencing similar bugs?
×