Andrew

Good chance that something like this will happen at some point during v2.x

In Alfred, if you set a notification output object to specifically be "Growl", then you can set it up to be sticky per output object. Using growl gives you much more control over the output.

I think embedding an icon into a png file is a bit of OS X magic as the underlying file in OS X (which Alfred is operating on) is unchanged. You may have to find another way to do this as I'm happier exporting raw files from Alfred to make things as clean as possible. I'm going to move this to noted instead of a bug as I need to use my time in the run up to v2 release as carefully as possible. Try to be as succinct as possible in any updates to this too!

I've also changed the title of this bug, as it made me think you were losing all of the icons, whereas it's just something strange going on with one or two icons. After a bit of analysis, when looking in terminal, the original files have the same size as post-export, so I think something may be messed up with your source resources: -rw-r--r--@ 1 preppeller staff 201073 6 Feb 20:54 icon.icns -rw-r--r--@ 1 preppeller staff 253730 5 Feb 07:02 icon_alarm.icns -rw-r-----@ 1 preppeller staff 15391 6 Feb 23:22 icon_alarm.png -rw-r--r--@ 1 preppeller staff 19072 28 Jan 06:51 icon_alarm_loop.png -rw-r--r--@ 1 preppeller staff 20501 28 Jan 06:51 icon_alarm_snooze.png -rw-r-----@ 1 preppeller staff 19515 28 Jan 06:51 icon_hal.png -rw-r--r--@ 1 preppeller staff 18320 28 Jan 06:51 icon_loop.png -rw-r--r--@ 1 preppeller staff 17761 28 Jan 06:51 icon_nuke.png -rw-r--r--@ 1 preppeller staff 18201 28 Jan 06:51 icon_repeat.png -rw-r--r--@ 1 preppeller staff 19459 28 Jan 06:51 icon_snooze.png -rw-------@ 1 preppeller staff 11788 28 Jan 06:51 icon_wtf.jpg I'd also suggest you run your icons through http://tinypng.org (which you'll notice will also see your 270k icon as a 15k icon). The other advantage is it takes this icon down further to just 5k in size. I'm pretty sure there isn't an issue here, just some corrupt source resources.

While the file size is smaller, the icon is still intact, going from 270k down to about 15k... but all the other pngs of the same size are also about 15 to 18k in there, so are you sure the original one isn't just a dodgy file which is being 'corrected' during the export? When I look at icon_alarm.png in the pre-exported and post-exported versions, they look identical.

I can't reproduce this - can you manually zip up the workflow folder so I can try exporting the identical file set.

If you are using file filter (workflow objects), it would be better to specify ~/Library directly in their scopes rather than the main scope... this will keep the default results nice and clean

That's fixed in b112 out today

Just a quick note that this was added to b112 which is now available - you can now set alternative connections on a fallback trigger and access these from the default results fallback

The OS X Metadata service only provisions for folder inclusion, not exclusion, so this isn't possible. Having said that, v2 doesn't include ~/Library/ by default, so unless you have added that yourself to the default search scope, these shouldn't be found.

Alfred always waits for a single script filter object to finish before calling it again, so if it calls on the first character you press and takes a few seconds to reply, it will only get called again with the current query at this point (e.g. if you have typed 6 further characters, the script gets called with these 6 characters, not all the separate times inbetween).

Yep you are right, that isn't how it works Alfred creates extremely refined queries directly to the low level metadata server, bypassing Spotlight altogether - This is how he manages to achieve very high performance. To give users the option to use ANDs, ORs etc, Alfred would have to have his own syntax interpreting and translate that into a correctly formed query. This is something which I have thought about for quite some time, but is very low priority compared to some other stuff in the works. Having said that, Alfred does internally have a way of blacklisting certain types per filter, I'll expose that to the File Filter workflow object preferences if I get time (possibly not for v2.0)

You need to return formed, escaped XML. In this situation, you would need & instead of &. I'm moving this over to the Workflow questions forum as I'd like to keep the bugs forum as clean as possible

Tab auto complete in fs navigation works as designed (if not setup as an action hotkey in Alfred's preferences). It partially or fully autocompletes much like using Bash's tab autocomplete.

Alfred now uses a significantly more reliable method for getting the selected item in OS X using the pasteboard. This relies on the app you are trying to 'grab' the data from to be active, which is why a keyword wouldn't work as Alfred is the active application.

Workflow upgrading is one of the main outstanding things left on my plan for workflows before v2.0 is released

This is likely on the cards for v2.1 but it's unlikely I'll have time to get it in for v2

Alfred doesn't import your bash profile so if you want to use growlnotify, you need to use its absolute path... but why not just echo output from your script and wire the script into a notification output... much easier (and more portable)

By the time v2 is finished (if I get time), if you set a bundle ID, the folder will be the same as the bundle ID and not a generated UID

I actually have a ticket already for exactly this - I should hopefully be able to get around to it before v2 is released

I'm aware of this, but most preference panes need the space which is why there is a minimum size. I have added the full screen option to make editing easier in limited screen space situations. You could always pop your dock to the right hand side (I do this even on my huge screen). I may look into this later, but it's low priority for now as there is quite a bit of other stuff left to do for v2.

I'm actually refining a few bits of this XML today, and adding an item type as file is on the plan. If the file exists, Alfred will standardise the arg (expand and standardise the ~/) and treat it like any other file based result in the default results; i.e. Buffer, Actions, Revel In Finder shortcut etc. My original reasoning for needing this in the XML as it should better support if somebody were to create a NAS search type live search filter returning files. The XML will look something like this: <item uid="filter.desktop" arg="~/Desktop" valid="YES" autocomplete="Desktop" type="file"> <title>Desktop</title> <subtitle>~/Desktop</subtitle> <icon type="fileicon">~/Desktop</icon> </item> The important part is type="file" on the item. Just for completeness, I'm also going to add type="file:skipcheck" which will skip the file exists check, in case it's on a slow NAS or drive, which could get in the way of results showing quickly if you know the files being returned do already exist. This will be in the next build, after b94

Alfred actually makes this quite easy for you, you can add a type parameter to the <icon> part of the XML to show file types e.g. <icon type="filetype">public.jpeg</icon> ...to show the icon for the UTI. If you want the actual icon for the file, you can use e.g. <icon type="fileicon">~/Desktop</icon> ...to get the actual icon used for the given path.

Hi Chaps, Once you start to release in multiple languages, it opens the floodgates to needing to be translated into all languages. Internationalising an app takes a HUGE amount of commitment from the translators, and as a new release would have to wait on the slowest translator, this would SIGNIFICANTLY slow down Alfred's very fast and iterative release cycle, not to mention add an additional burden on me and Vero managing and verifying translations. To put things simply... If you love how fast paced Alfred's development is and like my iterative approach to releasing early and often, then multi-language is simply out of the question. Hope that clears things up! Cheers, Andrew

I actually already have a ticket for adding an "External" trigger type for workflows, which can be called through Alfred's AppleScript interface If this doesn't make it into v2.0, it will likely make it to v2.1