Jump to content

paulw

Member
  • Posts

    158
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by paulw

  1. 11 hours ago, vitor said:

    There’s a set of Automation Tasks to Script WebKit browsers. Try with that using the Custom browser option and seeing if it works.

     

    Thanks. That does work, using "Orion RC" as the custom browser. Hopefully I can find a way to get the "Current Front Browser" working again with Orion RC, since it has the advantage of also working with other browsers I might have open.

  2. Thanks @vitor. I won't ask you to spend time troubleshooting a browser that you don't have access to, but just FYI, I used this script to confirm that kCGWindowLayer is 0 and kCGWindowOwnerName starts with Orion (Orion RC).

     

    On 1/31/2024 at 6:32 AM, vitor said:

    Also try using the Webkit Browser Automation tasks and giving it specific names.

     

    I'm not sure what you mean by this. Could you explain?

  3. Thanks. It's the same issue as before: "Current Front Browser Tab" fails with

     

    Task Error: arm/get-frontmost-browser.swift:32: Fatal error: Did not find a supported web browser
    ../../../../com.alfredapp.automation.core/safari/.common/tabs-current: execution error: Error: Did not find a supported web browser (-2700)

     

    I'm on Alfred 5.1.4 and MacOS 14.3.

     

    Other Automation Tasks involving front browser run into the same error

     

    Edit: and I'm using v 2024.1 of Automation Tasks

  4. If there's a way I can help you figure it out, I'd be happy to.

     

    I don't know if the cause could be this simple but using Filemerge, I notice that in Contents/Info.plist for each app, Orion's includes

     

    <key>CFBundleExecutable</key>
    <string>Orion</string>
    <key>CFBundleIconFile</key>
    <string>AppIcon</string>
    <key>CFBundleIconName</key>
    <string>AppIcon</string>
    <key>CFBundleIdentifier</key>
    <string>com.kagi.kagimacOS</string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>Orion</string>

     

    while Orion RC's has

     

    <key>CFBundleExecutable</key>
    <string>Orion RC</string>
    <key>CFBundleIconFile</key>
    <string>AppIcon-RC</string>
    <key>CFBundleIconName</key>
    <string>AppIcon-RC</string>
    <key>CFBundleIdentifier</key>
    <string>com.kagi.kagimacOS.RC</string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>Orion RC</string>

     

     

    Also in Contents/embedded.provisionprofile some of the differences are:

     

    Orion:

    <key>AppIDName</key>
    <string>Kagi</string>
    
    ...
    
    <key>DER-Encoded-Profile</key>
    <string><<a long string>></string>
    
    ...
    
    <key>com.apple.application-identifier</key>
    <string>TFVG979488.com.kagi.kagimacOS</string>
    
    ...
    
    <key>Name</key>
    <string>Kagi macOS</string>

     

    and Orion RC:

     

    <key>AppIDName</key>
    <string>Orion RC</string>
    
    ...
    
    <key>DER-Encoded-Profile</key>
    <string><<  a different long string >></string>
    
    ...
    
    <key>com.apple.application-identifier</key>
    <string>TFVG979488.com.kagi.kagimacOS.RC</string>
    
    ...
    
    <key>Name</key>
    <string>Orion macOS RC</string>

     

  5. 4 hours ago, vitor said:

    Just to let you know this has been added a couple of weeks ago.

    Thanks! Works great without the need for the osascripts now. The only issue that I'm having is that I'm using Orion browser (actually, the Orion RC version) and I get the error 

    Task Error: arm/get-frontmost-browser.swift:32: Fatal error: Did not find a supported web browser

    I realize there are a ton of browsers out there, and some come and go, and it might be a chore to keep Alfred managing a list of them.

     

    Perhaps:

    1. Orion and Orion RC be added to the list of supported browsers, or

    2. Possibly there's a more global way for Alfred to recognize browsers (Orion for example is basically Webkit plus added stuff)? or

    3. Users could specify an app as a browser in Alfred preferences (similar to how Choosy.app allows you to specify an app that it may not have detected as a browser)?

  6. Thanks @Stephen_C. What you described is an example of the issue, but unfortunately not a solution for what I was looking for/expecting, which is that the automation would work even when an app that isn't a browser is active. I'm was trying adapt @dfay's very useful Browser snippets workflow to work with any browser, using Alfred's built-in automations rather than adding a bunch of extra scripting to account for other browsers.

     

    I would have expected "Current Frontmost Browser Tab" to basically:

    - determine what browsers are running

    - determine which window among those browsers is in front of the others

    - return the URL and/or Title of the current tab from that browser window 

     

    This would allow the action to return the active tab of whatever browser I was most recently working with, even if I'm using a different app. Ause case would be to grab the url and title from the tab and paste it into a text document, for example, with one quick keyboard shortcut or snippet.

     

    Instead, "frontmost browser" really seems to mean "frontmost app, which also must be a browser".

  7. I'd like to get the title and url of the active tab in the frontmost browser, using the automation task "Get Current Frontmost Browser Tab".

     

    I expected the automation to detect which browser is frontmost, no matter what app is active, but it doesn't seem to work that way.

     

    For example, if I make a simple workflow with a keyword to trigger "Get Current Frontmost Browser Tab", and trigger it from the Alfred UI, the debugger shows

     

    [Automation Task] Task Error: ../../../../com.alfredapp.automation.core/safari/.common/tabs-current: execution error: Error: Error: Alfred Preferences is not a supported browser: Safari, Webkit, Orion, Google Chrome, Chromium, Opera, Vivaldi, Brave Browser, Microsoft Edge, Arc (-2700)

     

    Is that expected? It seems like it would be more useful for the automation task, and others like it, to find open browsers in the background, find the frontmost one, and get its active tab.

  8. I've been using Orion Browser recently, which is Webkit based, and running into an issue with Alfred snippet expansion.

     

    I have a snippet for my email address for example, like @@em which expands into my full email address—let's say "my@email.com". In other browsers, including Safari, this works with no problem. In Orion, though, it expands to "@@my@email."

     

    If I use macOS's built-in text expansion, there's no such issue.

     

    I've tried disabling all extensions in Orion, but no luck.

     

    Any ideas?

  9. 22 hours ago, vitor said:

    Alfred doesn’t (and shouldn’t) edit the script’s contents, so if php is literally written on it the issue still manifests. But you (or the author) can edit the script. Add to it, at the top, the line export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" and it should work.

    Oh, ok, I would have thought that Alfred would be able to make use of the user's PATH, instead of having to explicitly define it in the scripts. Is there a reason why it can't?

  10. 4 hours ago, nemrod said:

    Hello MGHollander
    It doesn't work in Monterey (like all other lipsum workflow)
    but with yours I don't get the usr/bin/php error… I get nothing… no feedback
    so for me, it's encouraging!

    https://loom.com/share/3a517bd7e3fa4005ae0372dea6a73461

    Can you do something? please :)

     

    Alex Chan's workflow, which this one was forked from, was just updated to use Python instead of PHP, and it works with Monterey now

  11. I have php installed via Homebrew, and I'm on Alfred 4.6 on Monterey, but workflows using php are breaking.

     

    Confirming that php works in the command line on my machine:

    % which php
    /usr/local/bin/php
    % php -r 'echo function_exists("foo") ? "yes" : "no";'
    no%

     

    According to this blog post, "If you install PHP (e.g. via homebrew), most PHP-based workflows will continue to work without an issue, as the workflow script objects in Alfred 4.6 have been updated to be aware of alternative bin paths."

     

    But in a bare-bones Alfred workflow with language set to bin/bash:

     

    php -r 'echo function_exists("foo") ? "yes" : "no";'

     

    gets me "line 1: php: command not found" in the debugger.

     

    Am I misunderstanding something?

  12. Thanks! By the way, I did a file comparison between the old and new versions, and you changed export_shortcuts to export_shorcuts. Doesn't seem to be a problem, since it's consistent, but just thought I'd let you know 🤓 Never mind, had that completely backwards. Thanks for your very useful script!

×
×
  • Create New...