Hacker News Reader

Comment by Kelteseth | Hacker News Reader

Nice to see that Qt finally gets some competition! The pricing alone is a no-brainer. Now the only thing I'm missing from the demos is smooth scrolling :)

View on HN

If you target desktop only probably Qt license (LGPL 3.0) is easy to use even in commercial projects. The problems comes if you want to target embedded, mobile platforms especially iOS or require some of their GPL modules (e.g. Charts, Data Visualization)

Otherwise Qt is probsbly much more mature project and already has unofficial rust bindings

The current main problem is that Qt often releases new modules under GPL and commercial only licenses. For example, the new Qt GRPC implementation and then it is all or nothing. Qt commercial would force us to essentially buy two licenses because we have a second app that acts as a third party dll loading app. These dlls often crash and thus we moved them into a dedicated app we could simply restart, but Qt license would force you two buy two licenses only because they talk to each other. So, no thank you Qt we will stick with LGPL for now, and move to something else in the future. See my blog post "Current Issues With The Qt Project - From The Outside Looking In" [1].

[1] https://kelteseth.com/post/20-04-2023-current-issues-with-th...

I think you have misunderstood the Qt licensing model when you say that you need two Qt licenses if you are building two separate applications?

The commercial licenses are a) per developer and b) per distributed device (if you distribute your software as part of a device), there is no per application licensing requirement.

> An application using Qt Commercial must not communicate with any another application using Qt LGPL-3.0 or Qt GPL, if both applications run on the same device. This is more restrictive than GPL.

https://embeddeduse.com/2023/01/06/using-qt-5-15-and-qt-6-un...

The context there is "combining commercial and free open-source Qt licenses"; if you are using either commercial or open source licenses exclusively, there are no such restrictions.

Not to diminish Slint authors work, but it is still far from being Qt competition, given the current state of accessibility, IDE integration, or graphical tooling for UI/UX designers.

Disclaimer: I work for Slint

Indeed we are actively working on all of those topics:

Accessibility support in Slint is improving. We just merged the initial AccessKit integration into our winit backend -- https://github.com/slint-ui/slint/pull/2865

IDE integration - our VSCode extension is pretty stable these days (https://slint.dev/get-started#vscode) and we also support integrating into other IDEs via LSP (https://slint.dev/get-started#other-ide)

Graphical tooling for UI/UX designers - our current prototype https://slintpad.com needs more work to become an easy Drag n'Drop editor for UI/UX designers -- but we are on the right path to achieve that :)

Slint is already a viable alternative to Qt, as evidenced by users actively choosing us over Qt. While Qt is more mature in many areas with its two decades of development and large team, Slint is already good enough for some use cases. And as a young framework, we naturally strive to improve.

By the way, when it comes to IDE integration, our VSCode extension and LSP server, which includes live preview, put us on par with Qt's.

Sorry but that isn't the same thing, you're even reckon that is only some use cases, not all of them.

Using VSCode is hardly comparable to QtEditor alongside Qt Design Studio.

So yeah it might be a viable alternative to those that aren't even aware of what a full installation of Qt brings in the box.

While I don't doubt Slint will eventually reach that level, we are comparing 1.0 release with 6.5 and related tooling.

By the way, madnirua's answer was more in line with the reality and it was appreciated.

Disclaimer: I work for Slint

Thanks. We have a lot of users who are migrating from Qt/QML to Slint.

The smooth scrolling part -- is that for the wasm binary or for a native application?

Wasm in Firefox.

I can't find it now, but I remember looking at slint a few months back and finding out that native widget support on the desktop required QT. Is this not true?

Qt is only needed if you want native looking widgets. Otherwise, another style will be used for widget, which does not look native. In the future, we plan to have native backend using the native API, which will allow native widgets without using Qt.

Reference: https://github.com/slint-ui/slint/blob/master/docs/install_q...

Reply on news.ycombinator.com