Feature: open meetings in Google Meet PWA if available

[neb]

Issue that this suggestion fixes

I know this is a duplicate of #747, #601, #481, #409, and #313. But bear with me. :)

For the sake of this text box: The "issue" is simply that there's currently no way to configure MeetingBar to open Google Meet links directly in the Google Meet PWA — without routing through another URL-routing app such as Finicky or BetterTouchTool.

Solution description

Here's the part that's different from the previous tickets: A proposed solution!

Once the Google Meet PWA has been installed as a Chrome App, it's possible to launch it directly into a meeting's join screen by executing Google Chrome with --app-id and --app-launch-url-for-shortcuts-menu-item arguments. On macOS it looks like:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --app-id=kjgfgldnnfoeklkmfkjfagphfepbbdan --app-launch-url-for-shortcuts-menu-item=https://meet.google.com/xxx-xxxx-xxx

(To give credit where it's due, I got this from @skoshy's comment here: https://github.com/johnste/finicky/issues/153#issuecomment-770316349.) I've been using this for years, by having MeetingBar open links in Finicky or BTT. and then using either of those to launch the Meet app. And this mechanism also works for most/all video conferencing PWAs installed as Chrome Apps. For example I've done the same with Doxy and GrowTherapy. But rather than all that hand-tuned complexity, it'd be nice if MeetingBar could do it directly with a little tweaking!

Would you be open to MeetingBar either intelligently opening Chrome App links, or bring back the arbitrary Arguments field so that users could hand-build this in MeetingBar rather than BTT/Finicky?

If you're open to it, I'd be happy to put up a draft PR once I know which direction you'd like it to go. I've... accidentally written a long proposal... which I'll put as a followup comment to keep this already-long issue description from getting longer.

Alternatives considered

I first went down the rabbit hole of constructing a custom web browser entry which specifies command line arguments. Looking at defaults read leits.MeetingBar browsers and defaults read leits.MeetingBar meetBrowser I see a tantalizing arguments string... but I don't see a way to populate it via the UI, and populating it by hand with defaults write didn't seem to do anything. Looking at the source code it seems like a leftover from a very early version of the browser mechanism. Of course the key would be to somehow get the meeting URL merged directly into the 2nd argument, which would mean some sort of templating/substitution.

Additional context

No response

[neb]

Background: I see where the browser launching is done in URL.swift and where browsers are configured in BrowserConfigView.swift. I also noticed in the commit history that there briefly was a UI field to edit arguments, and code that used it — but it was later removed, and the logic simply split on commas and used the results as arguments, without any sort of substitution.

I'm not a Swift person so I won't mess with UI other than e.g. adding/restoring the Arguments field, but I can handle the rest. Feel free to describe the approach you'd prefer, but here are two possible plans of attack:

Quickest and narrowest: Extend URL.swift to notice when a provided .app file is actually a Chrome App and launch it via the above command line, probably with Process() as was recently added for non-*.app paths.

• I think a reliable way to detect a Chrome App it would be to look at the ....app directory's Contents/Info.plist for a CrAppModeShortcutID key. That's the value that would go in the --app-id argument so we need it anyway.
• Two sticking points:
  • I don't know the best way to identify which installed Chrome browser should be used. Maybe search the configured browsers array, or just go with /Applications/Google Chrome.app for now? Or is it legit to grab LastRunAppBundlePath out of ~/Library/Preferences/com.google.Chrome.plist? :)
  • I don't know how to decide which Chrome Profile to use. If an App is only installed under one Profile it'll use the correct one, but if it's installed under multiple, I think it'll just use whichever Profile was most recently focused. It can be controlled via CLI (--profile-directory) but then does this need a UI to pick it?...

More abstract and flexible, but more complicated UX: Bring back an improved (to support substitution) version of the browser.arguments feature, and some amount of UI to help utilize it.

1. Extend the new non-.app codepath in URL.swift to support browser.arguments if populated, perhaps splitting on commas like it originally did, and substituting the URL into it if needed.

• Would you have a preference/suggestion for how substitution should work within that string? It could just blindly replace {{URL}} or $URL or %u or something, probably relying on the arguments string already containing quotes as needed, or if you'd like something smarter just let me know the outline. (And I suppose if it doesn't find the magic token, it would just default to putting the URL as a separate, final argument.)

2. One or more of these:

• Bring back the Arguments field in BrowserConfigView.swift and let people do whatever they want (including controlling Profile). (But! Splitting on commas won't make a very intuitive or friendly UX, so maybe that's why this was removed? Would this need a whole new UI?)
• Extend BrowserConfigView.swift to notice that a Chrome App has been selected (as mentioned in the other approach) and if so replace its path with Chrome's and construct an appropriate comma-separated arguments string.
  • (Again does not provide a solution for controlling which Profile will be used, when the App is installed under multiple. Same for the next option.)
• Extend the "All system web browsers" to notice the installed Google Meet "Chrome App" and construct this special entry if so. (Or some other button dedicated to this Google Meet magic. Or this could show a picker UI listing all installed Chrome Apps, but I'm not actually a Swift person so I'll leave that kind of UI to someone else. :))

I am not an AI, nor did I use an AI to write any of this, though in hindsight it reads a bit like I did... and maybe I should have. And... you or I might be able to just hand the above description to an AI and let it create the PR... But I'd still do it by hand for the fun of playing with Swift again. Unless there are unit tests that I should add. I don't know anything about Swift testing so I'd definitely get AI help me with that. 😆

[lemerv]

Nothing to add other than I'm keen for this functionality!