Jump to content

godbout

Member
 View Profile  See their activity

  • Posts

    332

  • Joined

  • Last visited

  • Days Won

    12

 Content Type 

Everything posted by godbout

  1. godbout
    toggle your Brook VPNs through Alfred: https://github.com/godbout/AlfredBrook enjoy.
  2. godbout
    actually 2.5.1: https://github.com/godbout/WooshyWindowToTheForeground/releases/tag/2.5.1 small fix in Alfred Result for when no window is found.
  3. godbout
    2.5.0 out, no more Notification Center and improved windows filter out system: https://github.com/godbout/WooshyWindowToTheForeground/releases/tag/2.5.0
  4. godbout
    2.4.0 out with better support for MB with Notch: https://github.com/godbout/WooshyWindowToTheForeground/releases/tag/2.4.0
  5. godbout
    5.0.0 out: https://github.com/godbout/alfred-time/releases/tag/5.0.0
  6. godbout
    my pleasure. lemme know if you have any questions... Ben Shapiro? 😅️
  7. godbout
    2.3.0 out: https://github.com/godbout/WooshyWindowToTheForeground/releases/tag/2.3.0 brings support for a new type of window. update will show up automatically in Alfred's Results within 6 hours.
  8. godbout
    the speed comes with disadvantages: 1) doesn't grab hidden windows 2) doesn't grab minimized windows. some Workflows actually handle those, but yeah, slower. for me i needed something fast to bring windows to the foreground so that i can target them with my apps (kindaVim, Wooshy and Scrolla). hope it helps!
  9. godbout
    3.1.0 adds support for multiple devices: https://github.com/godbout/alfred-airpodspro-battery/releases/tag/3.1.0
  10. godbout
    after investigating on my side i'm finding that this seems to be a bug in AppKit. assuming that Alfred is checking the active screen with `NSScreen.main`, the screen returned is wrong if an app is a LSUIElement type. i've reported this to Apple (FB11506568). one way to go around this could be to get the Focused Window of the System AX Element. then grab the Frame of the Focused Window, and check it against the available Screens Frames to see within which Screen the Focused Window is. that is, if you want to get this fixed. may not be worth the trouble?
  11. godbout
    as the title says. it's pretty straightforward. if the `Displays have separate Spaces` is OFF in macOS, then the `active screen` ends up always being the default one instead. Alfred 5.0.2 [2073] macOS 13 public beta 6 macOS 12.5
  12. godbout
    i like the Web Search History, but usually they clutter my Workflows. i would like to keep calling my Workflows with a single letter, like `w` to get a list of visible windows, `m` to get menus of frontmost app, etc. but i end up having some URLs in there too. would there be a way to prefix the Web Search History with something in order to show them? like how it works for the Bookmarks. thanks.
  13. godbout
    2.2.0 out: https://github.com/godbout/WooshyWindowToTheForeground/releases/tag/2.2.0 * add support for Font window * update frequency check changed to 6 hours for now instead of 24
  14. godbout
    @joetannenbaum in my case i was starting building an app for the Mac so it was a right time to dig into Swift. and also i've had several issues with my PHP workflows, between the PHP versions people would install through Homebrew and/or the M1/Intel installation paths. i still have those issues reported from time to time and it's painful to dig into this again. my brain is not done to handle several different things at one. so be ready to get some transfers
  15. godbout
    hey @joetannenbaum yeah following you on GitHub and saw the release today. congrats! and i'm glad. after Apple decided to stop packing interpreters in macOS, i've switched and then rebuilt my Alfred ecosystem in Swift. i was still maintaining the PHP one but only when i had time, and without too much heart tbh. so i'm gonna archive mine now and redirect it to yours welcome back.
  16. godbout
    ok. if you wanna check the automatic update, do this: 1. update the Workflow version to 2.0.0, rather than 2.1.0 2. update the frequency check from 1440 to 0, so that an update will be checked in the background every time you bring a window in the foreground. that will not slow down the Workflow but it will use some extra resource 3. use the Workflow and bring one window to the foreground at least. at that time the update info will be downloaded 4. after a few seconds, the update will appear in the Alfred Results when you use the Workflow. see pic attached
  17. godbout
    ? sorry i don't understand what you're trying to do. the Workflow comes with the Updater included. you don't have to do anything. as a user you install the Workflow, give permissions, and start using and enjoying it. updates will be checked automatically every 24 hours. end of story. it just works. if you want to do open-surgery on the Workflow sure, have fun. but as a user, to get the Workflow's features and the automatic updates, you don't have to do anything. definitely not installing something extra.
  18. godbout
    Marco is that you trolling me again??? ok just in case this is not Marco (would be surprising but ok...). you're looking at the wrong thing. see my answer above: also look at the element highlighted in the screenshot. thanks. come on Marco... it's up to each Workflow to handle the way they update. Wooshy: Window to the Foreground! uses the AlfredWorkflowUpdater available here: https://github.com/godbout/AlfredWorkflowUpdater but as a user you shouldn't even bother caring about this. it just works, that's all you should care about. if for whatever reason the OneUpdater feature is very important to you, then Vitor Workflow may be a better fit: https://www.alfredforum.com/topic/17665-window-switcher-—-switch-to-a-specific-window-of-an-app-in-the-current-desktop-space/#comment-91324
  19. godbout
    check the README here: https://github.com/godbout/WooshyWindowToTheForeground#permissions there's the explanation, and a link to where in the source this is used. it's safe. it's just to grab the windows titles. if you don't want to give the permission to Alfred you can give it just to the Workflow command line tool instead. there is one. you can see within the Workflow itself, in Alfred. bottom elements. by default it checks for an update every 24 hours. you can change the setting to whatever you want if you need (time is in minutes, hence 1440). see screenshot attached. if you worry about permissions, you can use some alternatives: https://github.com/godbout/WooshyWindowToTheForeground#alternatives good luck!
  20. godbout
    2.1.0 out: https://github.com/godbout/WooshyWindowToTheForeground/releases/tag/2.1.0 feels like nightly builds sorry 😛 but ultimately `Screen Recording` is needed currently. if you haven't granted, you'll now get an Alfred Result mentioning this, and you can prompt from there. enjoy.
  21. godbout
    actually you're still gonna need the `Screen Recording` permissions to get the windows titles 🤔️ not sure this is easily avoidable without making the Workflow slow.
  22. godbout
    2.0.0 out! https://github.com/godbout/WooshyWindowToTheForeground/releases/tag/2.0.0 * switch from using the official `Screen Recording` way to get windows to some private AX API, so no more `Screen Recording` permissions needed * windows now can match with 100% accuracy
  23. godbout
    1.5.0 out: https://github.com/godbout/WooshyWindowToTheForeground/releases/tag/1.5.0 * add support for a few more windows, like the Apple ID 2FA shit * soften the way windows with wrong or missing data are discarded, which helps when using yabai * move Workflow Update Alfred Result as last item rather than first, to avoid selecting it when wanting to quickly switch window * add a way to prompt for Accessibility and Screen Recording permissions from within Alfred Results
  24. godbout
    my bad, i wasn't aware of that. i see an "Update items" result yeah, lost below my usual results. i guess i misread how the new integration worked. and kinda expected that it was as straightforward as before. this new system adds some non-welcomed friction, although i understand it's out of your control. thanks!
  25. godbout
    maybe i'm missing something, but is the Workflow supposed to catch up with the items from 1Password itself? i keep having to go through :1p Extras to force the items to be updated. whether it's a new item, removing an old one, adding a URL, etc. thanks. the diagnosis: ### Workflow version 2022.15 ### Alfred version 5.0.1 ### macOS version 13.0 ### Architecture i386 ### Preferences Default ### 1Password version 8.9.0-1.BETA ### op version In Workflow: 2.2.0 In /usr/local: 2.2.0 ### Biometric unlock Enabled ### Custom terminal feature Enabled ### Launchd job Loaded: - 0 com.alfredapp.1password Installed edit: i've checked the GitHub issues. saw some about not updating the items, but doesn't seem related to what i'm asking. maybe the current it works is actually expected. would be nice to have a confirmation.
×
×
  • Create New...