Apple has put a lot of work and polish into its touchpad drivers, and it makes a huge difference; it's probably the largest single differentiator Macbooks have over other manufacturers. Part of it is latency (which will probably also require some work on the graphics stack), part of it is handling all the corner cases correctly. (Improving latency probably also requires some work on the graphics stack, not just the touchpad drivers.)
A simple test which Macbooks pass, but Windows and Linux laptops fail: fling scroll down a web page, then press Cmd/Ctrl+W to close the tab before the fling scroll has stopped moving. On Macs this works correctly; everywhere else, it acts as though you're spinning an old-style wheel mouse while holding Ctrl, and zooms in repeatedly.
I agree 100%, and I also think Force Touch doesn't get the attention it deserves. To me the 2015 Macbook Pro is the pinnacle of laptop engineering because it added the Force Touch touchpad. Being able to click anywhere on the pad and configure the strength of the haptic feedback is huge. Not having haptic feedback, or having to use a separate button, or having it vary from top to bottom depending on how far I am from the hinge, is no longer acceptable to me.
Without Force Touch-like trackpad hardware, other laptops are still too far behind.
I can only speak for my mid-2015 15" Retina MacBook Pro, and the whole pad is clearly flexible and very slightly sprung (and yes, it's made of glass - thin glass is quite flexible). You can see it flex and bend by looking across it while deflecting it - it's most easily seen by looking at the gap around the edge of the pad, between the pad and the laptop casing, while deflecting it close to the edge. The gap varies as the pad is deflected.
What it doesn't do is haptic feedback when it's turned off. There's no click. I infer that's because the click works by applying a mechanical kick back close to the point of deflection. Your finger wouldn't feel it as a click if there was no mechanical movement at all. A bit like a speaker: speakers are mechanical devices too.
> we’re pretty sure the magic pressure sensors in the new Force Touch trackpad are tiny strain gauges. Mounted on flexing metal supports, they detect the amount of flex on each—and based on that, the force from above.
I have bought Magic Touchpad for its "Force Touch" quietness, but other than that, I find it to be more of a gimmick. It is slightly better than the hinge-pad of my Yoga 2 Pro, but it's not a life-changing experience. What is a deal-changer for me is the volume of its click sound, especially when configuring its force feedback engine on GNU/Linux to get even lower than what macOS allows ;)
I've been an exclusive touchpad user for years already. This really isn't a big change - well, it could be if you move from a really crappy touchpad (and from my experience perceived crappiness is usually software's fault, although of course there are some bad apples in hardware too).
Having used the Macbook trackpad... I don't understand the hype. As a trackpad, it's brilliant. But so what? On a table, I'd much rather use a mouse. The weirdly inaccurate precision, odd acceleration, and clumsy movement makes the trackpad feel off. There's no acceleration sweetspot and there's no sensitivity sweetspot that I could find.. On my lap, I don't usually have enough space to use a trackpad over say a trackpoint.
It's a great solution, but it just doesn't solve any problem I have. I'd rather have a scroll wheel.
Having used a trackpad for years, I don't even use a mouse when one is available (outside of 'gaming') and use my trackpad 100% of the time. I also use my laptop for hours per week on planes / trains on my lap without any issues from the trackpad. For me, that's not something that ever felt comfortable to do with the trackpoint.. and trying to use a mouse on a train seems like it would be unpleasant.
I expect I'm not the only person in that situation and it's great if more effort goes into trying to improve the trackpad experience of linux on a laptop!
How do I do gestures on a mouse? Example: drag a file, 3 finger swipe to different desktop, drop file.
Done by holding a button that doesn't exist, but which you forget isn't there. Cos the driver is that good.
I prefer being able to scroll horizontally and vertically, zoom in/out and rotate on the spot. There's no question the multitouch model is more expressive, but we're all gimped by mice.
I disagree, I still prefer the old-style Macbook Pro touchpad. Though I haven't used the new one on daily basis, I have always thought it felt strange.
That's not Force Touch though. It's the Apple Taptic Engine simulating a click with a vibration. Force Touch, or later 3D Touch, refers to the ability to distinguish between various levels of force: https://en.wikipedia.org/wiki/Force_Touch
I hate Touch-Force and wish I could buy a machine with distinct mouse buttons today.
I'd view it as feature that is usable when the hardware and drivers are done well and just miserable when they are bad - the possibility of your typing and your mousing getting in each other's way seems to increase with every generation of laptop form factor, with more gimmicks needed to stop it (oddly similar to the 737 Max problem - reading the edge of software compensation).
Palm rejection on the latest 15" MBP is impeccable, in my experience. I was pretty worried about that before purchasing, just because it's hard to imagine how they've perfected it on a touchpad that large, but they truly have.
Would you care to elaborate on why this is your opinion? For now, your comment just reads like a regular post on the MacRumors forums: a short and generic complaint.
It's been working correctly since 2013 on my Thinkpad T530. Ctrl+scroll zooming is definitely enabled, I use it regularly. I use the Windows Update-supplied driver.
It's because macOS implements kinetic scrolling in the toolkit, not in the driver (like xf86-input-synaptics and some Windows drivers do). The driver itself on macOS isn't really exceptional.
>It's because macOS implements kinetic scrolling in the toolkit
Which is the proper way to do it.
Other vendors wanted to emulate macOS’s inertial scrolling but they had to stay compatible with all sorts of legacy APIs that only knew mouse events, so some of them cut corners and started sending these fake mouse events from the driver, to be the first on the market with “macOS-like scrolling”™.
Of course this is very much a bolted-on solution, which leads to all sorts of nuisances like what’s described in the parent comment, and contributes to the general sad state of trackpad behaviour on Windows and Linux.
They’ve pretty much cornered themselves, because fixing it would require a coordinated effort from the hardware/driver vendors, the OS vendors and the UI toolkit vendors. It’s just unlikely to happen unless you own the whole stack like Apple does.
Not really, at least not in the GNU/Linux case. The proper way is to do it in the driver (or in some HID abstraction of the operating system - so compositor maybe), but clearly differentiating such events in the client API, so it can be properly interpreted by clients and ignored when not relevant. Otherwise you fail to handle the case where you put your finger still to stop the scrolling steadily enough to not generate any cursor movement (libinput+GTK combo fails here, btw) and to fix that you have to move all gesture processing (including basic scrolling) to the toolkit, which is a bad idea in an environment where multiple toolkits can be used at once (basically a recipe for UX disaster).
Well, at least Apple’s gesture handling API have a proven track record.
You can’t abstract away gesture processing because it’s deeply intertwined with the UI logic. Inertial scrolling, rubber band effect, concurrent gestures with complex exusion rules between them, etc. If you try to abstract them away from the UI library, you’ll end up with a bloated meta-toolkit that still won’t cover all use cases, and is inflexible and prone to ossification.
Apple's gesture handling API lives in a completely different environment.
But I generally agree with you. It's up to client/toolkit to handle complex gestures. However, even Apple abstracts pointer movement and scrolling on input level, and that abstraction includes inertial scrolling. Rubber band effect doesn't really interwine input with UI logic (it can easily be entirely encapsulated in the widget itself) and for other gestures you're going to use some gesture-specific API anyway. The scrolling inertia is a function of the input, so the proper place to calculate it is on the OS side, not in the client/toolkit - it can be in toolkit only when the toolkit itself is a part of the OS. You don't have such toolkit in the GNU/Linux land.
Have a Thinkpad X1 yoga, can confirm that this test works on Windows 10 but does not on standard Ubuntu linux. It's something which annoys me regularly, but one get's used with it, especially if one doesn't sit in front of a Mac daily ;-)
This is just improper handling of an inertial scroll and zoom in applications, not something that OS deliver. On Mac the issue has been known for much longer and most applications adopted the proper API to detect that.
I'm using default Ubuntu on a very cheap Lenovo Ideapad and it passes this test. Additionally, the touchpad works almost as well as my Mac, other than one significant annoyance: double finger right click is difficult, because it has a tendency to scroll the window as I try to press down, meaning I miss the thing I'm trying to right click.
The touchpad drivers and input stack have come a very long way in Linux, if (BIG IF) you're running well supported hardware.
A simple test which Macbooks pass, but Windows and Linux laptops fail: fling scroll down a web page, then press Cmd/Ctrl+W to close the tab before the fling scroll has stopped moving. On Macs this works correctly; everywhere else, it acts as though you're spinning an old-style wheel mouse while holding Ctrl, and zooms in repeatedly.