Rust-Tailored Slint GUI Toolkit Adding Python API

[shmerl]

Weird indeed. For a toolkit, having a GPL license is probably a deal breaker for some projects and royalty free license is some kind of custom one and doesn't sound like a real FOSS license.

Qt licensing isn't perfect but it's usable. This one - doesn't seem to be practical to even consider.

[nadro]

I think it would be better to use LGPL (or MIT) instead of GPL for libraries. I like GPL for application software, but I dislike it for libraries.

LGPL (especially v3) isn't good choice for libraries, because this license is incompatible with Google Play and App Store, so you lose iOS and Android platforms. Only MIT, Zlib and similars are fine.

[anda_skoa]

LGPL (especially v3) isn't good choice for libraries, because this license is incompatible with Google Play and App Store

If that is true it would be extremely hypocritical by both vendors given that the main browser on either platformshas been derived from KHTML/WebKit which is LGPL licensed.

[mmstick]

S76 said they hesitated between Iced and Slint but ended up picking Iced because it was more advanced at the time, and very straightforward to bind to libcosmic, but that they liked Slint too, and considered it as a potential second backend for libcosmic.

Not quite. Part of the reason we chose iced is we prefer building applications with TEA (The Elm Architecture). Another reason would be the desire to have a native toolkit from top to bottom in Rust without a QML-ish language layer inbetween. And if a business wants to build an application that's not GPL, we'd like to support that as well.

[mmstick]

I think it would be better to use LGPL (or MIT) instead of GPL for libraries. I like GPL for application software, but I dislike it for libraries.

For Rust libraries, MPL 2.0 is better than LGPL. LGPL's static linking clause makes it virtually no different from GPL for Cargo projects. MPL 2.0 permits static linking and also applies its copyleft licensing on a per-file basis. So you can use MPL 2.0 source code in a non-MPL project without needing to relicense your code that links to it.

[Quackdoc]

Sounds cool but their licensing situation is somehow more annoying than even Qt’s, so I sense a lot of projects will simply ignore this and use Iced instead if they want a pure rust toolkit. System76 picking Iced has given it a lot of clout.

their licencing situation is mostly fine IMO, the "mostly free" license is a little to strange? for my liking, but I think a lot of people will still be fine with it. For instance they say "Desktop programs" but they do define it afterwards which would include mobile systems like android/IOS since android and IOS phones are "General purpose computers" now. Embedded use here are things like IoT, management systems for say traffic light infrastructure, control boards for various electronics, home automation panels etc. (Unless the home automation panel is a simple browser connected to say home assistant which is not uncommon).

It's oddly worded, but in the end the licence IS clear enough that it shouldn't pose issues to anybody wanting to use it, and their terms for the free to use are quite fine. I suppose some people may find issues with the below terms, but I don't see any issues myself for either paid or free software

You may distribute the Software as part of an Application, modified or unmodified, provided that You do all of the following:

(a) Display the AboutSlint widget in an "About" screen or dialog that is accessible from the top level menu of the Application.

(b) Display the Slint attribution badge on a public webpage, preferably where the binaries of your Application can be downloaded from, in such a way that it can be easily found by any visitor to that page.

(c) You may not remove or alter any license notices (including copyright notices, disclaimers of warranty, or limitations of liability) contained within the source code form of the Software.

[Vorpal]

Michael you said desktop focused and now also android. You forgot they also already do embedded and Wasm. So really a bit of everything.

[babali]

Not quite. Part of the reason we chose iced is we prefer building applications with TEA (The Elm Architecture). Another reason would be the desire to have a native toolkit from top to bottom in Rust without a QML-ish language layer inbetween. And if a business wants to build an application that's not GPL, we'd like to support that as well.

What is financing iced?
A risk for a business is when the library you're using becomes unmaintained.
That risk is lower when there's a business supporting the library.
What kind of income is provided to iced's devs?

[Steffo]

What is financing iced?
A risk for a business is when the library you're using becomes unmaintained.
That risk is lower when there's a business supporting the library.
What kind of income is provided to iced's devs?

On GitHub it states: "The development of Iced is sponsored by the Cryptowatch team at Kraken.com"

[ssokolow]

their licencing situation is mostly fine IMO, the "mostly free" license is a little to strange? for my liking, but I think a lot of people will still be fine with it. For instance they say "Desktop programs" but they do define it afterwards which would include mobile systems like android/IOS since android and IOS phones are "General purpose computers" now. Embedded use here are things like IoT, management systems for say traffic light infrastructure, control boards for various electronics, home automation panels etc. (Unless the home automation panel is a simple browser connected to say home assistant which is not uncommon).

It's oddly worded, but in the end the licence IS clear enough that it shouldn't pose issues to anybody wanting to use it, and their terms for the free to use are quite fine. I suppose some people may find issues with the below terms, but I don't see any issues myself for either paid or free software

Even if I were OK with QML-ish layers (Rust+PyO3+Python+MyPy(strict-mode)+PyQt/PySide is already an insufficiently compile-time correct way to reconcile demands for QWidget APIs and memory safety and even KDE's Kirigami can't seem to get past creating uncanny valley UIs when used to replace QWidget-based KDE UIs), I don't like license phrasing that mandates the existence of a "top-level menu bar". I tend to write little utilities where, at most, they need a toolbar with maybe four buttons and an as-you-type search field in it... if that. (I've written plenty of things where the only menu of any kind is a context menu and/or tray icon menu.)

I design my UX first, then pick the tool that makes it as easy as possible to implement and maintain... and Slint is in the rather unique position of taking itself out of the running for legal reasons in addition to technical ones.

Hell, given the comparatively sparse selection of widgets, talking about top-level menu bars in Slint feels like putting the cart before the horse. If I want to write something complex enough to need a menu bar, even Qt Quick, which has a massive head start and more funding, hasn't managed to sufficiently catch up to QWidget or non-libadwaita GTK. (StackView is so young it didn't make the cut for Kubuntu 20.04 LTS, Qt Quick is still missing a tree view, which I seem to remember being standard in Windows since at least 1995, etc.)