Hacker News Reader

Comment by Mayzie | Hacker News Reader

> Flutter is not based on webviews, but is also not using the native widgets but instead rendering custom widgets.

Yeah, I only just realised this after further looking into it today (when I last checked their site, they only had one page introducing the project). They try to spin this from a negative to a positive[1], by saying that they think they can guarantee the Flutter widgets quality and performance compared to native widgets, and it's on them (the Flutter devs) to make sure those widgets are up to date to the look and feel of the platform.

Which to me just seems like trying to solve a non-issue in the first place, not to mention depending on the Flutter developers to ensure their supported widgets remain up-to-date to the platforms standards and not deviate in any way.

[1] https://flutter.io/faq/#does-flutter-use-my-systems-oem-widg...

View on HN

Qt seems to have done a great job of this. There are occasional hiccups when OSX updates the look of their progress bars for example, but it never feels nearly as bad as Java Swing (when it's emulating the host OS) or wxWidgets (ironic, since they use native widgets like react-native).

So it can be done, but I imagine it isn't easy. Qt has years of experience doing it.

Counterpoint: Qt has done a terrible/non-existent job of this for iOS. Qt/QML apps look and feel pretty native on MacOS, and Qt & Qt Quick controls on Android devices look very close to Android native, but they've barely even attempted to implement iOS-looking controls. (It's bizarre how little interest they seem to have in supporting iOS. I don't know if it's because iOS doesn't have the styling APIs they need or what.) There is a third-party framework that partially addresses iOS issues (https://v-play.net/qt), but that's not an ideal solution.

For some applications (including the one I'm currently working on), you can get away with having nearly the same UI on Android and iOS, with just a little extra work to (for instance) give iOS users a more native-feeling navigation experience.

In regards to Flutter, I'm not sure if it's reasonable to expect the Flutter project to do a better job simulating native iOS widgets than Qt has been able to.

The problema is not only the UI and affects Android as well.

For the majority of OS APIs there are no wrappers, beyond of what is available on the desktop + hardware sensors.

So basic stuff like file pickers or asking for permissions aren't even supported.

I tried it once back in 5.4 and gave up on it, going back to Java / C++.

https://bugreports.qt.io/browse/QTBUG-42491

Are you sure that QT is not using native widgets? I always thought QT used native widgets and a quick search [1] seems to confirm this:

> Recent versions of Qt use the native style APIs of the different platforms, on platforms that have a native widget set, to query metrics and draw most controls.

[1] https://en.wikipedia.org/wiki/Qt_%28software%29

Seems to confirm it, but doesn't. What that means is Qt uses the native style APIs to get the system styles (e.g., theme color, highlight colors, default fonts/sizes, etc.), so it can draw controls that look like native controls. But it's drawing widgets, not using native widgets. In many/most cases, users will never know the difference, but it is different.

Blind users definitley notice the difference, because Qt apparently doesn't implement the platform accessibility APIs quite right, particularly on WIndows.

Two anecdotes:

1. The TeamTalk (http://bearware.dk/) voice chat system is popular among blind people. Originally when it was Windows only, it was an MFC application. Then when it went cross-platform, the developer used Qt. But the Qt version was inferior for blind users, so the developer still maintains the MFC version just for them.

2. Rant from a blind programmer trying to develop an accessible cross-platform application with Qt: https://blind.guru/qta11y.html

On every major platform, it's possible for non-native widgets to be accessible by implementing the platforms' accessibility APIs. But Qt doesn't do this very well.

That doesn't confirm use of native widgets. It confirms use of native styles.

iirc it uses native widgets, the problem was that for some time QT used Carbon and stuff like scrollbars looked outdated until they added cocoa support because Apple stopped updating visually carbon

>Which to me just seems like trying to solve a non-issue in the first place

Writing code once is a non-issue?

Reply on news.ycombinator.com