Jump to content

Recommended Posts

@pontus While adding Notes as a built-in searchable feature has been on the cards for a long time, Apple constantly change the Notes data (e.g. used to be individual files, now is a single file in High Sierra) and its location. This makes it difficult for us to provide a reliable, stable feature to users on all OS versions when Apple keeps moving the goalposts.

 

As such, it'll most likely always remain something that's searched via workflows, unless Apple starts to offer a public API we can rely on.

 

Cheers,
Vero

Link to comment
On 09/11/2017 at 12:27 AM, Jasondm007 said:

Any chance of this coming back in a High Sierra-friendly version?

 

To expand on what @Vero said, the same applies to workflows, only (sometimes) more so.

 

Andrew’s a professional developer, so having a couple of old machines around to run older or beta versions of an OS is part of the job, as is Apple moving the goalposts to some extent.

 

Many of us workflow developers don’t have multiple machines and/or can’t run multiple versions of macOS just to test stuff. Some of us are stuck on older versions of macOS for various reasons, even if we could find the time to rewrite our workflows because Apple has changed something.

 

Which is to say, something that presents a significant problem for Andrew can easily be a much bigger problem for a hobbyist workflow developer (though the converse is often also true).

 

In this particular case, it seems Apple has done what they did with Safari’s history and moved the notes from individual files to an SQLite database. The workflow is written in AppleScript, which can’t natively read such a database. That means that it’ll take a lot of work for this workflow to support High Sierra.

 

I have no idea what @surrealroad is doing or planning to do. I just want to emphasise how difficult it is to update this particular workflow as a result of Apple’s changes.

Link to comment

Thanks for that @deanishe. There are a couple of options that could be pursued, but they're all significant and they're all theoretical. I'd love to be able to experiment and figure this out but I just don't have the time. So, realistically, I'm waiting to see if someone else finds a way to access the notes in an easy way, and if so I can try something similar in this workflow.

 

I am not holding my breath though. Unfortunately Apple just doesn't care about making this stuff work outside of their native apps, particularly outside of iOS. That's fine-- the native notes app works well enough for what it does for a large segment of the userbase. It was exactly the same story with my reminders workflow a few years back- things changed under the hood making it too difficult to get the list of reminders into Alfred, but there's still value in using Alfred to create reminders (likewise using this workflow to create notes quickly, I hope).

 

Hopefully someone will just create some kind of API or something that lets you access this data easily on macOS and I'll be able to take a fresh look at it, but right now, sorry not going to happen :(

Edited by surrealroad
Link to comment

Hello all - as a workaround I have found this script works. 

 

Just create a normal alfred workflow - keyword (with space, argument required)  to run applescript and use this

 

on alfred_script(q)
  tell application "Notes"     activate     tell application "System Events" to keystroke "0" using command down     tell application "System Events" to keystroke "f" using {command down, option down}
tell application "System Events" to keystroke q 
end tell
end alfred_script

 

Hope that helps,

 

Link to comment
2 hours ago, rpowellweb said:

Hello all - as a workaround I have found this script works. 

 

Just create a normal alfred workflow - keyword (with space, argument required)  to run applescript and use this

 

on alfred_script(q)
  tell application "Notes"     activate     tell application "System Events" to keystroke "0" using command down     tell application "System Events" to keystroke "f" using {command down, option down}
tell application "System Events" to keystroke q 
end tell
end alfred_script

 

Hope that helps,

 

 

Thanks, I've done the same thing with native workflow objects. Works ok as a temporary solution.

Link to comment
  • 6 months later...

@40-02 Thanks for the tip! I didn't realize that Spotlight could search the Notes app. 

 

By chance, do you know how to limit Spotlight's results to the Notes app (without impacting Alfred's search capabilities)? If I have to use Spotlight to search for notes, then I'd love to only see notes in its results (or at least have them placed at the top of results to avoid having to scroll down). Thanks!

Link to comment

Hey guys, I made a version that works on High Sierra: http://www.packal.org/workflow/search-apple-notes

 

It gives a couple options:

- Use Python to open a SQL database and AppleScript to open the note directly (fast but I've only tested on High Sierra)

- Use AppleScript to get all the note names and then find the requested note and open it (decently fast, should work for other OSes)

- Use AppleScript to get all note+folder names then do the same as above (slow)

 

If anyone is an AppleScript wizard, it seems like building the output string for Alfred takes the longest time, and this thing could be fast and cross-compatible if that was fixed.

Edited by sballin
Link to comment

@sballin this is quite promising, thank you!

 

But it didn't work for me. Could you be so kind as to take a look into debug and tell if I can repair it?

Starting debug for 'Search Notes.app'

[2018-07-26 11:03:14][ERROR: input.scriptfilter] Code 1: Traceback (most recent call last):
  File "/Users/uvarofff/Documents/! temp files archive/tempAlfred/Alfred.alfredpreferences/workflows/user.workflow.9D0B4217-85AB-4197-8355-79D02FFA4F76/searchNotes.py", line 35, in <module>
    for m in matches]
TypeError: 'NoneType' object has no attribute '__getitem__'
[2018-07-26 11:03:16][ERROR: input.scriptfilter] Code 1: Traceback (most recent call last):
  File "/Users/uvarofff/Documents/! temp files archive/tempAlfred/Alfred.alfredpreferences/workflows/user.workflow.9D0B4217-85AB-4197-8355-79D02FFA4F76/searchNotes.py", line 35, in <module>
    for m in matches]
TypeError: 'NoneType' object has no attribute '__getitem__'

 

Edited by 40-02
Link to comment
11 hours ago, 40-02 said:

I guess you can do it in spotlight settings. But I don't know what exactly you need to keep turned on. 

2018-07-26_08-15-34.png

2018-07-26_08-17-58.png

 

@40-02 I'm afraid I don't think you can go that route, as Alfred uses Spotlight's indexed metadata for its own results (i.e., and you're effectively telling Spotlight, not to index several things that you'd probably like to see in Alfred's results, like Images, Folders, etc.) (See #3 - https://www.alfredapp.com/help/troubleshooting/indexing/)

 

 

Link to comment
9 hours ago, sballin said:

If anyone is an AppleScript wizard, it seems like building the output string for Alfred takes the longest time

 

Unlikely: with AppleScript most of the overhead is generally in connecting to the application in the first place. On my machine this typically takes ~0.3s. Reading the data will usually take a small fraction of that time unless you have an epic number of notes to read.

 

The best way to handle this is typically to at least cache the data for several seconds/minutes, and better yet, to fetch them in the background while the live workflow works with the (very fast) cached data.

 

Also, your AppleScript code is fundamentally broken because you're trying to create JSON by smushing strings together. That never works. If someone has a note that contains, say, a quotation mark (i.e. ") or non-ASCII text, your JSON will be invalid. It would be smarter to use JXA instead of AppleScript, as it has native support for JSON.

 

Link to comment
2 hours ago, deanishe said:

Unlikely: with AppleScript most of the overhead is generally in connecting to the application in the first place. On my machine this typically takes ~0.3s. Reading the data will usually take a small fraction of that time unless you have an epic number of notes to read.

 

You were right, I did some more testing and it's actually the accessing the name of each container (folder) that's taking up time. Currently I'm doing it as

 

set noteRefs to a reference to every note in default account

set containers to container of noteRefs

(inside the loop:) name of item i of containers

 

So to make it fast I probably need to deal with references of the containers instead of the containers themselves, but I'm not sure how the syntax for that looks. For me the whole thing runs in less than 0.1 seconds without containers, and 2 seconds with them.

 

2 hours ago, deanishe said:

Also, your AppleScript code is fundamentally broken because you're trying to create JSON by smushing strings together. That never works. If someone has a note that contains, say, a quotation mark (i.e. ") or non-ASCII text, your JSON will be invalid. It would be smarter to use JXA instead of AppleScript, as it has native support for JSON.

 

Good point, I forgot about that. I henceforth ban unusual characters in note titles! I didn't know about JXA though, I'll look into it.

 

3 hours ago, Jasondm007 said:

@sballin Is there any way to get the workflow to search the full body of the notes?

 

At the moment, it looks like it's only searching for matches with (1) the first line of text in a note, and (2) folder names.

 

Thanks again!

 

Glad you like it. I poked around and couldn't easily find the note text in the SQL database. It might be easier to get with the AppleScript methods, but it wasn't immediately working for me, probably because they're stored in HTML and we want them as a string. I will try to look into it further. I'm happy to include searching the body too as an option, but I made it search titles only for now because I like the more specific search scope.

Link to comment
16 minutes ago, sballin said:

I henceforth ban unusual characters in note titles!

 

:D

 

@sballin I think at this point, it might be a good idea to start a separate thread for your workflow. Unless @surrealroad has abandoned his, this discussion doesn't really belong in his workflow's thread, imo.

 

Edited by deanishe
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...