CLI (command line integration) to manage virtual screens and other features

[waydabber]

BD should have all the required command line commands to manage all dummy related things.

[varenc]

++ to this! Would really appreciate this feature.

[wcbrown86]

I would also love this feature. Or an API that can be called from a program.

[dmkpoznan]

Upvoting this feature.

This could be combined with some event bus - like connecting via VNC (remotely) - this is one of two cases, where I use display pro (especially for remote access to my M1 mini from iPad).

[homerjam]

This would be incredibly useful right now!

[LoveDuckie]

I'm just replying to this issue to increase interest. We're currently having problems using Electron applications on headless macOS instances (e.g. AWS EC2 over SSH) and we're seeking a software solution for creating virtual display devices.

[waydabber]

Hi @LoveDuckie - I have a command line version app for that, see below. If you have any questions, contact me on the app discord channel (https://discord.gg/aKe5yCWXSp)!

[waydabber]

CLI support is still planned in BetterDisplay, the following command line tool createdummy is just an interim solution for those who need to manage virtual screens in a scripted environment until the functionality is integrated into BetterDisplay.

https://github.com/waydabber/createdummy

It is free for personal use or for evaluation purposes - if you want to use it commercially, you should get a BetterDisplay license (see license terms - 1 per user or per computer/instance, whichever makes more sense).

[bilal-khan]

@waydabber Thank you so much! Would you consider adding brightness controls to the command line tool? I use 3 external displays, setting them all individually is quite laborious.

[waydabber]

Yes, I plan to add CLI for most features of BetterDisplay including brightness control. The separate tool is only a stop-gap measure.

[waydabber]

A neat way to support CLI or as a means of general 3rd party integration capability is to use deeplinks.

Examples:

https://manual.raycast.com/deeplinks
https://culturedcode.com/things/support/articles/2803573/

Idea comes from roelvangils:

https://discord.com/channels/903276571773771796/903276571773771799/1139629808142274732

[waydabber]

Note to self: here is how to do it: https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app

This is for UIApplication but seems like NSApplication has the same.

[modest]

A neat way to support CLI or as a means of general 3rd party integration capability is to use deeplinks.

If you go this way, I would suggest adopting the x-callback-url pattern, a specific type of standardized deeplink that supports callbacks on success/failure and can optionally provide return data (e.g. current volume level after changing the volume). If nothing else, it's important for synchronous/procedural scripts (e.g. shell scripts) to know when an operation has completed so that it can proceed to the next one.

If you feel like supporting a CLI/API/automation is a daunting project and worry about designing your app into a corner through ossification, let me also suggest: Take a look at the commands for which you currently provide a keyboard shortcut. These are good candidates for a v0.1 of an API because:

• There's already an implicit commitment that commands with a keyboard shortcut will "probably" stay around, as removing them would break the muscle memory (and saved preferences) of keyboard shortcut users.
• By deciding to allow keyboard shortcuts for those commands, you've already identified those as actions which might need to be performed frequently - at least by some subset of users. That means that they're good candidates for automations and integrations, too.
• Nothing is lost by enabling CLI/API/automation access to those commands, as it was already possible (perhaps painfully) to automate them by simulating keystrokes that trigger those commands.

Eager API users such as myself would love to see some APIs above and beyond that subset of commands, of course. But, if the hardest part is getting that v0.1 API out the door... this might be the "crawl" you need to "crawl, walk, run."

[waydabber]

Thanks @modest for the suggestions! Yes, my plan was to add CLI to cover keyboard shortcuts first. The idea to support the x-callback-url pattern is useful as well.

[Wouter01]

Would the CLI only allow to pass commands to BD, or would it also allow to get data from BD? I'm developing an app which replaces the old macOS HUDs with more modern ones. It works fine for the built-in display, but it doesn't for BD because it reads the brightness levels from DisplayServices. To get around this, it would be awesome if brightness / volume changes are published so other apps can use them. Lunar has lunar listen which does something similar, and uses a socket to communicate with other processes. The CLI itself connects to Lunar with a socket to send and receive commands.

[waydabber]

Well now a socket based approach is a different one. I did not think that far ahead. There can be multiple supported ways of integration of course. :)

[taninke]

100% would love to see this app compatible with the functionality of MediaMate.

Currently it "over-writes" MediaMates UI when adjusting brightness, which is a bit frustrating UI-wise. Anything we can do to get that resolved would be amazing!

Aka what I should see via MediaMate being active:

What I see when I actively use BetterDisplay:

[waydabber]

@taninke - Right. If @Wouter01 has an idea that is quick&easy to add and can help MediaMate (or other apps) hook into BetterDisplay's brightness and volume (and other ranged) controls in an elegant way (both for control and getting notifications of changes), I am happy to collaborate or implement a nice solution.

[waydabber]

Maybe we could simply communicate over DistributedNotificationCenter with some UI for security to enable such communications maybe. This would be a simple, efficient and live communication. Using URLs for high frequency events like brightness control feels strange to me (but might also work).

I am not familiar about MediaMate - does it also control stuff or only show an UI? Probably it needs notifications only when the change is keyboard induced (so it should not present an UI when the user is changing the slider) and might need to inform BetterDisplay that it is taking over showing the OSD for specific tasks (like brightness or volume control) so BD should hide its own OSD for these controls but probably not for others (or can MediaMate work for other BD keyboard shortcuts like contrast etc with possibly getting a recommended SF Symbol for the corresponding action to show in the OSD replacement?).

[waydabber]

Anyway @Wouter01 - let me know if you have a general idea or maybe a brief overview of what you'd need. Then I think I'll create a separate issue for app2app integration - as I check out the MediaMate website, it might be an ideal partner app to figure this out with.

[waydabber]

@Wouter01 - #2143 - if you'd like to follow up, please check out that issue and let me know if this can work on your end.

[waydabber]

#2398
#2399
#2403

[waydabber]

I'll close this as integration tasks are subdivided into various issues. Those who are interested can follow progress by filtering to the Integration label:

https://github.com/waydabber/BetterDisplay/issues?q=is%3Aopen+label%3AIntegration+sort%3Aupdated-desc

[ShadowJonathan]

Why can't this issue then be reassigned to be a tracker issue? It'd help to centralise focus on what still needs to be done (and organise meta-discussion), even if a label provides the categorisation of those issues

[waydabber]

Right, I can convert this into a discussion.