If you are serious in supporting this project, a way to prevent that is by sponsoring the project via the authors Patreon or if he applies for GitHub sponsorship. This has worked for projects like the Zig Programming Language, etc.
This used to be a problem in the past but not anymore. I would really like to finally see Rust's answser to having a non-Electron cross-platform GUI library.
Some charge money for developing products, and it leads to sustained development. Some call those commercial products, and have a tendency to work well. The source can still be open, as open source doesnt have to be free. But many dont want to pay for products, want them free, and at the expense of others.
When it comes to using only GTK+ for the cross-platform use-case, it already has the Cocoa and Win32 back-ends built in via the GDK, which that API is abstracted to GTK+ so that work is already done. It maybe enough to solve the Rust GUI problem on Win/Mac/Linux, however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings.
I think the author might have to support GTK+ theming options to counter this issue then? If not then perhaps using GTK+ for Linux and using the win32 and cocoa crates separately and abstracting that might be something worth looking at?
however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings.
It is not worse than electron in that respect ;). But some small Rust Gtk+ utility that I have for personal uses a whopping 7564KB of resident anonymous memory.
Personally, my issue with Electron is that, in practice, it is hugely inefficient. The up-side to Electron, IMO, is that it doesn't try to straddle the uncanny valley of native GUIs. In GTK, usually everything _looks_ like a normal GUI, but behaves/looks just a little (or, often times, a lot) bit different than what is expected.
Comments
These projects always stop (or make no useful progress) at the really difficult/tedious work of abstracting cocoa and win32 API.
If you are serious in supporting this project, a way to prevent that is by sponsoring the project via the authors Patreon or if he applies for GitHub sponsorship. This has worked for projects like the Zig Programming Language, etc.
This used to be a problem in the past but not anymore. I would really like to finally see Rust's answser to having a non-Electron cross-platform GUI library.
Some charge money for developing products, and it leads to sustained development. Some call those commercial products, and have a tendency to work well. The source can still be open, as open source doesnt have to be free. But many dont want to pay for products, want them free, and at the expense of others.
Isn't this abstraction already done (at least partly) by gtk ? (Or are you thinking of another level of abstraction - otherwise gtk would be enough ?)
When it comes to using only GTK+ for the cross-platform use-case, it already has the Cocoa and Win32 back-ends built in via the GDK, which that API is abstracted to GTK+ so that work is already done. It maybe enough to solve the Rust GUI problem on Win/Mac/Linux, however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings.
I think the author might have to support GTK+ theming options to counter this issue then? If not then perhaps using GTK+ for Linux and using the win32 and cocoa crates separately and abstracting that might be something worth looking at?
Not only will it look out of place, but last time I checked, GTK has zero accessibility (e.g. with screen readers) on Windows or Mac.
however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings.
It is not worse than electron in that respect ;). But some small Rust Gtk+ utility that I have for personal uses a whopping 7564KB of resident anonymous memory.
Personally, my issue with Electron is that, in practice, it is hugely inefficient. The up-side to Electron, IMO, is that it doesn't try to straddle the uncanny valley of native GUIs. In GTK, usually everything _looks_ like a normal GUI, but behaves/looks just a little (or, often times, a lot) bit different than what is expected.
No gtk draws its own widgets.