Jump to content

Search and add bookmarks to Raindrop.io


Recommended Posts

Hello @andreas.w! Sorry for the late reply because I've been distracted by personal stuff and things fell through the cracks.

 

I just upgraded to search_raindrop-1.6.1.alfredworkflow but unfortunately the issue seems unchanged on my end. The tokens.json file still contains only the timestamp and no authorization info.

 

I would be glad to provide further assistance so feel free to reach out to me. Thank you for all the hard work!

 

Link to comment
  • 3 weeks later...
  • 5 months later...
On 1/10/2021 at 2:30 PM, AV8RDude said:

I see some questions re: authentication but none of the answers apply in my case.  I have v1.6 of Search Raindrop.io installed.  When I type "r " I get prompted to authenticate with Raindrop.io.  I hit enter and am taken to Raindrop.io where I click on "Agree".  At that point, I am redirected to 127.0.0.1:11038/?code=<some code> and I get an error saying this site cannot be reached, connection refused.  This error occurs on all browsers.

 

I'm able to ping 127.0.0.1.  I suspect this is an issue on my end (since the workflow seems to work for others) so I'm just looking for suggestions on where to look to debug this issue.  Any advice appreciated. 

 

On 1/10/2021 at 2:34 PM, deanishe said:

 

That IP address is "localhost". It always means the machine you're using. If you're getting a "connection refused" error, the workflow's webserver isn't running.

 

Look in Alfred's debugger for a proper error message.

 

On 1/10/2021 at 3:31 PM, andreas.w said:

 

Exactly!

 

I can look at this problem, @AV8RDude, if you get the error message that you'll find in the debugger, as @deanishe said.

You could send the log messages you see in the debugger in a private message to me if you don't want to post it for everyone to see.

First open the debugger, as in the linked instructions, then make sure to do the same thing you did when the problem occurred, and then copy and send the log messages you see in the debugger.

 

I also think I would need the same thing from you, @xurc, to be able to find out what's going wrong in your case.

 

Hey @andreas.w and @deanishe I think I am having the same problem as AV8RDude with authentication.

Here are my logs, there is nothing weird happening that I see. Note, I changed my real client_id to 'myClientID'.

 

[13:09:13.871] Search Raindrop.io[Script Filter] Queuing argument '(null)'
[13:09:13.960] Search Raindrop.io[Script Filter] Script with argv '(null)' finished
[13:09:13.961] Search Raindrop.io[Script Filter] {"items":[{"arg":"https:\/\/raindrop.io\/oauth\/authorize?redirect_uri=http%3A%2F%2F127.0.0.1%3A11038&client_id=myClientID","subtitle":"Press enter to authenticate now","title":"You are not authenticated with Raindrop.io","valid":true}]}
[13:09:16.259] Search Raindrop.io[Script Filter] Processing complete
[13:09:16.263] Search Raindrop.io[Script Filter] Passing output 'https://raindrop.io/oauth/authorize?redirect_uri=http%3A%2F%2F127.0.0.1%3A11038&client_id=myClientID' to Conditional
[13:09:16.264] Search Raindrop.io[Conditional] Processing complete
[13:09:16.264] Search Raindrop.io[Conditional] Passing output 'https://raindrop.io/oauth/authorize?redirect_uri=http%3A%2F%2F127.0.0.1%3A11038&client_id=myClientID' to Conditional
[13:09:16.265] Search Raindrop.io[Conditional] Processing complete
[13:09:16.265] Search Raindrop.io[Conditional] Passing output 'https://raindrop.io/oauth/authorize?redirect_uri=http%3A%2F%2F127.0.0.1%3A11038&client_id=myClientID' to Arg and Vars
[13:09:16.266] Search Raindrop.io[Arg and Vars] Processing complete
[13:09:16.266] Search Raindrop.io[Arg and Vars] Passing output 'https://raindrop.io/oauth/authorize?redirect_uri=http%3A%2F%2F127.0.0.1%3A11038&client_id=myClientID' to Run Script
[13:09:16.927] Search Raindrop.io[Run Script] Processing complete
[13:09:16.930] Search Raindrop.io[Run Script] Passing output 'Alfred Preferences
' to Arg and Vars
[13:09:16.931] Search Raindrop.io[Arg and Vars] Processing complete
[13:09:16.932] Search Raindrop.io[Arg and Vars] Passing output 'Alfred Preferences
' to Conditional
[13:09:16.932] Search Raindrop.io[Conditional] Processing complete
[13:09:16.933] Search Raindrop.io[Conditional] Passing output 'Alfred Preferences
' to Open URL

 

Edited by mdubsss
Link to comment

There is now a new version of this Workflow, v1.7!

 

The most important change here is that support for macOS Monterey is added.

Apple removed PHP from Monterey (which has been preinstalled since Mac OS X 10.0 in 2001), so some changes had to be made to adopt to that, and you will also need to install PHP yourself for it to work in Monterey, which I recommend that you follow PHP's own instructions for if you have not already installed it.

 

There is also quite a few more potential problems that are fixed with this update, so if you where having problems with this workflow before, please try again with this update and hopefully it will work better.

 

There are also some new features!

Bookmarks that you have marked as favourites in Raindrop will now be indicated, and will also by default be listed on top of results, and you can also now browse your Unsorted bookmarks the same way as you can browse other collections.

 

Download from Packal or GitHub!

Link to comment
  • 3 weeks later...

Is there any chance I'm missing a way to just manually enter/paste in a URL? I'm testing (and loving) SigmaOS as my browser but it's early and there's no native way to add something to Raindrop.io, moreover, I doubt there are any hooks you could use to grab the URL of the current tab progromatically. Copying and pasting the URL into Alfred seems like about the best workflow currently possible if I find a workflow that supports it.

Edited by chrisWhite
Link to comment
  • 3 weeks later...

Just released version 2.0!

 

This is something that I realized maybe a year ago that I wanted to do eventually, to rewrite all the PHP and Python (which is almost all of what this workflow used to be) in a way that will make it work without external dependencies when Apple stops providing PHP and Python with the OS (which has been know for a while that they will eventually stop doing)

 

With macOS 12 Monterey, which will be released possibly as soon as the coming week (but more likely next month), PHP will be gone, which means that this workflow would not function if you did not manually install PHP yourself, and while I did some changes in version 1.7 recently to make the workflow function with a version of PHP that you have installed yourself, I do really not like the idea of requiring PHP to be manually installed for my workflow to function, and it is also just a matter of time before Python goes away as well. Likely next year.

 

So I have rewritten everything that was written in PHP and Python in Go instead. Which means that almost everything is entirely rewritten (there is just a bit of AppleScript that has only changed a little)

 

Go is a compiled programming language, and it does not require any runtime to be installed to function once the code is compiled. This means that the workflow is not dependent on Apple to provide support for something like PHP or Python in macOS anymore, and Go also has the added benefit of being faster than a scripting language like PHP.

 

Version 2.0 does not really look or behave as different as the version bump might indicate, but almost everything has changed underneath to make this a better workflow.

  • Rewritten in Go, so no dependency on PHP or Python anymore. This is important, as Apple is removing PHP from macOS 12 Monterey, and will also remove Python from macOS in the future.
  • It's faster! Running the backend of the workflow as a compiled binary (Go) instead of a script (PHP) makes it faster, and it is also compiled as a universal binary, so it's running natively on both Apple Silicon and Intel Macs, but there are also some other changes that helps to make it faster and you will probably notice the difference if you used the old version before.
  • Less risk for unexpected behavior that leads to bugs, both because it can't behave different depending on which PHP or Python version you have anymore, but also because it now for example uses more reliable ways to keep track of information while navigating through the different parts of the workflow.
  • Adding bookmarks from Firefox is now more reliable, and if things still occasionally go wrong, the workflow is better at communication that in a useful way. (I switched from Safari to Firefox myself, so it got some more attention than before)
  • Ability to add a bookmark by copying the address, rather than getting it from the currently active browser window. To use this feature for adding a bookmark from an unsupported browser (or somewhere else), just copy the address and go to the bookmark adding feature of this workflow. It will just work, without you having to do anything more than that!

Get it from GitHub!

Link to comment
4 hours ago, xurc said:

I downloaded ver 2.0 from GitHub but cannot authenticate with my Raindrop.io account. Why is this and how do I solve it? Thank you in advance.

 

Hi @xurc

 

I just added the ability to show more information if the authentication fails, so try downloading version 2.0.1 and see if it might help to at least point out where the issue is.

 

Download at GitHub

Link to comment

Hello @andreas.w,

 

Thanks for the swift reply! Here's the detailed error:

 

Quote

Authentication with Raindrop.io failed.


Failed to make request to Raindrop.io 

Post "https://raindrop.io/oauth/access_token": proxyconnect tcp: EOF

 

Potentially useful info:

  • I have a network proxy listening on 127.0.0.1:1080. Due to my network configuration, I assume the workflow need to connect to the internet via the system proxy in order to work?
  • Disabling the system proxy is not an option for me, unfortunately, because my internet is heavily censored by the government and I cannot access https://raindrop.io without the proxy.
  • I had a hunch this was the reason the workflow works properly for everyone in this thread except me. Due to the nature of this issue, only a minuscule proportion of your users will be affected, so please feel free to choose not to spend time fixing this issue if it's too much work.
Edited by xurc
Link to comment

Hi @xurc

 

During the development of this I sent all requests to Raindrop.io through a proxy to be able to easier see whats going on with the requests and fix issues that way, so I know that it can work with a proxy (at least the one I used, but that's for development, not really to be used as an actual proxy)

 

The trick I did to get that proxy to work was to use the fact that Go applications by default looks for the environment variable https_proxy (and http_proxy, but that's not relevant here as all traffic is https).

You can manually specify this environment variable before calling the raindrop_alfred application, and it will then send traffic through that proxy.

 

For example, if you look at the workflow in Alfred, and double click the green object up in the left corner that specify "r" at the top (for which key you use to access it), you can change this line:

./raindrop_alfred search --query="{query}"

to this:

https_proxy=127.0.0.1:1080 ./raindrop_alfred search --query="{query}"

 

That will change that part of the workflow to send traffic through the proxy, but for it to work everywhere, you will have to do the same in all other places where ./raindrop_alfred is called around the workflow (most of the object's that either say Script Filter or Run Script at the buttom).

 

The other green object with "ra" at the top has a bunch of AppleScript in it, and it calls ./raindrop_alfred in several places.

For this possible fix to work there, I would suggest to copy all the AppleScript in there, put it in a text editor, use the find and replace-feature to replace all instances of "./raindrop_alfred" with "https_proxy=127.0.0.1:1080 ./raindrop_alfred", and then copy it all and paste in Alfred again.

 

I'm sure that there is probably a way to set the https_proxy environment variable globally for your whole system in a way that Alfred and in turn this workflow manages to pick it up too, and than it should just work, but I haven't tried to do that, and I know that scripts that are run in a workflow do not pick up environment variables that I have set in my zsh or bash configuration for example, so it is possible that this is quite hard to do.

 

Maybe someone else here knows how to do that?

 

In the mean time the solution above might do the trick.

 

I might possibly implement support for this eventually too, but no promises on that.

 

Link to comment

Hello @andreas.w,

 

2 hours ago, andreas.w said:

for it to work everywhere, you will have to do the same in all other places where ./raindrop_alfred is called around the workflow (most of the object's that either say Script Filter or Run Script at the buttom)

 

I followed your instruction above and manually replaced each instance, and now the workflow is perfectly functional. Thank you for going out of your way to provide such a detailed fix, I appreciate your patience and help. 

Link to comment

@xurc I looked a little more at this, thinking that it would really be quite strange if there isn't a better method for Alfred workflows to send their traffic through a proxy, and it turned out that there is a much simpler way to do it!

 

You can just go to the Alfred preferences, and to Advanced, and enable "Use macOS http proxy settings for scripts". :)

 

This just isn't enable by default, and I had totally missed it's existence because of it.

Link to comment

I made another small update.

 

Version 2.0.2 adds the ability to directly open Raindrop.io's permanent copy of a bookmark by holding shift and pressing enter while a bookmark is selected in the list. This feature requires a Raindrop.io Pro subscription to work

 

Now I will probably be more quiet for a while, if there are not a bunch of bugs showing up or something like that :)

Link to comment

Hello @andreas.w,

 

9 hours ago, andreas.w said:

enable "Use macOS http proxy settings for scripts"

 

I checked this setting but it was already enabled. I must've enabled it long ago and forgotten about it. I poked around to see why enabling this setting hasn't been working for me up til now, and discovered that I need to uncheck the "Prefix schemes if missing" box, which has been checked. Now the workflow can connect via the proxy by default.

 

Thank you so much for walking me through this!

Link to comment
  • 2 weeks later...
On 9/12/2021 at 11:56 AM, andreas.w said:

@xurc I looked a little more at this, thinking that it would really be quite strange if there isn't a better method for Alfred workflows to send their traffic through a proxy, and it turned out that there is a much simpler way to do it!

 

You can just go to the Alfred preferences, and to Advanced, and enable "Use macOS http proxy settings for scripts". :)

 

This just isn't enable by default, and I had totally missed it's existence because of it.

 

I update this preference and updated to v2.0.4 and its now working for me, thanks. 

Edit: (on macOS 11.6)

Edited by mdubsss
Link to comment
  • 1 month later...

Thanks for this workflow!  I noticed it takes ~10-15 seconds for every step of searching. For example, if I search "school" it'll take 10 seconds to show results, then if I type "resource" to further define the search, it again takes another 10 seconds to show new results.

Is this normal or is there something I can tweak in the settings?

Link to comment
4 hours ago, jaygogrr said:

Thanks for this workflow!  I noticed it takes ~10-15 seconds for every step of searching. For example, if I search "school" it'll take 10 seconds to show results, then if I type "resource" to further define the search, it again takes another 10 seconds to show new results.

Is this normal or is there something I can tweak in the settings?

 

Hi @jaygogrr

 

The workflow sends every search query to Raindrop and waits for the results, and is not doing the search locally.

This makes it possible to for example have full text search, so the results get much better because of this.

 

That means that when you type a search query, there is first a very small wait (this is even slightly shorter if you are using version 2.0 or newer) before it is sent to the server, and then you have to wait for the response before you get to see any results.

This happens again if you change the search. It's not filtering what you already searched for locally when you add a second word, but instead it sends a search request just like the first one.

 

Because of this it will practically always be the server you are waiting for if it takes a long time to get your results.

For me it normally varies between maybe 1-2 seconds to maybe 4-5 seconds for my search queries, so I do think that 10 seconds seems like a lot compared to how it works for me.

 

Anyway, if it's slow in the way that you describe, it probably either means that the Raindrop servers are slow at the moment, for some reason, or that your internet connection is slow at the moment, at least for connections to the Raindrop servers which would not necessarily mean that everything else is also slow on your connection.

 

Link to comment
  • 4 weeks later...

Hi @andreas.w

 

Hoping you can help me. I've installed the current workflow and get the following error when I type "r" in Alfred:

 

[09:18:09.037] Search Raindrop.io[Script Filter] Queuing argument '(null)'
[09:18:09.995] Search Raindrop.io[Script Filter] Script with argv '(null)' finished
[09:18:09.997] ERROR: Search Raindrop.io[Script Filter] Code 1: 🍺
09:18:09 workflow.go:328: ----- Search Raindrop.io/2.0.4 (AwGo/0.27.1) -----
09:18:09 workflow.go:343: ------------------ FATAL ERROR -------------------
09:18:09 workflow.go:344: interface conversion: interface {} is nil, not []interface {} : goroutine 1 [running]:
runtime/debug.Stack()
	/opt/homebrew/Cellar/go/1.17/libexec/src/runtime/debug/stack.go:24 +0x65
github.com/deanishe/awgo.(*Workflow).Run.func2()
	/Users/andreas/go/pkg/mod/github.com/deanishe/awgo@v0.29.0/workflow.go:344 +0xd9
panic({0x12bea60, 0xc000199320})
	/opt/homebrew/Cellar/go/1.17/libexec/src/runtime/panic.go:1038 +0x215
main.get_collections({{0x0, 0x0}, {0x0, 0x0}, {0x0, 0x0}, {0xc0000de108, 0x13}, 0x0, 0x0, ...}, ...)
	/Users/andreas/Library/Application Support/Alfred/Alfred.alfredpreferences/workflows/user.workflow.1B8F238D-BB91-410E-8CE1-61AD0823A468/raindrop_common.go:283 +0x74a
main.search({0x130a77b, 0x13071bc}, {0x7ff7bfeff88b, 0x0}, {0x0, 0x1d}, {0x0, 0x13d4885}, 0x46, 0x1)
	/Users/andreas/Library/Application Support/Alfred/Alfred.alfredpreferences/workflows/user.workflow.1B8F238D-BB91-410E-8CE1-61AD0823A468/raindrop_search.go:149 +0xf06
main.run()
	/Users/andreas/Library/Application Support/Alfred/Alfred.alfredpreferences/workflows/user.workflow.1B8F238D-BB91-410E-8CE1-61AD0823A468/raindrop_main.go:52 +0x765
github.com/deanishe/awgo.(*Workflow).Run(0xc0000d66c0, 0x13271c0)
	/Users/andreas/go/pkg/mod/github.com/deanishe/awgo@v0.29.0/workflow.go:358 +0x303
main.main()
	/Users/andreas/Library/Application Support/Alfred/Alfred.alfredpreferences/workflows/user.workflow.1B8F238D-BB91-410E-8CE1-61AD0823A468/raindrop_main.go:86 +0x1da
09:18:09 workflow.go:345: ---------------- END STACK TRACE -----------------
09:18:09 feedback.go:509: Sent 1 result(s) to Alfred
09:18:09 workflow.go:376: [ERROR] interface conversion: interface {} is nil, not []interface {}
09:18:09 workflow.go:402: ------------------ 915.216434ms ------------------
[09:18:10.000] Search Raindrop.io[Script Filter] {
  "variables": {
    "AW_SESSION_ID": "4WXZB40GJ1KXQQ86IA8H1EXG"
  },
  "items": [
    {
      "title": "interface conversion: interface {} is nil, not []interface {}",
      "valid": false,
      "icon": {
        "path": "/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/AlertStopIcon.icns"
      }
    }
  ]
}

 

Link to comment

Hi again @SteveM

 

I did fix a bug a couple of weeks ago that was quite similar to the one you reported yesterday, but I was unsure if I had really fixed it, so I had been trying it out a bit myself before releasing it.

Your bug looked so similar to this that I was sure it was the same, and released that update I had been testing (which really does fix that other bug that reminds of this)

 

I looked into this a bit more now though, and have released another update again that I am sure actually does fix your problem.

 

Get the updated version here

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...