System Preferences-->Accessibility-->Display-->Reduce transparency
at the start and end of a KM macro.
(I am doing this in an attempt to solve a problem matching a "Clicking Found Image" after right-clicking an image on an Opera webpage. "Reduce transparency" does seem to solve the problem but I'm not sure if that is the best way to fix that issue.)
Can you see the error in my AppleScript? Or is there an easier KM-only solution? Thanks.
I've never attempted it myself but I find this to be an area I'm interested in. For example I may want to use this method to reduce the mouse speed to minimum while my macros run so that the user can't interfere with my mouse manipulating macros. Once I figure out how to do that I'll probably post that on this site.
I get odd behaviour. The 2 shell scripts do tick/untick the R.T. box but nothing happens to the actual transparency on my High Sierra Mac. If I tick manually it works.
Also -- Are you saying that AppleScript just won't work here due to a MacOS bug since 2016's Sierra?
I can of course just use KM to click on images etc. Thanks.
The below script works in macOS 10.14.5 (Mojave), so I can't say for sure it will work in High Sierra.
There are two caveats:
It assumes that "Increase Contrast" is UNCHECKED
It uses several delay statements, which you may need to adjust (increase).
As a result, this is NOT a fast process
Please let us know if this works for you.
AppleScript to Toggle Reduce Transparency (Mojave)
Tested only in Keyboard Maestro 8.2.4 on macOS 10.14.5
property ptyScriptName : "Toggle Reduce Transparency in System Preferences"
property ptyScriptVer : "1.0"
property ptyScriptDate : "2019-07-04"
property ptyScriptAuthor : "JMichaelTX"
activate application "System Preferences"
delay 1
tell application "System Events"
tell process "System Preferences"
tell window 1
perform action "AXRaise"
set focused to true
delay 0.2
set winName to its name
end tell
--- Open System Prefs to Accessibility Panel ---
if (winName ≠ "Accessibility") then
if (winName ≠ "System Preferences") then
click button "Show All" of group 1 of group 2 of toolbar 1 of window 1
delay 0.5
end if
click button "Accessibility" of scroll area 1 of window 1
delay 1.0
end if
--- Select the "Display" Section/Button ---
set oRow to row 6 of table 1 of scroll area 1 of window 1
tell oRow
set selected to true
set displayCell to UI element "Display"
tell displayCell
set selected to true
end tell
end tell
delay 0.1
--- TOGGLE The "Reduce transparency" Checkbox ---
-- (This Assumes that "Increase Contrast" is UNCHECKED)
click checkbox "Reduce transparency" of group 1 of window 1
end tell
end tell
tell application "System Preferences" to quit
Hey @JMichaelTX, assuming Mojave hasn't intentionally deleted System Preference's AppleScriptability, it would be much more advisable to navigate your way through to the appropriate place using panes and anchors. It would also bypass the issue that @cvc8445 found where the wrong UI element was being clicked.
Another tip regarding System Preferences: you don't need to activate it, and it's a much more pleasant user experience not to do so. The UI tree can still be navigated perfectly well despite System Preferences being kept in the background and out-of-sight.
For anyone still trying out various options, here's how I would do it (for an English-language system):
use sys : application id "com.apple.systemevents"
use scripting additions
property process : a reference to process "System Preferences"
property window : a reference to window 1 of my process
property system version : (system info)'s system version
property HighSierra : the system version starts with "10.13"
--------------------------------------------------------------------------------
-- Open preferences pane and wait for it to load
tell application id "com.apple.systempreferences"
set UniversalAccess to pane id "com.apple.preference.universalaccess"
reveal anchor "Seeing_Display" in UniversalAccess
repeat until the current pane = UniversalAccess
delay 0.1
end repeat
end tell
set object to a reference to my window
-- A recursive descent through the UI elements to look
-- for checkboxes in case non-High Sierra systems have
-- a different structural hierarchy
if not HighSierra then repeat until the ¬
(object's checkboxes exists) or ¬
not (the object exists)
set the object to a reference to the object's UI elements
end repeat
if not (the object exists) then return Q(false)
click (the object's checkboxes whose name = "Increase contrast")
Q(true)
--------------------------------------------------------------------------------
on Q(e)
quit application id "com.apple.systempreferences"
return e
end Q
And, likewise, one can simply replace this line in my script:
click (the object's checkboxes whose name = "Increase contrast")
with this one:
click (the object's checkboxes whose name = "Reduce transparency")
to target that checkbox instead.
Testing in High Sierra appears successful. It takes about 3-5 seconds on my system to complete, but that's faster than doing the more UI-heavy approach.
I don't have Mojave, but I have incorporated a conditional block that runs if the system isn't High Sierra, seeing as I don't know the UI tree layout, so decided to perform a quick search for the first checkbox element it finds with a particular name. If it works in Mojave first time, I'll be gobsmacked. If Mojave System Preferences doesn't respect its own AppleScript dictionary, however, I apologise in advance for time-wasting and would understand why navigating through its UI would be necessary.
How did you discover that the "Display" sub-panel corresponds to the anchor "Seeing_Display"? I don't see any reference to that string in any of the UI elements.
It's not a UI element. It's an AppleScript anchor element that is contained by a pane element, which in turn belongs to the System Preferencesapplication class object. Thus, you can enumerate them for a specific pane by first opening System Preferences and navigating yourself to the relevant pane (in this case, Accessibility, as it's called on High Sierra), and then run this AppleScript snippet:
tell app "System Preferences" to get the name of every anchor in the current pane
It was fairly evident at the time which was the likely anchor name to use, but if not, you probably just have to work your way through a series of reveal commands until you find the one you need.
Note:anchors can only be referenced by their name property; they don't have an id property. Therefore, consideration might need to be given for localising these name values for non-English language systems.
It relies on the Display subpanel of the Accessibility Pane always displaying at the same size. That will be the case if it always opens on the same monitor (or if all your monitors have the same pixel density and scaling settings), and don't change the scaling.
If that's the case, you simply designate the coordinates of the checkbox relative to the pane's upper left corner. These coordinates work for a mid-2014 15" Retina MacBook Pro.
If you want to use it for some other checkbox, you simply change the coordinates. For instance, I actually use this for Invert Colors; I simply modified it to work for Reduced Contrast.
I've found this approach has great general applicability—with a combination of tabs and arrow keys, you can often access screens and options that would otherwise require either Apple Script or KM's Find Image on Screen—and both of those can be problematic.
