Implement more display events

[Masstronaut]

overview

There are a number of use cases (#624 #707) where having more granular display events would be helpful. This PR aims to implement more specific display events, for use cases such as multi-monitor + window manager setups.

SketchyBar already had plumbing for several types of display events, but was only sending a display_change event. This PR implements more of the display events:

• display_added
• display_removed

---

With some guidance, I'd also be open to adding the following, however haven't implemented them yet - just stubbed out.

• display_moved
• display_resized

I also would prefer not to have this PR held up on them, and so would be happy to revert them in this PR and implement in a separate one to get added/removed across the finish line faster.

My asks:

• A go/no-go on whether you are open to changes of this nature being added to SketchyBar
• Review the design decision for the Events approach and confirm/deny this is the right path
• Help me understand the behavior of monitor added/removed events for N>2 displays to architect the right solution
• Explain the use case and data that should be included for moved/resized events so they can be implemented

design decisions

Events approach

Currently, built-in sketchybar events include data in the $INFO env variable. When it comes to display_change this is woefully inadequate for a number of reasons:

1. It's not clear what display change occurred (focus change? Monitor added? removed? etc.)
2. The $INFO always includes the active display, which is unintuitive in many cases. For example, adding a 2nd display with ID 2 would fire a display_change event with $INFO of 1, when nothing changed about display 1.

To remedy this, there are 2 obvious (to me) possibilities:

1. Include more variables in the display_change event. For example, a $TYPE that contains added/removed/changed/etc. and then update the value provided via $INFO to be relevant and useful for the specific event type
2. Add new event types for the other display events, and use $INFO to provide the relevant data for that event

I believe option 1 (adding to display_change) has several disadvantages:

• It is a breaking change to modify what data is sent in $INFO
• Forcing users to do more complex event handling on a display_change event requires users to write more code and therefore more bugs that lead to issues opened on SketchyBar
• Having more listeners to a bigger event takes more CPU cycles than having listeners on smaller events that require less handling

For these reasons, I opted for option 2 - add new event types for the other display events.

Monitor tracking

I wasn't able to find a cached store of the connected displays which would probably be the most reliable way to send events about monitor state changes. For display added/removed, I took a naive approach which is to:

1. assume that monitor IDs are assigned sequentially without gaps and 1-indexed
2. set the added display as the active display count (via display_active_display_count())
3. Set the removed display as the previous active display count, ie uint32_t removed_display_id = bar_manager->active_displays;

My M1 13" mac only supports 1 external display, so these assumptions are fine on my device. For users with multiple external displays, I don't know if this works correctly when monitor id 2 of 3 is disconnected:

• Does 3 get reassigned to ID 2 or is ID 2 left as a gap?
• Does a new monitor being plugged in get assigned ID 2?

I'm open to implementing something more complex to better handle these scenarios, but I don't have the hardware to test them so if someone knows where to find documentation on this behavior or has the hardware and wants to pull this fork, add event listeners, and figure out how it behaves, that would make it easier to design a good solution.

@FelixKratz if you have thoughts on how you'd like to see this implemented, I would appreciate that!

Display moved and resized events

I'm not sure what the intent is with these events, but @FelixKratz if you have an opinion of what data you'd like to have sent in $INFO and where I can get that data, I'm happy to get these across the finish line too. I personally don't have a use case for these, so I am low confidence about what they should do.