Hacker News Reader

Comment by diffeomorphism | Hacker News Reader

So in qt or gtk on macos it is implemented at the toolkit level?

I’m not quite understanding the question (probably due to my lack of English skills) but if you’re asking if it’s implemented in the macOS equivalent of Qt/GTK(which probably means AppKit), yes AFAIK it’s true.

Some apps on macOS are not written using AppKit but are cross platform apps which use either the QT or GTK toolkits even on macOS. The question is asking how inertia scrolling is handled on macOS for applications which use these toolkits instead of AppKit.

Badly, which is why cross-platform applications stand out like a sore thumb on MacOS

Well, I'm not sure (as I always erase GTK/Qt apps as soon as they become useless), but what I remember is that they do handle window changes (b.c. event propagation is handled in AppKit), but the inertia doesn't feel right. I think there are apps that do implement inertia, and there are also apps that don't implement inertia. Both feels wrong.

> Both feels wrong.

That was my question. So macOS has one blessed toolkit working nicely and everything else feeling "wrong". So this has nothing at all to do with being "fragmented" but simply says "apple has one good toolkit and lots of bad ones".

Well, I won’t call GTK/Qt as a macOS toolkit... but in Linux world, both are used similarly. I think that’s the difference.

It’s not handled there at all. Qt likely uses NSScrolledView underneath, but Java/Swing and GTK feel foreign even if they look the same (which they don’t, with different levels of unsubtlety).

Reply on news.ycombinator.com