Open bland328 opened 4 years ago
Which would be a use case? In what situations might a percentage be more useful? Especially as in either case, “25% down” could result in a position (theoretically) outside the screen bounds. Or are you rather interested in percentaged absolute values?
OO=(`{cliclick p:. && osascript -e 'tell application "Finder" to get bounds of window of desktop'} \
|tr ',' ' '`) && printf '{\n "mouse-xy-pct": {"x": %d, "y": %d}\n}\n' \
`echo $((${OO[1]}*100/${OO[5]})) $((${OO[2]}*100/${OO[6]}))`
zsh
-- remember basharrays differ from 'zsh' ones; indices enumerate starting at
0, zsh at
1-- just subtract 1 from the stuff above if spawned from within
bash. (+
bashdifferent compound command syntax.
{ cmd1; cmd2 }. Can't remember how that works. Let me know if issue. I know it requires a terminating semicolon after
cmd2` at least.)$ system_profiler SPDisplaysDataType|grep Resolution
any old stackoverflow-cli
-esque query will dig up for you. I've seen SPDisplaysDataType
representing a lot of strangeness -- anything between max resolution built-in graphics setup is capable of (in the context of macOS and according to Apple, that is!), to he maximum [retina] resolution (sometimes 2x) of whatever is currently set. While what you want is just the actual resolution currently set and activated through System Preferences
or something to that effect. Multi-monitor setups need more love than this hack.$(( integer math ))
parts with pipes to bc
that other fancy floating point capacity you've been saving, to triumphantly pull out at occations like this.jq
and friends, like so:clicklick
here. Originally came here today to determine whethercliclick
when color sampling could output hex like $ab919f
and $0a0a0a
in addition to the 14 255 94
8 bit decimal. -- so similar to the above, in case someone else also came here looking for that:
printf '$%02x%02x%02x\n' $(/usr/local/bin/cliclick cp:.)
Sorry for the necro-posting, but just today I found an use case for this: I've recently raised the resolution of my macOS Desktop (from the middle, recommended, setting, to the next one to the right) and now my cliclick-using scripts don't work. Percentage positioning would be perfect in this scenario.
Sorry, but I’m still not convinced this would be a frequently needed use case. If you switched resolution once and will keep it, updating the scripts once will make them work again – if you plan to switch resolutions repeatedly, you’re free to calculate positions yourself in your scripts. Plus: I don’t see how this could work reliably with multiple displays. (Which is something which I’m always aware of, as I almost always use two.) Switching a MacBook’s display to twice the resolution does not mean you have twice the width or heigth when using a second display, and therefore, a 50%,50% coordinate would (probably) not be at the center of the screen. One could argue that this could be a feature which only works with single-display setups, but that doesn’t feel convincing for me.
@atnbueno You can find what you need to hack together a solution from here:
https://apple.stackexchange.com/questions/162860/how-to-view-current-display-resolution
You could make a small shell script that finds your main desktops X and Y resolution. Then if you want to move your cursor to 60% right and 40% down you just calculate the respective X and Y coordinates from your percentage of the max resolutions, and call on cliclick
to move the mouse pointer there.
If you like customizations, I'd also suggest looking into these which gives you ways to do what you want and via a GUI:
If you really like customization, keep digging:
Good luck, and please share if you make something useful around your percentage problem :-)
Feature suggestion: I appreciate the value of pixel-perfect mouse positioning, but I occasionally have "looser" requirements for mouse movements, and would love to be able to move the mouse to, say, 25% of the way across and 40% of the way down the screen, without concern for the resolution of the current display.
Of course, this is a lovely way to get to the center of the screen, too, without wrapping the call in external math.
If get some free time sometime soon, I'll take a shot at it myself and send a pull request if it proves to be slick.