jvdneut

The "2.0" workflow that I linked to in the first post has been doing just that recently. See: http://www.alfredforum.com/topic/1993-menu-search/page-4

Good job keeping the workflow alive. I modified my original post to point to this new topic, hopefully that will help people find this newer version. Is the source code to your menudump executable as well on your github? I would prefer for things to work without any form of cache, which could possibly be achieved by limiting the recursion depth of the menus (assuming that you are recursing). That would probably also allow handling (probably hiding) of disabled menu items. Disabling caching would also make toggle menu items (such as Safari's "Show Web Inspector"/"Hide Web Inspector") work properly. The goal would be to get the entire workflow to execute in less than 200 milliseconds. 100ms would be better, as it has that instant feel to it, but 200ms would still feel semi-instant.

I've been trying to get AppleScript to produce a cleaner bit of menu bar information, but keep getting stuck as I can't figure out how to recurse on these menu bar objects using AppleScript. Retrieving the properties of an object works when I ask it directly (see marker A1), but not when I use it in a "function" (see marker A2). In order to get the property at A2 I seem to have to cast the variable to a type, but that doesn't work either because the type contains a space (see marker . Maybe someone more familiar with AppleScript can tell me how to do this. on run argv tell application "System Events" set _app to item 1 of (every process whose frontmost is true) end tell tell application "System Events" tell _app set menustuff to menu bar 1 --(A1) retrieving property here does work --return menus of menustuff return my recurseMenu(menustuff) end tell end tell end run on recurseMenu(menustuff) --( casting doesn't work --set castMenuStuff to menustuff as menu bar --(A2) retrieving property without casting also doesn't work return menus of menustuff end recurseMenu In any case, what it is I'm trying to do is this: recursively walk through the menus and menu items, record their title (e.g. "New file"), path (e.g. "File-->New file"), enabled state and shortcut (e.g. Command+N). When recursing it would also become simple to add a depth constraint, which will avoid cases like ctwise and The_Ben mentioned in the case of Chrome.

Pretty much, yes. I still intend to implement fuzzy searching ("wi" to match "show Web Inspector" for example), but I'm not particularly satisfied with the performance right now. I will have to figure out a way to implement caching properly first.

I was actually looking into Objective-C as well now. QuickSilver (http://qsapp.com) has a similar feature for accessing menu bar items through their UI Access plugin. The source for that is on: https://github.com/quicksilver/UIAccess-qsplugin

Ted, good job on the caching. I'm currently using your workflow instead of my own I am still exploring AppleScript to see if I can produce better results directly from it. Disabled entries should not be listed for one. Also the cache is sometimes out of date when using a toggle (Show/hide) menu option.

Cool. I was hoping someone else would pick up where I left. I'm planning on making the script a bit more useful, but that will probably involve me actually having to learn AppleScript to a decent level... Did you make the changes using some more grep / sed commands or using some actual form of scripting? I am a programmer by trade, but unfortunately I don't know any AppleScript, Python, Ruby or PHP, but I guess I'll have to learn in order to make this thing a little more useful.

I would be perfectly happy implementing a cache. This would be a whole lot easier if Alfred gave me something to work with though. If it could pass a "instance identifier" that would change every time the workflow was entered (or Alfred was displayed/hidden even) that would be perfect. With respect to having a bunch of things listed in Alfreds initial search: I did not mean to list the entries retrieved by the workflow, but the workflow itself. In my case this would be "Menu bar search", not the actual menu bar items. This is something I could live without, but would probably make having many workflows easier to work with.

Hi, I've just created my first workflow (http://www.alfredforum.com/topic/653-menu-bar-search/) for searching the system's menu bar. The main problem that I encountered here is that Alfred executes my script for every keystroke. I would prefer if Alfred could execute my script only once and then have it filter the results based on it's regular "fuzzy" search. This would make my workflow a whole lot faster. Another thing that might be useful is to allow static XML files to be used as input for a workflow. This would allow me to define a bunch of snippets for example in an XML file and have Alfred search them and copy them to the clipboard. Finally, I also think it would be useful if workflows could be initiated without keywords, but simply displayed as entries in Alfred's initial search. Jeroen van der Neut @jvdneut

Hi, I've created a basic workflow that searches the system's menu bar. After having used Sublime Text's command palette I wanted to have a similar system-wide functionality. EDIT: For people that haven't worked with Sublime Text's command palette: the command palette allows you to fuzzy search the entire application menu by keyboard. This saves both time on hunting down the right menu and saves you having to remember all sorts of keyboard shortcuts. For a brief introduction on Sublime Text's command palette see https://tutsplus.com/lesson/the-command-palette/ EDIT: Better use ctwise's "2.0" workflow http://www.alfredforum.com/topic/1993-menu-search/ [old download is still available at http://dl.dropbox.com/u/6259900/Menu%20bar%20search.alfredworkflow] The current workflow does not do any fuzzy searching and every keystroke executes the entire script again. My preferred fix to this would be to have a script input that is only executed once, and have Alfred do the subsequent fuzzy matching based on the initial result. Jeroen van der Neut @jvdneut