Jump to content

Wildcard

Member
  • Content Count

    64
  • Joined

  • Last visited

  • Days Won

    1

Wildcard last won the day on July 9 2013

Wildcard had the most liked content!

About Wildcard

  • Rank
    Member

Recent Profile Visitors

772 profile views
  1. The only illegal character in a file path is a null byte. No other delimiter is guaranteed not to appear in the path. (Related: Why not parse the output of ls?) Particularly when dealing with music files, there are all kinds of unusual characters that quite commonly appear in filenames. Perhaps what I want should simply be a native feature of Alfred? It could be disabled for those who don't want it, just as any other built-in file action—but I'm sure I'm not the only one who would have a use for creation of aliases, symlinks and hard links through Alfred's excellent File Actions interface. If the clean and smooth "Copy to..." and "Move to..." workflows (in the English sense) are impossible to replicate with a user defined workflow (in the Alfred sense)...I expect they'd be fairly trivial to add in the underlying code, starting from a replica of the "Copy" and "Move" file actions. I just upgraded to Alfred 3 today and got my Mega Supporter license. Hoping I won't have to use some other tool, e.g. Path Finder or something, to make this workflow possible....
  2. Hello, I'm trying to create the ability to mirror the actual workflow aspect of the file actions "Copy to..." and "Move to...." Specifically, I want to be able to: 1. Select a file, or multiple files, through Alfred's file buffer or in the Finder. 2. Trigger Alfred's "File Actions" menu. 3. Select my workflow action from the list. 4. Choose a target folder, using Alfred's search (or even better, using Alfred's "browse" feature, but that's not how "Copy to..." works). 5. Run an action (e.g. shell script) on the selected files, with the "target folder" available in some fashion as well. The specific use case I have is to enable the creation of aliases, symlinks, or hard links in a specified location for the selected files. However, I haven't been able to figure out how to link together actions in a way that allows this. Saving the query to a var is confusing, because it's not clear how multiple selected files can be saved in that way. Then, I can't figure out which "action" to choose to allow searching for a folder (preferably with the selected files still shown in the pane to the right, just like they are in "Copy to..." and "Move to..."). Can someone provide some tips or a nudge in the right direction, please? Thanks very much, --Mike
  3. Awesome, thanks Andrew! In that case I will probably upgrade soon.... In the meantime, I actually made a workaround using BetterTouchTool—which is the only application that I install before I install Alfred on a new computer. I set Alfred's File Actions key to something complicated (that I won't need to use with anything else), and then I use BTT with (option /) to (a) switch keyboard layouts (b) wait 0.1 seconds so the layout actually switches (c) trigger Alfred's File Actions hotkey (the complicated one) and (d) switch layouts back. But yeah, it would be nice not to need that. After I'm done migrating to this new computer I'll make the plunge for Alfred 3. Thanks for your constant work to improve the product.
  4. Cool; makes sense. If I ever do anything with it I'll post it here, but I agree it's probably more work than it's worth.
  5. This is pretty cool! Do you have any plans to make it accept an argument of which site to search? I looked into the Python code and I see that the "SITE" parameter can be modified, but since I am a routine visitor of unix.stackexchange, apple.stackexchange, superuser, stackoverflow, occasionally askubuntu, it would be nice if I could search any one of these...without making 5 copies of the entire workflow just to edit that one parameter! P.S.: I'm willing to attempt this myself, but I am a beginner with Python so I would need some tips, preferably from the original author. Now if it were in bash, I would have already edited it myself.
  6. Hey, bug report: If you search for the word "timer" on http://www.packal.org you see some really weird low level error.

  7. I shut down Alfred, switched to QWERTY layout, removed both Alfred-related directories from ~/Library/Caches/, removed both relevant files from ~/Library/Preferences/, removed ~/Library/Application Support/Alfred 2/ (after saving the license file), started up Alfred with factory settings, loaded in the license so I could access PowerPack features again, and tried using the default keyboard shortcut for File Actions: ⌥⌘\ It worked successfully. I made no other changes except switching layouts to "Dvorak - Qwerty ⌘" and tried activating the File Actions menu again. I got the "Info" pane instead. Whatever I said in 2013 about it working for other people or other accounts was using version 2.0.5, not version 2.8.6. As my later testing revealed (and as is described earlier in this thread), in version 2.0.5 through at least version 2.3, if Alfred is started while the Qwerty keyboard is active, and the File Actions hotkey is triggered while the Qwerty layout is still the active layout, then the File Actions hotkey will work correctly regardless of later keyboard layout changes. In those same versions, if Alfred is started while the Dvorak - Qwerty ⌘ layout is active, and if the File Actions hotkey is first triggered with that keyboard layout active, then the File Actions hotkey will only open the File Info pane of Finder (what you get with the OS keyboard shortcut ⌘I), even after further keyboard layout changes—even if it's changed to Qwerty. This behavior changed between 2.3 and 2.8.6. In version 2.8.6, regardless of what keyboard layout is active when Alfred is started up, if the Dvorak - Qwerty ⌘ layout is active when you trigger the File Actions hotkey, the "Get Info" window is what will appear. And in version 2.8.6, regardless of what keyboard layout is active when Alfred is started up, if the Qwerty layout is active when you trigger the File Actions hotkey, the hotkey will work correctly. (In my earlier test from another user account using version 2.0.5, I had started Alfred with the Qwerty layout active before switching it to Dvorak - Qwerty ⌘. Therefore my conclusion at the time that it "worked from another user account, just not from mine" was actually invalid and based on insufficient testing.) So no, the problem doesn't lie with my user account. The above can be reliably reproduced on the latest build of Alfred on a brand new computer with no prior Alfred installation (and no lingering preferences). This is purely an Application-level bug in Alfred. I hope that info is more helpful for diagnosis? I wouldn't be writing all this at all if I didn't really care about Alfred's functionality, and rely on it constantly. Do you think the developers could please have a look at this?
  8. I've just tried it with all my other utility applications disabled with the same results.
  9. If you can't reproduce it using the steps above, tell me how to completely wipe and reinstall Alfred on my El Capitan computer and I will attempt to reproduce it with NO adjustments to settings from the default. But I think the above two steps would be enough.
  10. I just used a FRESH install of Alfred 2.8.6 on a FRESH install of Mac OS 10.11.6 and reproduced the problem with no trouble at all. Please don't blame the user before you've at least made an attempt to reproduce the reported bug. (This reminds me of https://xkcd.com/806/) Steps to reproduce: 1. Set keyboard layout to "Dvorak - Qwerty ⌘". 2. Attempt to launch the "File Actions" menu in Finder using the keyboard shortcut defined in Alfred. Results: The "Get Info" window appears for the selected file. Now, I have made a VERY few other adjustments to my preferences on this particular computer, but (a) none of them should be relevant (b) nothing was imported from my previous Alfred install where I first had this difficulty and (c) this is a different computer, not just a new OS on the same hardware. If you can successfully trigger the "File Actions" menu from Finder with the "Dvorak - Qwerty" keyboard layout set, using any key combination, I will be impressed. I really love the context menu (a.k.a. File Actions menu) in Alfred. "Open with..." and "Move to..." as well as "Email to..." are in constant use, so it is really a great irritation in my workflow to have to switch keyboard layouts before the context menu will work.
  11. I foolishly upgraded to 2.8.6. Is this fixed in Alfred 3? If so I would bite for the paid upgrade. Not really thrilled with the "oh well" response. Succinct statement of bug: "file action" trigger does not work on alternate keyboard layouts—period. That seems like a bug worthy of fixing.
  12. I'm using version 2.8.6 (441). I want to modify some of the built-in web searches, and there appears to be no way to do this. Specific use case: I want to modify the "amazon" search so that it searches smile.amazon.com instead of www.amazon.com. I can't do this (that I can see). I consider this a bug. The workaround is rather tiresome: I must add a new custom search (figuring out the search URL myself), disable the default one, and dig up the right graphic for the custom search. Then forever afterward I will have the built-in search cluttering up my list of searches.
  13. Going to bump this ancient bug report: I have been running consistently on 2.3 because once my software works I leave it alone. The other day I accidentally upgraded to 2.8.3. 2.8.3 fixes half of the issue described above, because it no longer matters what the current keyboard layout is while Alfred is running—but it breaks the more important half. Using 2.8.3, with Dvorak as the keyboard layout while using Finder, there is simply no way to activate the File Action menu, regardless of the keyboard layout that was set when Alfred started up. I'll just get the "File Info" window unless I switch to QWERTY layout before activating the file action hotkey. This is more logical in a sense; it's not exactly an intended feature to behave differently depending on the keyboard layout that was set during app startup. Nevertheless, this breaks the workaround I had worked out above. Is there another workaround possible (or better yet, a permanent fix?)
×
×
  • Create New...