Jump to content

Pennyworth

Member
  • Posts

    46
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Pennyworth

  1. Since it's a Mac App Store app, the note files are containerized in the following directory: ~/Library/Containers/com.microsoft.onenote.mac/Data/Library/Application Support/Microsoft User Data/OneNote/ They're stored as an offline cache (synced to the master file on Microsoft OneDrive) in a proprietary .onecache extension, with assets of each note stored separately as .onebin files. It's not pretty and I don't have enough skills to reverse engineer this. Command-line tools are available for Windows, and they're limited to repairing the database and other maintenance tasks.
  2. Thanks for the feedback. Unfortunately, OneNote doesn't have an AppleScript dictionary. Just to confirm, I Googled around and found others complaining of this too. Is that game-over as far as Alfred is concerned?
  3. This workflow is implemented really well but isn't the point of two-factor authentication to have two separate physical devices required to authenticate yourself? What's the point if both factors are on your computer (assuming the computer is what's being authenticated into, and not another device like a smartphone or tablet)?
  4. I'd like a workflow that can search Microsoft OneNote for Mac (notebooks, sections, pages) and possibly also create notes. Alternatively, how would I be able to build this myself?
  5. Does anyone know how I can customize this workflow so that I can quickly access presets with a keyword like "hue p" ?
  6. Tyler, thanks so much for your help and linking to that workflow. I gave it a shot and it still didn't solve the problem, despite successfully rebuilding the external drive's spotlight index (unlike the Alfred Metadata Rebuild button). That means this is a problem with the specific library packages I'm dealing with. iPhoto's been neglected by Apple for so long that I'm hoping the new Photos.app in Yosemite will fix this.
  7. I did that, and as expected, the .Spotlight-V100 folder on the external drive was not touched by this process. It only indexed the main system drive, which is not where the problem lies. I know this because I enabled hidden files to be shown and watched what happened in the root directories of both drives once I started the rebuild process. My file search results still include the contents of iPhoto Library packages. This isn't a Spotlight issue, this is something else relating to these iPhoto Library packages on the external drive. The current remedy is to manually add the package contents to the Spotlight privacy exclusion list. It's a hack, but it works.
  8. I deleted the .Spotlight-V100 folder on the external drive and added/removed the drive from Spotlight Privacy to re-index. It still didn't work. Should I be using Alfred's "Rebuild OS X Metadata"? Is that any different from doing what I did?
  9. I forced a reindex of the drive by adding it to the Spotlight Privacy exclusion list and then removing it -- but it didn't help. (Sidebar: is this different from Alfred's metadata rebuilder?) What finally worked was that I right-clicked the libraries, selected 'Show Package Contents', and manually added the contents to the Privacy exclusion list. This works better than simply adding the library to the exclusion list because I wasn't able to search and access just the library with that workaround, but now I can. For now, problem solved, but I suspect there's some kind of bug with iPhoto library packages. Hopefully Photos.app in Yosemite fixes a lot of these oddities.
  10. I can confirm now that something is definitely wrong with how Spotlight/Alfred indexes iPhoto library packages on internal vs. external drives. These library packages are "opaque" on the internal drive. That is to say, you can't see inside them in search results (expected behavior). On my external drive, these packages are transparent, so you can see all their garbled garbage. Also, on the same external volume, I cannot search inside iMovie library packages (expected behavior). So something about iPhoto library packages on an external drive is off. I don't know why this is or how to turn it off but help would be much appreciated.
  11. Yes, it's Mac OS Extended (Journaled). I'm also running 10.9.4. I should also disclose that I've manually added to Alfred's 'Search Scope' list the folder in which those iPhoto library packages are located. I didn't know of another way to incorporate them into my results. They're on an external drive connected via USB. This must have something to do with it.
  12. Tyler, The problem is that by adding certain files to the Spotlight Privacy blacklist, I'm no longer able to search for them! For example, I have two iPhoto libraries on an external hard drive. I also have two on my internal disk. Currently, the contents of the external libraries are indexed by Spotlight (as are the main library files themselves, so I can open them in iPhoto). When I add the two external libraries to the Spotlight Privacy blacklist, their garbled contents no longer clutter my search results. This is great. At the same time, I'm no longer able to quickly access these iPhoto libraries through search results! Confusingly, the iPhoto libraries on my internal drive do not have their package contents clutter up search results, they just appear as opaque files (which is the desired behavior). Something just seems off about all this.
  13. I know Alfred uses the Spotlight index to power its search results, so my question is: How can I disable Spotlight from indexing the content of package files, particularly iPhoto or iTunes library files? The contents of these packages/libraries are cluttering up my Alfred results like no body's business. It's basically making Alfred dysfunctional for searching files and folders. I'm getting all kinds of irrelevant results with long strings of random characters (because that's how package/library data is named). It's really impacting my experience and I want to fix it ASAP. Thanks community for any advice you have. Screenshots below:
  14. Shawn, thank you so much! Your workflow is great!
  15. The new preferences in flux are so different I knew there'd be big changes behind the scenes. I gotta say: a big thank you for getting on top of this. Your workflow is awesome!
  16. I just uninstalled the workflow, updated Alfred to 2.3, reinstalled the workflow, and it still doesn't work. There must be something causing this in my machine as well as the others who are complaining.
  17. I have the same issue. Either OS X 10.9 or f.lux 30.0 or both in combination broke this Alfred workflow. Add me to the list of people who'd like to see this fixed. Or if someone could at least explain how the workflow is put together so we can fix it ourselves... that would be much appreciated as well.
  18. That's what I was doing -- using a custom search -- to get around the problem. Looking forward to the fix. Thanks Andrew!
  19. I'm having the same problem. Google Image Search is broken for me. It seems like Google's search query string is much longer and includes many more variables than the simple one Alfred outputs. Something needs to change. Google's Image Search result URL for query "pasta": https://www.google.com/search?safe=off&site=&tbm=isch&source=hp&biw=1280&bih=1275&q=pasta&oq=pasta&gs_l=img.3..0l10.195.605.0.755.5.4.0.0.0.0.117.277.3j1.4.0....0...1ac.1.34.img..1.4.277.IQq668Z5Fdg Alfred's Image Search result URL for query "pasta": https://images.google.com/images?q=pasta (with a 404 error) Using Google Chrome v32.0.1700.107 (1700.107) on Mac OS X 10.9.1
  20. Thanks for the alternative method RodgerWW! That would certainly help people without a plist editor. I realized the problem because I have a Mac mini and a MacBook Air that were both showing the ID of my old machine, a MacBook Pro (since they're both restored from that machine's backup). That's when I knew it had to be some type of residual data stuck somewhere in my system. I parsed your script to see how it was generating the text files and which plists it was referring to and eventually I figured it out. (This was a lot of fun, I must admit.) In any case, thanks for this workflow. It seems so obvious to type 'about' into Alfred that it could easily have been one of the included System commands that shipped with the software.
  21. I've finally figured out this problem! I was having the same issue and after a bit of research, got it to work. You need to edit a plist file that has somehow retained your old machine's identifier and edit that information out. Here are the steps: Open the following file with a plist editor of your choice (Xcode, PlistEdit Pro, etc): ~/Library/Preferences/com.apple.SystemProfiler.plist Under the 'CPU Names' field, locate the identifier for your current system as well as the identifier for your previous system. Delete that old identifier. Save the plist file. In Alfred, reset the About workflow by typing the keyword: xabout When you run the workflow again by typing the keyword 'about', you should now see the correct 'System (Model Identifier)' entry!
×
×
  • Create New...