Also along these lines of bizarre defaults, I don't remember how but I had to change key press settings to allow for repeated presses. Apparently the default behavior is to give you accent character options. Then from there I had to change the interval/initial timings to be closer to Linux/Windows as well. Of course now I'm paying the price with the dreaded repeat inputs on this keyboard
Ah, but it makes sense on Apple scroll wheels! I think that's why they never added a built-in option to disable it.
Nowadays the Magic Mouse doesn't even have a physical scroll wheel, but even on the Mighty Mouse, the scroll wheel was a little ball that could roll in any direction and didn't have notches, so acceleration made sense.
Acceleration + notches are what do not go together.
I would like to get VNC working but haven't done the research post wayland.
An app that does nothing but change an OS setting—and whose user interface exists purely to adjust those settings—does not belong in my applications folder, and certainly not in my menu bar. Such apps ought to live in System Preferences, alongside other, well, system preferences. And what do you know, Apple built a way for third party developers to do just that!
Preference panes used to be the norm, but that seems to have changed over the last decade. It pains me to admit that an app is probably the right approach nowadays, because when everyone else is doing things one way, users will expect you to do that too.
One more way that OS X's UI metaphors have regressed...
I never understood why it was there. It makes a ton of sense for content to scroll in the direction your finger moves when your finger is touching the content, but I fail to understand why you'd expect it to move that way when using a touchpad or a mouse.
Was this done specifically for users who were coming to Mac from iPad?
I suppose most computer users don't consider settings at all and just go with whatever the default is and eventually get comfortable using that, not knowing it's not "normal". But who made the change so that this became the new normal setting?
It made sense because it relates to PgUp/PgDn or to consider that you're pulling the scrollbar indicator down. (oh, what's that, this UI element is hidden nowadays..?).
Unlike some comments here, when I move from TrackPad to mouse, I still think of the scroll wheel as the document, so natural scroll makes more sense for me, personally.
The only thing I would get rid of in TrackPad is the "bounce effect" when you reach the Home/End of the document. Also, many documents are perfectly fit in the app window (e.g. Preview) but still the horizontal scroll moves them around, which is annoying (try opening a new PDF in Preview and use left/right arrow keys to move to next page; it scrolls the document horizontally slightly!)
Inverse or reverse mouse wheel (natural scrolling), reboot or unplug the mouse. Must be run in an admin powershell console.
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Enum\HID\\\Device` Parameters FlipFlopWheel -EA 0 | ForEach-Object { Set-ItemProperty $_.PSPath FlipFlopWheel 1 }
I myself added native wheel support to some major Carbon apps, and convinced other engineers to do it, as I was at Microsoft MacBU at the time.
But anyway, when Apple decided that scroll wheels should work the other way around, I gave it a try. I soon acclimatized to it and never had to change the default again. I would recommend all Mac users try out the "natural" setting and see if you get used to it.
Now explain why I HAVE to invert the y-axis in Halo on XBOX (any version of either). I tried but I can not adjust to the default.
Many years ago, when I was teachin my mother how to use the computer, I noticed something that I recalled the day Apple introduced the "Natural" Scroll thing.
She was working on a Word document, so I told her that she didn't need to click the scroll bar, but to scroll directly using the mouse wheel. To my surprise, she moved the wheel in the "wrong" direction. And for some seconds she was wondering why the whole thing was "inverted". In that moment I thought that probably we were all taught "incorrectly", and maybe, just maybe, "intuitively" people will think about scrolling on the opposite way, but we ended up learning that it was not correct, adapting our minds to the already established behavior of the mouse wheel.
The truth is. I embraced with happiness the "Natural" scrolling from Apple with the touchpad and the magic mouse on macOS, but also had a hard time getting used to this behavior with a regular mouse. I've been struggling since then, and I still use the "classic" scrolling with my Windows-based PC.
As for why I like them to be different, I think it's all about the tactile experience. I find using the trackpad to be very much like using a touch screen on a phone. In both cases, it's as if I'm manipulating the screen content directly with my finger. With the scroll wheel, it's a different tactile experience and the traditional behavior seems more "correct". Someone could do a nice human factors study on this.
My personal experience is that after years of keeping the "natural" scroll setting enabled, my scroll wheel has gained some of that tactile feeling in my brain. It's like the wheel is the content, and I'm pushing it up and down with my finger.
However, it definitely took longer for this to happen than with a TrackPad.
Every day I have to relearn how to scroll when I switch back and forth from my Mac and Windows machines. It frustrated me that the scrolling direction of two completely different input mechanisms were tied together.
Thanks again!
Hey, did you see the new animated emoji pack the new version is shipping with? Really should check it out!
> With ControlPlane you can intelligently reconfigure your Mac or perform any number of actions based on input from a wide variety of evidence sources […]
I also don't think it runs as an accessibility service, but as a low-level driver.
Downside is that it's not free.
I've created PR for brew cask, as I wanted to be able to add it to my dotfiles.
But there are certain UX fails by Apple I cannot comprehend and this is one of them.
I remember when this changed. It was years ago now. Apple decided the previous way of doing things was unnatural and just reversed it. If you want it the "unnatural" way you could use a setting. But the inability to split how the trackpad worked and how a scroll wheel worked is nothing short of pigheadedness ("no, it's the users who are wrong" to paraphrase Principal Skkinner).
Sadly this isn't an isolated example.
The earlier iPads had an orientation lock physical switch on them. I love this feature. And then Apple decided this was "inconsistent" with the iPhone (which had no such switch) and removed it. I mean the switch was obviously still there but now it did something completely useless. I think it muted the iPad instead? If you wanted this you could just hold down the volume down button. Then they briefly added back the option of getting the old behaviour but that only lasted briefly before that option and ultimately the switch were entirely gone. I used the orientation lock all the time and I'm still dark about it.
Another: a Bluetooth keyboard or trackpad connected to the laptop by USB will automatically pair. Great feature. Compare this to the Bose headphones I have, which are a total nightmare as soon as you pair to more than one device to the point where I've installed homebrew packages and scripts to disconnect Bluetooth when I close the lid of my Macbook (who decided it was a good default to pair to a Macbook with the lid closed vs one with its lid open? I mean does anyone even use pairing to a closed Macbook?). The problem? There's a popup I need to dismiss saying "This trakcpad is now wirelessly connected to your computer". Great. I don't care. I don't ever want to see this message again. Is there an option for that? No!
I find full screen mode for apps great. I often have it set up so my IDE is one screen and I can swipe left and right between my main desktop and my IDE. The problem? If your mouse gets near the top of the screen a menu bar appears, often obscuring the top of your IDE so you have to walk this fine line between getting high enough on the screen but not too high.
I have a 32" 4K monitor. I'm fine with the menu being visible all the time to avoid this. Really. Why don't I have that option?
Years ago Chrome actually worked like that. Then it mysteriously disappeared. When I worked at Google I asked about this and was told something like it was considered a "bug" and it violated Apple's UI guidelines or something similar. So now we have the dumb version.
Yet another: if you have multiple monitors, one of them is the "main" display. It has the dock. If you hit the bottom of the screen on a different monitor the dock will move. You can't turn this "feature" off. The best you can do is put the dock somewhere else. I don't want the dock somewhere else.
What's really troubling about the last two is they really ignore the basic tenets of HCI in that the corners and edges of the screen are the easiest places to hit. Microsoft famously ignored this years ago when on Windows 9x the Start button was offset by a couple of pixels from the corner for no good reasons. No doubt some designer's opinionated sense of aesthetics.
So, rant aside, thanks for making this utility. I know there have been other solutions to this as well. Part of me still hopes Apple sees reason and reverses their dumb decisions here.
[Don't you people have better things to downvote?]
Honestly can’t believe this is not default behavior in macOS.
I agree apps filling up the menu bar is annoying, so there is an option to hide it if you wish.
Point is, it can appear that the OS settings pane/app/whatever is for stuff Apple controls, and the rest has to go in an app or menubar. I'm not saying it's right, I'm saying that Apple has let the messaging get really confused.
Right—part of Apple's job is to create an environment where the "correct path" is clear and developers want to follow it. Either Apple used to do a better job, or else developers did.
And, consider:
• Apple encourages developers to distribute via the Mac App Store as much as possible.
• Preference Panes cannot be sold in the Mac App Store.
• In Catalina, all Safari extensions must be installed from the App Store as individual apps.
• New Notification Center widgets are always installed as applications. Old Dashboard widgets never were.
I would say that taken together, the clear implication from Apple is that apps are the way to go. And it all comes back to the Mac App Store, which Apple wants to push that at all costs. Evidently, they either actively don't want to sell non-apps in the store, or they don't care enough to build that functionality.
There are probably times when Apple's patterns are just wrong and the community coalesces on something better—I can't think of any, but it has probably happened, or will some day. But I do not think this is one of those times, because if you step back, using an app does not make objective sense.
(P.S. It's interesting to note that Apple's own iOS apps tend to have far fewer in-app preferences, in favor of sticking stuff in the Settings app.)
It’s not even an Apple thing, Windows has been the same for a very long time - remember how browser extensions “exploded” when Mozilla made it possible to write them in JS? IE forced you to C++, dramatically restricting the number of developers.
I'd agree that most of the focus has been on app development, but I just found this toy kernel written in Swift the other day: http://si.org/projects/project1/
On the Objective-C side, sure you have access to all of the low level stuff of C, but Objective-C's message passing is probably a poor choice for very low-level system programming (in the kernel, for example). Apple uses C and C++ in the xnu kernel.
Swift was also designed to interoperate with C and Objective-C APIs, so you could certainly write a preference pane in it. It even automatically generates Swiftier interfaces for APIs that follow conventions. Here's the NSPreferencePane API: https://developer.apple.com/documentation/preferencepanes/ns...
If that was the case (I don't believe it is), it would only be because modern Apple doesn't care enough about Preference Panes to add easy support. A third party Preference Pane is not any more "OS machinery" that a third party screen saver.
Whereas when I am using a mouse I feel like I the document is below the mouse more or less and when I move the scrollwheel it is physically moving the document as if it was tied to the scrollwheel.
Not sure if that makes any sense, as this is just some internal feelings on it, but I have beeen manually toggling the natural scroll when i plug and unplug my mouse ever since I started using MacOs
However, when I use a touch surface such as a trackpad or touchscreen I like to push the page up.
disclaimer: not a magic mouse user.
Mentally, the same mapping does not happen with a scroll wheel. So it’s a weird psychological block when I scroll down with a scroll wheel and the page goes up.
Why would people be confused by some piece of hardware not behaving like some completely different piece of hardware?
Just intercepting the actual scroll and inverting it is a really elegant solution (that doesn't require a relog) which is great.
This solves one of the two biggest gripes I had about MacOs - with the other being my inablility to "pin" my dock to one of my monitors, overriding the swap functionality. Thanks!
A bit of both I would think. When the Mac was a more niche platform the developer community tended to be more bought into philosophy and design sensibilities around it. And as the Mac has gotten more widespread in popularity, Apple has gotten less good at planning around power-user use cases or communicating how to handle them elegantly.
I still kind of hold Apple accountable for that, though. As the platform grows, Apple has more resources they can dedicate to clarifying UI patterns, or systemic coaching via API design. But they've gone in the opposite direction.
Not true, you can distribute outside of the App Store as long as you sign/notarize correctly.
I think I was getting confused with old-style extensions and the Safari Extension gallery, for which sideloading was truly blocked for around a year.