https://www.dropbox.com/s/k9ty3xoefizf2fl/MacDisplaySettings.zip?dl=0
Dear Mario
Please add this to the PsychContributed folder. MacDisplaySettings uses AppleScript to peek and poke 7 parameters of the macOS System Preferences:Displays panel, any of which can wreak havoc on attempts to calibrate a display if other users fiddle with them. It solves the problem by saving whatever values are present, imposing the values you need, and when you’re done, allows you to restore whatever was current. It handles Brightness, AutoBrightness, True Tone, Night Shift, and Color Profile.
It consists of two files: MacDisplaySettings.m and MacDisplaySettings.applescript
The usual psychtoolbox license is fine.
Thanks.
Best
Denis
p.s.
This routine is not intended to ADD features. Rather it is intended to eliminate unwanted effects of macOS features that get in the way of doing vision research on a Mac.
pps
This makes AutoBrightness obsolete. MacDisplaySettings is much faster and more reliable and handles many more parameters.
Hi Denis,
could you send this as a GitHub pull request, so origin and authorship is better documented in the commit logs, and also so i have less work with it?
I added an extra disclaimer to the PsychContributed folders help text to warn users that any code in that folder has to be considered completely untested and unsupported in case of trouble, and that the code may change or even be removed without warning or regards towards backwards compatibility.
This way i can just pull this function in without any previous testing or review of the code, for which i don’t have time atm.
With that in mind, is it possible for you to change AutoBrightness to become a dumb wrapper around the new function, so it keeps working, but uses MacDisplaySettings() internally? We could also just delete it. A bit user hostile, but given that the normal rules for Quality and stability do not apply for the PsychContributed folder, i can live with that.
Thanks,
-mario
dear mario
sure. i’ve used github for my own software, but never done a pull request. i tried to submit it as a pull request last night, but I got stuck and couldn’t figure out whether i was connected to the right repository. i’ll try again tonight.
yes, you’re right, replacing the guts of AutoBrightness with a call to MacDIsplaySettings is a good clean solution. I’ll do that.
best
denis
Hi Denis,
Make sure you fork the psychtoolbox repository so you have your own copy on your own github. Update that one, adding/changing the files, committing and then pushing it to your online copy of the PTB repository. Then, in the github interface looking at your repository, or at the PTB repository, it should probably note the differences between your copy and the PTB repo you forked, and suggest making a pull request.
Cheers,
Dee
Dear Dee
Thanks. I’ve done the first part—I made the changes, committed, and pushed them to my branch of the Psychtoobox-3 repo. But, no, Tower is not prompting me to make a Pull Request. I’m stuck. Here’s a screen shot.
Any suggestion?
Best
Denis
Hi Denis, I normally initiate a pull request from Github itself:
I’ve never used Tower, so don’t know if it supports handling pull requests but other GUIs don’t. If it is supposed to, it may need an upstream repository added. Adding the upstream repo allows you to pull in Mario’s changes locally to keep your fork “fresh” (you’ll notice you are quite a few commits behind Mario’s). At least on the commandline, to add an upstream remote you can use:
cd Psychtoolbox-3 # cd to your fork's local directory first
git pull # make sure you're up-to-date locally
git remote add upstream https://github.com/kleinerm/Psychtoolbox-3.git
git fetch --all
git merge --ff-only upstream/master
As you’ve pushed to your master, then --ff-only will fail and you can just remove and merge manually. This is why it is preferable to always make a new branch to make any changes, and keep your master a pure copy of the upstream master.
Dear Mario, Dee, and Ian
thanks for the help. This new version of Tower advertises its support for pull requests, but I can’t get anywhere with that. Instead I went to GitHub, following Dee’s advice, and tried from there. It seems to have worked.
However, I can well believe i’m several commits behind the master.
Ian, thanks, but i’m not fluent enough with Git to follow you. What “Command line”? Terminal?
Thanks all
Denis
Ian, thanks, but i’m not fluent enough with Git to follow you. What “Command line”? Terminal?
Yes, Terminal.app (or iTerm.app etc.) will allow you to work directly with git (you need the Apple command line tools installed, or use homebrew to install git). Most git commands are very straight forward and logical (pull / push / merge etc.)
Dear Ian
ok. I typed your commands into Terminal and they ran without a hitch!
Now Tower seems to be comparing my folder with the master, which is great, but it says I’m 198 commits AHEAD!
It doesn’t make sense for me to PUSH now, because Mario has already accepted my pull request for the only change I made. Any other difference I want the master, not my copy.
I tried pulling, and there’s nothing to pull. Tower now seems happy, but those 198 commits waiting to be pushed worry me.
How do I erase the differences and make my repository follow the master?
Thanks!
Best
Denis
It think it is telling your local is now 198 commits ahead of your own fork which is origin/master, not that you are ahead of upstream.
As long as you haven’t pushed back to Github yet (I can’t see you have according to https://github.com/denispelli/Psychtoolbox-3, which is saying you are 198 commits behind Mario), you can do a git reset again in terminal:
git reset --hard origin/master; # force reset back to your origin
git clean -fd; # not strictly necessary unless there are some left over files going back to the older revision.
You should get back to your previous state. I imagine Tower has a GUI version of reset --hard. Then when you are ready you can try to merge again and if you are happy, then you can push to your github origin/master.
In my fork of mario’s upstream, I tend to keep my master closely identical to Mario, but I only ever merge these changes individually, and when a beta is released, only then do I push that state to my fork. This means I can keep on the bleeding edge with the ability to reset my way back from danger if something breaks. Most users should stick to SVN, but once you get comfortable with Git (and if you don’t mind how much bigger the git repo is), it can be a really nice way to automate software updates across many lab machines…
Dear Ian
that did the trick. I now can make my Pull Request from within Tower. (I polished MacDisplaySettings.) This is great! Many thanks.
Denis