>The primary motivation for this package is to enable the use of Swift when writing GNOME apps, for all the reasons outlined above
The only problem I have with such projects is when they are unmaintained, in various stages of immaturity, and have little adoption (vicious circle).
You find them, they promise exactly what you need, and then you fell into issue after issue in practical use (*).
It would be amazing if there was (perhaps this is or will be) well maintained bindings for Swift/Rust/Go and co for Gnome.
* Yes, it's open source and you can fix some of the issues yourself. Doesn't mean you have the know-how or time to fix all of them, especially when there are lots of things to fix or features missing. Ideally a big community must exist, so that each can just work on or fix a small part and the problem still get lots of fixes/improvements incoming, as opposed to "fully replace the single overworked maintainer yourself".
This. Over the years I've seen so many cool projects aiming to ease native desktop UI development, but most became unmaintained at some point, for what I am guessing is due to the difficulty and complexity associated with actually making this work in practice. It is less sexy, but a solid language binding to the existing libraries is likely the more practical and maintainable way to go
After so many years of seeing cross platform stuff come and go I can’t help but think it can’t be done well enough for mass adoption. It just has too many gotchas that make things feel out of place on every platform in different ways. At least outside my first demo app territory.
The only thing that really seems to be succeeding is web stuff like Electron, which usually throws the baby out with the bathwater and does its own thing of emulating the web (itself, basically) instead of trying to feel perfectly native.
Idk I've been developing with Qt for idk, 15 years now, it's stable and keeps chugging along with constant improvements. And is used in more than enough mass-adopted apps, e.g. Telegram
This is spot-on. Though I think the interesting thing here is just demonstrating that you _can_ build this kind of thing at all and a cross-platform-SwiftUI-like framework isn't a pipe dream.
For production use-cases at this moment in time, I'd probably lean towards using Swift's pretty-good C++ interop functionality to thinly wrap a more battle-tested C++ library.
I don’t get these kinds of complaints about open source projects..
Seems like you guys want either 0% or 100% ..that something either not exist at all or perfectly does everything you ever wanted without any effort or cost on your part.
You want a process and commitment, a clear distinction between which things are first-class and which things aren't. If this is just an experimental project that may not go anywhere, fine. If this is meant to be the new way of writing Gnome apps, displacing Vala, and they're going to support it in LTS releases for at least the next n years, fine. But it should be clear which it is.
It doesn't have to be 100%, but nobody wants to invest a ton of time/energy into a project just to hit a wall a little ways down the road when something at the very core of it breaks or becomes unmaintained. Of course it would be nice for users of such projects to help and contribute, but this isn't always practical. Not because the users are being entitled assholes, but often times they aren't even the same skillsets, and I think this is especially true of some of this complicated, low-level UI stuff. If I'm a user of PyGObject writing GTK apps in Python, I'm not necessarily capable of contributing to the underlying C bindings, even if I wanted to be helpful.
This dynamic presents a legitimate problem for pretty much any open source project that aims to abstract away something very complex to enable more developers to use it. Any project that does this is going to have more developers relying on it than are capable of contributing to it.
You should never feel entitled to continued development of a project you don't contribute to, and you should always assess the community around tools you want to use in order to make good decisions. But this doesn't mean you can't be super frustrated if something you rely on goes dormant. I personally avoid using any library/package that doesn't appear to be very active, but nothing is foolproof. Even a seemingly healthy project die can fairly quickly in certain circumstances.
I think the discussion is valid, I don’t see it as complaining. People can create cool things, but you have to weight whether that can actually be used in practice. After all, until AI start writing software for us, maintaining a project takes time and effort. No one wants to see it go to waste.
>Seems like you guys want either 0% or 100% ..that something either not exist at all or perfectly does everything you ever wanted without any effort or cost on your part.
Or, you know, that's a strawman, and we just want something that exists and is mature, like hundreds of other FOSS people are fine with, as opposed to basing our code on something that is immature, has little community, and will probably be abandoned when the authors get bored with it.
Which has nothing to do with it being "100%" or "perfectly doing everything we ever wanted".
The only problem I have with such projects is when they are unmaintained, in various stages of immaturity, and have little adoption (vicious circle).
You find them, they promise exactly what you need, and then you fell into issue after issue in practical use (*).
It would be amazing if there was (perhaps this is or will be) well maintained bindings for Swift/Rust/Go and co for Gnome.
* Yes, it's open source and you can fix some of the issues yourself. Doesn't mean you have the know-how or time to fix all of them, especially when there are lots of things to fix or features missing. Ideally a big community must exist, so that each can just work on or fix a small part and the problem still get lots of fixes/improvements incoming, as opposed to "fully replace the single overworked maintainer yourself".