Lunar

Check out https://github.com/alin23/Lunar it's the most advanced app on mac when it comes to controlling screens

I believe git-secret[0] does what you describe. The author of Lunar[1] uses it to hide the private elements in a public repo. [0]: https://sobolevn.me/git-secret/ [1]: https://github.com/alin23/Lunar/

As the dev of a macOS app that breaks all the time because of external hardware, the tone of the article hits close to home. (I’m talking about https://lunar.fyi/ whose brightness control commands can be blocked by USB-C hubs, “smart” monitors, too long cables etc.) I had to disable public GitHub issues on the app repo [1] because people seemed to fuel each other with spiteful comments and “why can’t you just!!” sentences. The contact form still attracts many such “entitled” people and it hurts to wake up to such messages, but at least I can choose to ignore those if I can’t bring anything to the discussion. There’s no peer pressure. These people are expecting too much from a handful of developers who are sharing a lot of free work and time that could have been spent better than hunting new IDs in URLs and updating regular expressions. [

Since Ventura 13.3, you can access those hidden resolutions yourself from System Settings by Option-clicking on a scaling option. Also, Lunar is mostly open-source and many apps borrowed code from it (even competitors). For example here is the Notch button implementation: https://github.com/alin23/Lunar/blob/master/Lunar/Data/Displ... The Notch disabling function is free and doesn't require paying for a Pro license.

Most of the delay is I/O bound. Handshaking happens over the Display Data Channel (DDC) which is a protocol over I²C (a two-wire comunication bus). HDMI/DP/DVI have 2 dedicated wires inside the cable for this, USB-C has to switch over to use differential signaling on pins A8 and B8, and then switch back after communication is done. The bandwidth of that bus is small indeed, but most of the latency comes from artificial delays and error recovery in code: monitor is sending a message to host then sleeping 30ms to make sure the reply is ready, host doing the same thing, and this happens multiple times to negotiate pixel clock, signal timing, colors, resolution, additional features like suspend/reset/HDR/overscan etc.) You can see how in the MCCS specification [1] both host and display entrypoints for communication start with a delay: https:/

> My best selling app Lunar (https://lunar.fyi/) is done in AppKit with Storyboards and it’s a pain to maintain (source here: https://github.com/alin23/Lunar) I just wanted to say that you can and most likely should use UIKit without touching interface builder. It's been over 5 years since I've used interface builder and I have no regrets. Just build your UI programatically relying mostly on UIStackViews, constraints and multiple levels of views embedded in views. Write your own helpers on top of UIKit to help you compose views in a more compact way. I basically have a dozen functions I re-use over and over and over to build complex UI from these simple primitives.

Author here! My best selling app Lunar (https://lunar.fyi/) is done in AppKit with Storyboards and it’s a pain to maintain (source here: https://github.com/alin23/Lunar). So much that I finally created a SwiftUI menubar menu for it where I can add the more dynamic bits easily, and just leave the AppKit UI for static preferences stuff. Both AppKit and SwiftUI are good though, Lunar was the first time I was able to create a native UI from scratch and also release it without remorse. But I felt that the dynamic parts were much harder to reason about in AppKit, mostly because of the Delegate paradigm. I also have a preference for a not-so-native look which is much simpler to style using SwiftUI modifiers like clipShape, shadow etc.

I usually open source free apps, that I don't think I'll ever be able to sell because "who else could have the same problem as me?" If it turns out that people have a need and want to pay for Pro features, I try my best to keep the source available for the free part of the app, and only encrypt the code that constitutes the paid features. That happened with Lunar, and it seems to start happening with Clop as well. I have no idea if it did impact my profits at all, but it did help other people to start competing with me. The only competitors to Lunar (MonitorControl and DisplayBuddy) started by using Lunar's code [1] for controlling monitors on Apple Silicon [2], as Lunar was the first app to get that feature. Competition is still good though, as long as it's not break-neck competition. I learned how to make Lunar simpler in terms of menub

Thanks for the kind words! I’d say I had a year of full time work (on and off in 3 years of time) until I had Lunar 3 which was the most stable until Apple Silicon arrived: https://github.com/alin23/lunar/tree/lunar3 I had accumulated about $5k in donations over those years which allowed me to quit my job, do 6 months of full time work in 3 months of time, and launch Lunar 4 with support for Apple Silicon: https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/ After that, the hard work started because now I had paying users asking for a stable app that was very Hardware dependent on a completely new macOS architecture. 9 more months of full time work followed. Right now it’s finally quiet. I do about a bug fix and small feature release per month and I have plenty of time to work on my other apps.

Do also check out my Lunar app (https://lunar.fyi/) if you want more automated intelligent adaptive brightness for external monitors, along with some innovative features like Sub-zero Brightness (for those late nights with tired eyes), XDR Brightness (for working in the sun on your XDR MacBook Pro) and Blackout (for turning off individual displays). DisplayBuddy uses Lunar’s open source implementation [0] for controlling monitors using DDC on M1 [1] so they both do the same thing at the lower level. There’s also a comparison table with DisplayBuddy here: https://lunar.fyi/#comparison [0] https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#... [1] https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/

Yes, it's not open-source by that definition. It was fully open-source until v3: https://github.com/alin23/Lunar/tree/lunar3 I've kept that around, it's still compilable, but probably not that useful. When making Lunar paid in v4, I didn't want to remove the possibility of sharing knowledge, so I kept the non-paid parts open-source. This allowed other apps like MonitorControl [1] and DisplayBuddy [2] to port some Lunar features (like DDC on M1) to their own code. So I'd say it's still useful enough. [1] https://github.com/MonitorControl/MonitorControl [2] https://displaybuddy.app

It’s not screen dimming. It is an app to fully control the monitor without using its physical buttons. Lunar can change the hardware brightness, the same one that you can change using the monitor OSD. That in itself required a lot of reverse engineering and research about the DDC protocol. Adaptive brightness, ambient light sensor integration and other automatic features also needed months of non-stop work. Plus, the app is open source, trying to give something back to the community which gave me the inspiration to create this: https://github.com/alin23/Lunar Even with $23 per license, after taxes I barely make half of what I made at my previous job where I worked less hours. I don’t understand how you can dismiss this so simply. the people pirating your software probably wouldn't have paid for it anyhow I heard this argument so many

I've done that with Lunar (https://lunar.fyi) Lunar 3 was free and open source, then a very high effort upgrade had to happen because the M1 CPU needed different low level logic for controlling monitors, so I made Lunar 4 paid. I still keep Lunar 3 as a free download right on the front page, and its source code is untouched in the lunar3 branch (https://github.com/alin23/Lunar/tree/lunar3) Most people were happy to pay and support me for the new app, but inevitably there were some very rude messages because some users felt entitled to getting the upgrades free forever. I think it's a perfectly reasonable thing to do, it's your work and your time and you should ask to be compensated for it if you need the money.

I just ordered the M1 Max with 64GB RAM because I'm constantly getting the "Your system has run out of application memory." popup while working on Lunar[1] in Xcode. Every time this happens, Xcode uses about 4GB of RAM (probably because of the monolithic UI storyboard of Lunar) but it should still leave enough memory for my other non-memory hungry apps. But then I open Activity Monitor and I see WindowServer using ~80GB of memory [2] The only remedy is either `killall WindowServer` or a full reboot. I've been using an M1 MacBook Pro and Monterey since the first developer beta but this only became an issue in the last 2 months or so. [1] https://github.com/alin23/Lunar [2] https://cln.sh/CfEL6u

> When you map “white” down to gray, you have to drive the LED backlight brighter for the same perceived screen brightness So that's why Lunar[1] reads a much higher brightness and makes all external monitors as bright as ten thousand suns when HDR content is played. I wonder if there's any way to detect this and read or compute the SDR brightness instead. [1] https://github.com/alin23/Lunar/issues/86