woofy31

Hey Andrew, and thank you for getting back to me Well, the thing is that I have tried using both non-dropbox sync (default location), as well as dropbox-sync after it has finished syncing, and even tried using another dropbox folder, and nothing worked.. I must have tried every imaginable scenario, but it seems that there's something really wrong with this account (which was created by OSX after install)... so from where I stand, the only solutions I have are: [a] creating a new account and moving every app data, relicensing all apps, reconfiguring all apps, which is a daunting & time-consuming task setting the same must-have settings in Alfred every time I start the OS and taking my mind off of setting custom themes or installing new workflows, and making sure that the Alfred process never quits until I shutdown the OS.. Obviously I've decided to go with , hopefully I'll get used to setting the same settings over and over everytime the OS starts - ultimately I guess it'll become a mechanical reflex.. and maybe when I have more time I'll do [a] piece by piece.. I was really eager to install Mavericks, but instead it gave me a bitter taste.. hopefully this will resolve itself over the time, who knows, maybe with an Alfred update or the next OS update..

OK, so I've tried using another account, and it looks like it's working... but what does this mean? Because it can't be a permissions problem since I've repaired/removed/reset permissions and didn't help And I don't really like the idea of creating another account and re-licensing all apps, and moving every app data to a new account - it would take me ages to do that (( [later edit] I just can't understand what is wrong on this account.. I've set all permissions (in library/preferences, in library/appsupport, even in Applications folder) to be exactly the same as in the new account where Alfred worked, and yet on this account it just doesn't load the saved settings.. can anyone tell me what the problem could be? Because I've tried setting up the new account, but it takes me forever to re-license all apps and reconfigure them again..

Hey Andrew, I just did a clean install of OS X Mavericks 10.9.1 and did a fresh clean install of Alfred 2.1.1, too (no workflows, plain fresh and clean), and whenever I try to change a setting or import any skin, on next launch the setting is reset and the skin is gone I have tried repairing disk permissions with no luck, then tried changing the permissions myself with no luck either, then tried enabling sync and set to sync in non-dropbox folder then in dropbox and none worked either I can't do anything without Alfred, so what is happening? Could it be that Alfred is not fully compatible with Mavericks? After trying to "debug" the problem, I noticed the several things: 1. inside the "Alfred.alfredpreferences" package, the file "prefs.plist" found in ./preferences/appearance/options correctly shows that "hidehat=true" & "hidecog=true", which means the settings are persisted 2. however, as soon as I quit and relaunch Alfred, both the hat & cog are visible again, even though the previously mentioned file still shows "hidehat=true" & "hidecog=true", which means that Alfred is not reading the settings it just saved even though the settings are correct in the files on disk.. 3. next test: importing a skin; after importing any skin, it gets saved to the "prefs.plist" found in ./preferences/appearance of the "Alfred.alfredpreferences" package, and gets applied right away 4. but, after half a minute or so upon applying the theme, when I open alfred the theme has changed to the default and inside Alfred's preferences window the theme is gone, even though it still shows up in the previously mentioned "prefs.plist", which means again that Alfred doesn't read its own settings after it persists them?? So the conclusion is this: Alfred saves every setting I make, every change I make, but as soon as I quit/relaunch it all settings from disk are completely ignored. Why isn't Alfred reading the settings it saved? Maybe it's related to Maverick's new & more aggressive preference caching?? Because if a clean Alfred installation on a clean Mavericks installation doesn't work, then it's clearly that Alfred isn't Mavericks-ready yet... I really need Alfred to work, because I refuse to see it become wasted money P.S. while reading the forums, I noticed one other person say this exact phrase: "It seems as though Alfred was saving the settings to that location, but then not reading them back from there." - this confirms that Alfred is not reading back the settings it saves on Mavericks

Yep, that did the trick, and my guess is that it had something to do with the design change (=the update area is now under its own tab)

Hey, I just updated to 2.0.3-b187, but the weird thing is that Alfred shows a red error: "Unable to verify v2.0.3 b187" next to the "Updates" button and above the progress bar (if only I could figure out how to attach an image in here...). Is this something that we should be concerned about?

My god, I just had a moment of deep dumbness right now You've just put a big "L" on my forehead Thanks for making it clear!

I don't really know if this is a bug or not, but I've never been able to use the clipboard merging feature, because the instant I press the first "c" while holding the "cmd" key, alfred clipboard window disappears leaving me with the same clipboard contents - it's like it's trying to copy the last item from clipboard, because "cmd+c" is for copy, so the second "c" never gets caught ( I don't understand why this is happening, and I really needed this feature.. my advice would be to let us set the key combination for merging, or at least change the letter from "c" to something else, because it conflicts with MacOS's "cmd+c" copy command

It's currently not possible, but that would definitely be an awesome feature! Alfred devs, this one would really make us "see" the results better

I just wanted to avoid making intermediary script actions to parse input to be sent to a notification - I wanted to send the data directly to the notification output itself, and you must agree that it's tempting to have more than just "{query}"

Splitting the functionality into several pieces would create a lot of duplicate code as for splitting the argument, yes, it's easy to execute, but what do I do if I want the arg="r9996,bjork,all is full of love" sent to both a script action & a notification output? the script will handle the splitting with no problem, but the notification output will take the arg as a whole unless I first put it through a script action, which again creates more code than I first wanted Don't you agree that the above proposed suggestion would open so many more possibilities? just imagine not being limited to "{query}" in actions and outputs...

Hey, From what I know the only way to see the keywords is to browse through all workflows in Alfred... and I don't think there's a workflow that shows all available workflow shortcuts, although it's very doable but involves a lot of work (browsing through each workflow folder, reading each workflow's configuration plist file and searching for keywords, building the results), and I don't think most people would need such a workflow, so I'm sorry to disappoint

Hey guys, Say I make a Script Filter and link it to 4 script actions that each perform a different function, but each action needs a different input from the Script Filter, and this is where the problem begins, because the "arg" attribute can hold only one value which will work with just 1 of the 4 actions Right now the only workaround to this problem is to give the "arg" attribute a separated list of multiple values, and then each action would need to parse the input and search for its piece of data, but it's too much parsing and splitting involved.. My opinion is that we should have some freedom in the XML attributes of the feedback results by letting us define our own attributes in a result and Alfred would automatically send those attributes as individual parameters to the "alfred_script" function, as well as individual {attribute_name} to other predefined actions. For example, script filter would generate this xml result: ... <item uid="rdioartist" arg="r96664" valid="yes" autocomplete="Incubus" artistiname="Bjork" track="All is full of love"> ... And we, the programmers, would then use the following in script action: on alfred_script(arg, artistname, track) -- we use the parameter that is needed for a specific action end alfred_script [later edit]: a big problem with the current design is when you link a script filter to multiple actions AND a Notification action, because inside the Notification action we can't split the separated list of values of the "arg" attribute, and setting the arg attribute to a single value would make the other actions useless So with my suggestion above we would type something like {aristname} or {track} inside the Notification action

Did you know that it's forbidden to use their JSON data? I wanted to create the same workflow, but I asked an IMDB tech guy and he told me that it's forbidden to use those JSONs or any other way of scraping data from their site without their written approval I thought you should know this and be careful with this workflow

Yes Greg, I totally agree, that's exactly how it should work: leaving the UID empty will show the results in ~our~ chosen order.

Hey, Awesome to see this thread, because I've developed an equivalent library for AppleScript (see signature for link if you're an AppleScript lover), so I'll keep my eyes on this thread to see what other users need, what other features we should add to our workflow libraries to make them as similar as possible for all types of Alfred users and programmers, etc. I hope you won't mind that I try to keep my library consistent with libraries written in other languages like yours