Jump to content

andreas.w

Member
  • Posts

    52
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by andreas.w

  1. It's hard to tell what might be the reason for this without more context, but you could go to the the Raindrop workflow and check if it says "ra" where I marked that with red in the screenshow below. That is where the code word that by default is set to "ra" is configured, and you could change it to anything by double clicking that box and change the setting for it there. One thing you could do, and which is what I do myself, is to set up keyboard shortcuts for searching a bookmark or adding a bookmark, which you can also see in the screenshow below on the left side. Double click those boxes to set your own shortcuts if that seems like a good solution for you.
  2. No, there isn't (at least not that I'm aware of). What is possible though, and how I have been using this workflow myself, is to bind it to any keyboard shortcut you want, so that you get directly to the Raindrop searching (or adding a bookmark) without having to go through standard Alfred first. I have for example been using it like this: Trigger Alfred: cmd+space Trigger Alfred Raindrop Search: option+space Trigger Alfred Raindrop Add Bookmark: cmd+option+space But you can of course configure it to what you prefer. If you go to this workflow in the Alfred settings, the object that you will need to double click to set the shortcuts are the two green ones with a white field in them, up in the top left corner. (There is a description of this below these objects too). You can also change the "r" and "ra" keywords to anything you like (so that you can use something that you remember more easily) at about the same place in the configuration (you will see the green objects with "r" and "ra" as titles.
  3. Try to open Keychain Access and search for raindrop there, and remove the item that matches this workflow, and then open the workflow again and try to search or add a bookmark. If you do that, you should get to re-authenticate, and hopefully thay will fix the problem.
  4. @heyJoeCampbell Are you getting any error message, or some other hint of what might be going on?
  5. Hi @heyJoeCampbell, @kibbles and @jstncwlcx I think that the workflow should have your issues fixed in the latest version, so check if it works better if you upgrade. https://github.com/westerlind/alfred-raindrop-search/releases
  6. Hi @dyab I answered this on GitHub here: https://github.com/westerlind/alfred-raindrop-search/issues/19 The quick summery is that I think it is possible that it might be possible to solve this issue by forcing a log out and then log in to Raindrop again the next time you use the workflow, which you can do by removing the raindrop-search object from Keychain Access.
  7. The issues with opening links in Alfred 5 is now fixed in version 2.0.7, which you can get here. This version also adds support for the browsers Arc and Sidekick, and fixes some encoding issues when saving bookmarks. Thanks @vitor for the help with fixing the Alfred 5 issue!
  8. Hi @egregious I don't think you left anything blank yourself, but the workflow is trying to read something that is not what it expects it to be. It is hard to tell exactly where this came from by just knowing this error message though, so what you could do to help with some of the context of it is if you could open Alfreds settings, go to the Raindrop workflow, and and click the debug button in the top right corner (the one that looks like some bug). When you have done that, you can just leave it like that and try to use the workflow again, and you will then get more information in the debugging field that you opened, which you could copy and put here or send in a personal message to me. It would also be helpful to know if you got through the login process and accepted that the workflow should get access to your Raindrop account, and it would also be good to know if you where trying to search or add a bookmark when this happened, and if you got to see anything else happen before you got this error message.
  9. Hi @Craigers I'm happy to hear that you like the workflow! There is no way to use Raindrops own search locally, but I have been working on an alternative way to make something like what you ask for possible. The development of that has stalled a bit lately but it should be released eventually (I have a functioning proof of concept for how it would technically work). The idea of what I'm working on is to download and store the title's, tags and URL's (and maybe the description) of all bookmarks locally, and then use Alfreds own search engine to search that list. This will be an alternative way of searching, and you will be able to decide if you want to use the current search mechanism or this alternative one, and if you use the alternative method things will be faster but you will not get full text search like you do now (it will basically only search the titles and tag names and maybe the description, unlike the current search mechanism that is able to search the full content of all bookmarks), so then you can decide what works best for you. I think this will be done within a few months, but I can't say for sure.
  10. Hi @Ravisankar You might already know most of the following, but I'm writing it anyway if someone else might have use for it in the future. From the way you describe this, and the error message, it sounds almost certainly like this problem is a consequence of your corporate firewall sitting in the middle between you and the server and acting as a TLS endpoint (meaning that it decrypts your request to check/filter it), and then makes a new request to the actual server. This can be a good security approach in a corporate environment, but it it requires that the clients have the Firewalls root certificate installed to be technically possible without getting error messages like this for almost everything. Sometimes these firewalls are set to not check known sites, which means that they don't see the content of those, and that you don't need it's root certificate installed to be able to reach those sites, so for that reason you might not see these errors for everything, even though everything goes through the firewall and even if you don't have the certificate installed. It is good to know that if someone who should not be able to is trying to see your web requests, it would also look similar to this, so you should be careful with installing a certificate to solve it when you see an error like this if you are not 100% sure that it is the expected certificate. So, it sounds like you have the correct pem file with the root certificate, so that is good, and than the only thing that remains is really to install it. Chrome uses macOS's system wide certificate store, just like Safari and most other apps (Firefox uses it's own, so certificates that are installed in macOS's store does not apply to it) To install and enable a root certificate in macOS central certificate store you just need to double click it, and then open Keychain Access, search for and find the newly installed certificate and double click it, expand "Trust", change "When using this certificate" to "Always Trust", close the dialog and confirm with your credentials (or TouchID or whatever it asks for). After that it should work in most apps, which means almost anything that is not Firefox or Java based (there are more exceptions, but not on top of my mind right now)
  11. Hi @arpan Sorry that it's not very obvious how to log out. You can do it by opening the Keychain Access app, searching for raindrop, finding the value that comes from this workflow (likely the only result you get when searching for raindrop there), and delete that value. The next time you trigger the workflow it will let you log in again.
  12. @clienttel It is possible that it might start working again if you reauthenticate against Raindrop, which you can do by opening Keychain Access, search for raindrop, and delete the login object there. When you try to use the workflow the next time, it will then let you authenticate again, and with a little luck that might solve your problem.
  13. @clienttel One possibility is that Alfred might not have automation permissions for reading content from Chrome. That would lead to something like this. Go to System Preferences -> Security & Privacy -> Privacy -> Automation, and make sure that Google Chrome is checked under Alfred 4 in the list. Alfred asks for this permission the first time you try to add a bookmark, or something else that requires Alfred to access a specific browser, but if you don't click to allow it at that time, you will have to go to System Preferences like I described above to make it work. Also, if this is not how you did it previously, I think you would get the copied link variant to work by first copying the URL, then selecting something that is not the browser (click on the desktop for example), and then call the workflow for adding a bookmark. If that works like it is supposed to do, it would then read your copied link without you having to paste it, as you don't have a browser windows selected.
  14. Hi @clienttel When trying to add the bookmark, do you either have a browser with the site you want to add open as the front most window, or have copied the link you want to add before you call the workflow? The workflow will add the URL that is open if a browser is the front most window, or otherwise if you have copied a URL, it will add that. If you have none of those it does normally tell you about how to add a bookmark, but it happens that it simply does nothing, like you describe. (I should probably fix that, but it does not brake any functionality, it only makes it a bit less clear how to use the workflow in some cases) Which browser are you trying to add a bookmark from? Could you also, in the view that you sent a screenshot of, click "Script Filter" on the last line and check which box in the workflow that gets selected?
  15. Hi @SteveM I have looked a bit more into this, and I think that the root cause of the issue is some sort of problem to properly connect to the Raindrop servers, or at least it seems like you might get an unexpected response for some reason, so I have made some changes to make the actual response from the server (or at least the "body" of it, for now) show in the Alfred log if there is a problem like the one you are having now. So here is a new pre-release version that you can try, and if you still have the problem with this version you can look in the Alfred log and you should be able to see the server response there, and hopefully that will give a hint about what's wrong. Download here
  16. I think I got that one too now, but test this version here before I release an update, so I know it actually works now.
  17. 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
  18. Hi @SteveM Thanks for reporting! I just released version 2.0.5 which will probably fix this. Get it here: https://github.com/westerlind/alfred-raindrop-search/releases
  19. 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.
  20. I just released version 2.0.4 with a bug fix for an issue that would occur if you had at least one collection in Raindrop.io that did not have an icon manually set for it, so if you happened to turn into this problem you should now be able to have everything working by downloading the updated version here: https://github.com/westerlind/alfred-raindrop-search/releases
  21. 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
  22. @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.
  23. 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.
  24. 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
×
×
  • Create New...