Jump to content

deanishe

Community Hero
  • Content Count

    5,251
  • Joined

  • Last visited

  • Days Won

    308

Everything posted by deanishe

  1. I did look to see if there's a forum member of the same name, so I could tell him not to do such a daft thing. But he's not a member… Just in case he googles himself, I'll use this opportunity to say DON'T KEEP YOUR PASSWORDS IN EVERNOTE, FRANKYSEA, YOU PLONKER!
  2. Oof. Keeping your passwords in Evernote doesn't sound like the smartest idea…
  3. Me, too. @phantasm Perhaps you should submit a feature request?
  4. It's an SQLite3 database, as are all .alfdb files. You can open the file with DB Browser for SQLite, amongst other apps.
  5. That's what iTerm does when the connection fails. Are you sure the machine is responsive and the connection details are correct?
  6. As Vero noted above, Alfred Remote gets new features via Alfred, not via updates to Alfred Remote. There hasn't been a new release in 3 years (hasn't been a need for one), so I'd say the chances of an entirely new version appearing any time soon are very, very low.
  7. You're talking about a massive re-write of the application to add a feature that would be broken for a significant number of users/workflows. Why would anyone even consider implementing that?
  8. Well, not just workflows. The way Alfred works is that it expects its preferences bundle to be changed by other applications. It could be Dropbox or Syncthing syncing your preferences, or npm symlinking a Node-based workflow, or a workflow saving/changing its own files. The filesystem is the source of truth, and Alfred monitors that. CloudKit also expects to be the source of truth, and that your app's data will only be manipulated via the app's own CloudKit-aware APIs. Getting Alfred and CloudKit to work together would require completely changing the way Alfred works or writing a custom filesystem–CloudKit sync engine.
  9. There are plenty of faster alternatives. But there's about zero chance of Alfred supporting anything but JSON because JSON is so ubiquitous. OTOH, there are plenty of JSON libraries for Go that are way faster than the built-in one (IIRC, Python's standard JSON library is—or at least was—faster than Go's). Presumably. It's an AppleScript error, after all. I haven't bothered trying to track it down because I hate AppleScript and I don't actually need the workflow. If you're running it via a Hotkey, it would be. You're wasting ~0.2s by saving a variable you don't actually want to save and then another ~0.2s deleting it again later: tell application "Alfred 3" set configuration "JNANA_FILE" to value (quoted form of theFile) in workflow system attribute "alfred_workflow_bundleid" end tell Calling Alfred's set configuration method is not the right way to set a workflow variable, and as I said in the other thread, tell application "..." is slow as hell. This is why I said you need to benchmark code before you start optimising it. If you'd properly benchmarked the workflow's code, you'd know that the workflow is wasting a few tenths of a second with tell application "Alfred 3" calls it shouldn't be making. I'd put money on those two unneeded tell application ... calls taking more time to run than you've saved by rewriting in Go EDIT: Here's the section on setting variables. You've followed the section on saving variables, which is not what you want. If you only need to set one variable via AppleScript, you can return the value and use an Args & Vars to set a variable. If you need more than one, I'd recommend trying to rewrite the script in JXA. It's just as crazy as AppleScript in its own way, but it at least has perfect support for JSON.
  10. Dunno. There just are loads of Latin sayings in English. I guess that one came from a contract or some other legal text?
  11. Yup. When Andrew added List Filters, he had them running buttery smooth filtering fifty thousand items. Alfred is extremely fast. I have no idea why your workflow might be slow. I get the same Expected end of line but found identifier. (-2741) error with both versions The code looks perfectly legit, even if I can't run it. FWIW, you don't need to manually mess around with aw.Cache and json here. There's already an initialised cache at wf.Cache and there's the Cache.StoreJSON method, so that whole function can be reduced to a single call: func cacheLastQuery(queryString string) { if err := wf.Cache.StoreJSON("LastQuery", queryString); err != nil { panic(err) } } Same goes for getLastQuery() mutatis mutandis.
  12. It doesn't. Alfred loads icons lazily after it's already displaying results. Doubtful. What's faster? In any case, Alfred is plenty fast enough unless you're sending many, many thousands of results.
  13. It's a default shortcut that works with pretty much every application.
  14. The section on Saving variables? It does. It automatically puts {query} in the Argument box. If you don't want an argument set, just delete {query} from the box. No. Saving variables takes time. Retrieving them shouldn't take any time unless you're doing something daft like reading info.plist yourself.
  15. Why don’t you upload your workflow somewhere so we can tell you exactly what’s wrong instead of guessing based on descriptions? Variables disappear as soon as the workflow ends unless you explicitly save them.
  16. That depends heavily on which language you're using. As far as Python goes, Asheesh Laroia's videos are awesome.
  17. That's just a bit of web automation. Where it becomes tricky is if the site actually requires Javascript to be executed. If not, you can usually get what you need with an HTTP library that supports cookies and an HTML parsing library. If JS support is required, then you'll have to use a headless browser instead (i.e. run a full copy of Chrome/Firefox and automate that). If you can get away without the full browser, JS apps are often easier to pull data out of because the data is typically in easily-parsed JSON, not HTML. Sometimes the data are actually stored in a nice, machine-readable form in data- attributes on HTML elements, too, which is also easy to extract.
  18. FWIW, Safari requires the same option to be set under "Develop > Allow Javascript from Apple Events".
  19. In addition to that (which means they don't sync like proper workflows), updating via npm is broken. Apart from the bug they've been sitting on for nearly a year now, by not using Alfred to install updates, all your customisations (hotkeys, keywords) get dropped on the floor. The way the community around alfy (and some other Node devs) generally go about workflow development is fundamentally broken, imo. By that, I mean it's impossible to create an Alfred workflow that Just Works the way they're intended to.
  20. Add this to the end of the relevant AppleScript: tell application "Finder" to activate
  21. It doesn't close immediately. do shell script doesn't return until the script completes, so the quit command isn't even sent until the shell script has finished. Also, nobody mentioned long-running commands. Plenty of shell commands finish extremely quickly.
  22. Packal is mostly dead, I’m afraid. It is unmaintained and the updater isn’t compatible with Alfred 3. Many workflows include their own automatic updaters, and will let you know when a new version is available.
  23. It's not a valid workflow. See the GitHub thread for details.
  24. That's why I said you need to benchmark that stuff. There's little point trying to optimise a program before you've identified where it's actually slow. SQLite is amazing. It's quite likely the most widely-used piece of software in the world. Doesn't matter. I don't really use Calibre's built-in eReader, anyway.
×
×
  • Create New...