Three finger drag is also a killer feature for me, and unfortunately that very feature highlights a key difference in the way macOS and the Linux desktop are developed [1].
To get three-finger drag to work, you need a gesture right? So you report the issue to libinput. Libinput looks at it and says "well, this is more than just a gesture", and says "this should be implemented in the compositor". Now, this is desktop Linux, and now you need to get at least three compositor projects to agree that 1) yes it's their problem, it isn't a libinput problem and 2) to actually fix it in their compositor. Sigh. And what's more - this isn't even the end of the problem! This is just for dragging windows! Now you also need to get this for arbitrary drag and drop actions like moving text or stuff in your file manager, so now you also need fixes in your UI toolkits. There's at least two for that you'll need as well. Pile on top there that most maintainers in this web have never extensively used a Mac, and don't even understand why this is something people want in the first place. This kind of stuff is very hard to fix on the free desktop.
If the same discussion happens for macOS, at worst some manager who is the boss of both of the squabbling teams will get mad, tells them that the UX here is more important than your technical squabbles and orders them to sit down and fix it. To be clear: I completely understand how these layers of abstraction work on the free desktop, and this is much harder to fix. But I sure wish there was a stronger incentive for these abstraction layers to fix these cross cutting concerns.
I have some hopes pinned on recent progress for this [2].
I think a lot of this is especially bad right now because we're trying to unwind a lot of the bad system architecture that was imposed by X. A lot of maintainers are finding that they need to do things themselves that X used to do for them.
There are other issues on the horizon - if input preferences are no longer held in X (because that's not libinput's job and it shouldn't be) but are pushed up to gtk/glib/qt/kde, does that mean that whenever I use a kde app in gnome that it uses some random key-shortcut defaults rather than what's in my gsettings? That seems to be the case right now.
Also, I owned a multitude of MBPs through the years, from the first Intel Al-books around 2005 through to my last MBP, a 2015 model. I was heavily invested in the platform because it seemed like that manager you describe had the same sense of taste and the same engineering intuitions as I do. Well, that all ended with the butterfly-switch keyboard. It was a sad, angry, bitter divorce, but I left Apple and will probably never buy another MBP. The butterfly switches are gone, but I know now that that manager lacks the integrity and professionalism to manage the platform. It was more important to fluff Johnny Ive's ego.
That opinionated manager can giveth, and she can taketh away.
> If the same discussion happens on macOS, at worst some manager who is the boss of both of the squabbling teams will get mad, tells them that the UX here is more important than your technical squabbles and orders them to sit down and fix it.
That strikes me as rather optimistic. I mean, yes, in theory a company does have enough overarching management that it can force coherent action, but... the "Microsoft" in https://laughingsquid.com/organizational-charts-for-tech-com... is a thing. Maybe Apple is still sufficiently centrally-driven that it works there? Historical accounts certainly make it seem like they've managed their share of infighting, but I suppose by the time they went to market it tended to be dealt with.
When did switching workspaces become four-finger? Meaning you can't use the three-finger option? Catalina? I have a MacBook Pro on Mojave and the trackpad accepts three-finger for the gesture of switching workspaces and the Magic Mouse has an option for two-finger.
Same here. When I first saw that feature 2014 on my MBP back then I thought Linux will have that soon. Man was I wrong....But actually it should work, as I can e.g. tap 3 fingers on a link now here on a XPS to open it in a new tab.
It's not just moving windows around. It's all drag operations. Highlighting text in a webpage or console, dragging files between finder and other apps, dragging UI controls like sliders.
To get three-finger drag to work, you need a gesture right? So you report the issue to libinput. Libinput looks at it and says "well, this is more than just a gesture", and says "this should be implemented in the compositor". Now, this is desktop Linux, and now you need to get at least three compositor projects to agree that 1) yes it's their problem, it isn't a libinput problem and 2) to actually fix it in their compositor. Sigh. And what's more - this isn't even the end of the problem! This is just for dragging windows! Now you also need to get this for arbitrary drag and drop actions like moving text or stuff in your file manager, so now you also need fixes in your UI toolkits. There's at least two for that you'll need as well. Pile on top there that most maintainers in this web have never extensively used a Mac, and don't even understand why this is something people want in the first place. This kind of stuff is very hard to fix on the free desktop.
If the same discussion happens for macOS, at worst some manager who is the boss of both of the squabbling teams will get mad, tells them that the UX here is more important than your technical squabbles and orders them to sit down and fix it. To be clear: I completely understand how these layers of abstraction work on the free desktop, and this is much harder to fix. But I sure wish there was a stronger incentive for these abstraction layers to fix these cross cutting concerns.
I have some hopes pinned on recent progress for this [2].
[1]: https://bugs.freedesktop.org/show_bug.cgi?id=89999#c20
[2]: https://gitlab.freedesktop.org/libinput/libinput/-/issues/29...