SixtyFPS 0.1 Released As A Rust-Focused Graphical Toolkit

[phoronix]

Phoronix: SixtyFPS 0.1 Released As A Rust-Focused Graphical Toolkit

For passionate Phoronix readers around the Rust programming language, SixtyFPS is a new graphical toolkit offering focused on Rust but also supporting C++ and JavaScript...

https://www.phoronix.com/scan.php?pa...1-Rust-Toolkit

[Ironmask]

> SixtyFPS is GPLv3-licensed but with a commercial license option.
Oh, so it's useless. Good to know.

Isn't it lovely when a project makes itself untouchable for the sake of politics?

[zeehio]

> SixtyFPS is GPLv3-licensed but with a commercial license option.
Oh, so it's useless. Good to know.

Isn't it lovely when a project makes itself untouchable for the sake of politics?

They also have an "ambassador license", like the commercial but free. They grant it on a case by case basis and requires that you mention in the docs that you use the framework, among other things.

[tobias]

Isn't it lovely when a project makes itself untouchable for the sake of politics?

It allows for unlimited open source/free software use and strongly encourages commercial entities to get a commercial license atbthe same time.

Qt used the same approach before it was bought by Nokia and suddenly had unlimited funding. So this licensing model has shown to be able to bring in the resource needed to build a cross-platform UI library.

I think it is a great choice:-)

[Sonadow]

If it still needs Qt, then it is not a true full-fledged graphical toolkit.

[moltonel]

If it still needs Qt, then it is not a true full-fledged graphical toolkit.

Qt is just one of SixtyFPS's rendering engines, mainly intended to bootstrap a platform while the native engine matures on that platform.

[sh4nks]

It's great to see that for once Qt is used instead of GTK.

[kpedersen]

Qt... So what the project is saying that they are still 100% dependent on C++ and the Rust is basically a "safe" sprinkling on top of layers of potentially memory unsafe code.

Annoyingly Rust is currently such a dependent language. I suppose this is a toss up between safety vs a mess of dependencies.

Hopefully one day a language will appear where we can shed dependencies *and* have safety.

[dremon_nl]

I think druid (https://github.com/linebender/druid) has a great potential to become the Rust GUI library. Not quite there yet and none of other GUI frameworks are. We use currently wxWidgets with a bit of custom C++ bridge code which works pretty well across Linux, Windows and macOS. Great library, easy to make a custom build, I wish the wxRust is reanimated from the dead.

From my experience Qt is ok to use in the projects like KDE where it is essentially a part of the entire OS but for the standalone distributable applications (and especially non-C++ ones) it's a major PITA because it's way too bloated packaging every possible functionality in one huge framework. You have to use their official way of installing it along with account registration, maintenance tool and deployment tool in order to get everything working, it's like a bloody XCode or Visual Studio. WebEngine doesn't work with MinGW compiler and has a lot of other issues. Apple M1 support is still in beta so no universal binaries either on macOS. Their custom C++ object model with ownership causes endless segfaults in the event handlers. The list can go on and on.

[nkukard]

Using the word "Sixty" was probably not the best of ideas in being futureproof.