________________________________________________________________________________
Hello HN! SixtyFPS founders here. We're two engineers who started this project ~6 months ago because we love good APIs and good toolkits that boost overall productivity. We'll be around here to answer questions.
At this point, the product is still in a very early alpha stage, but we are eagerly looking forward to your feedback on technical features as well as on a scalable business model.
Our short term goal is to get involved in a paid project that would require a GUI frontend and where we could make use of this project. If you have any recommendations, or if you know of any such project, we would be happy to hear from you.
Congratulations on the project!
The description mentions targeting embedded applications. What's the definition of embedded in this context? I see "several hundred kilobytes of RAM" mentioned - What's a minimal configuration likely to look like?
Just trying to get a feel for the typical embedded application that you'd be targetting. Most of the embedded work I do is with <= 64kb RAM, which I'm guessing is not your target.
It might be helpful if you could perhaps contrast the product with existing (similar?) libraries such as as LVGL[1], uGFX[2] etc.
[1]
[2]
Hi ddeck!
We need to make our description a bit more precise - and we're working on comparisons. In terms of pure RAM usage (as opposed to ROM) in our experience the display resolution contributes a lot to what's left (unless there are dedicated frame buffers). So if you mention <= 64kb RAM, what kind of displays are you typically dealing with?
Generally I think we're aiming a little above LVGL/uGFX in terms of configuration, but also with with a much richer UI / features.
>_So if you mention <= 64kb RAM, what kind of displays are you typically dealing with?_
Typically displays with integrated SRAM. To give an example, a recent project used a 480x320x16-bit display and an MCU with 64kb SRAM. The display/drawing buffer took 38kb of that (i.e. 1/8 of the display).
Cool! I’d say that’s the very low end for us, but we think that it should be possible to create decent UIs also for such configurations. It would require additional work for us to target that right now but we’d be happy to take that offline. Drop us an email at info@sixtyfps.io please if you’re interested:)
How does this relate to Qt? I see that both founders worked for Trolltech and your other reply says SixtyFPS uses Qt styles on desktop (all Qt styles or just the ones shipped with Qt?) so clearly there's a close connection there. Does it build on top of Qt or is it a replacement, and if it is a replacement is it source / binary compatible?
The software is not built on Qt. The compiler and runtime is written in Rust (Qt is C++), the renderer is a lightweight GLES 2.0 renderer and winit is used for window creation and events.
The runtime’s API is available as plain C++ API (only depends on C++ standard library), JS api in node (via neon) and Rust natively (simply a crate). It’s generally rather lightweight in terms of its surface. Instead the focus is on our compiler generating API for the input design files, to make it easy to manipulate properties or feed data models into the UI.
We’re internally using QStyle calls to produce images of controls when selecting that kind of styling at compile time, but that’s entirely encapsulated. The style you see in the wasm demos for example is entirely done using GLES accelerated primitives (such as SDF based anti-aliases rectangles).
Can the native widgets be used instead of the Canvas widgets in the browser hosted view?
The definition of layout is nice, but handling state changes is still imperative. Is there a way to have values update without having to explicitly respond to signals?
If you mean the native browser widget, this is currently not planed. The browser view is just a way to preview the result, but the real product is meant to be used natively without a browser.
On the desktop platform, we can make use of a native style (using the styles from Qt in the current implementation)
As for the handling of the state change, they are not imperative. The values update automatically as the property changes.
(For example the text of this button changes when you click it:
https://www.sixtyfps.io/editor/?snippet=%0Aimport+%7B+Button...
)
Got it. Can you show an example of modifiying the button label outside of the button click? I am curious how you would modify values outside of the scope of the event handler.
In the following example, the text is bound to the text of a line edit:
https://www.sixtyfps.io/editor/?snippet=import+%7B+LineEdit+...
Is that the kind of example you were looking for?
That is great. Thanks!
Can this work on the Remarkable Tablet? And other EInk Screens? I'm not sure how exactly I can get this to compile for an armV7 Architecture.
I believe the only way to build apps for Remarkable is using QT:
https://github.com/canselcik/libremarkable
We have instruction on how to build for arvV7:
https://github.com/sixtyfpsui/sixtyfps/blob/master/docs/buil...
As for Remarkable, I don't know enough about their platform to know if they are open enough to support other toolkit.
But this kind of hardware is totally something we could target.
Any plans for charts? I found this is the big feature (for my case) supported by Qt but not many others.
Really excited to see more competition in this space!
Yes, we have plans for charts.
We are still very early in the development so this kind of feature will definitively come later as there will be need for them.
Good to know, thanks.