Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by IshKebab on Tuesday April 27, 2021 @01:41PM
(#26959070)
I hope they solved the spaghetti code nature of QML (basically everything can refer to anything else; you end up with children that have dependencies in the internals of their parents).
Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by tronical on Tuesday April 27, 2021 @01:54PM
(#26959210)
We try hard to avoid that. No magic context properties, good modularity across files (js module concept). Easy to write components. But there is more work to be done.
Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by ogoffart on Tuesday April 27, 2021 @04:20PM
(#26960999)
Yes, we use static typing and everything is statically known within a single file.
This allows to preview each control on its own since they don't depends on their parents.
Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by cookguyruffles on Tuesday April 27, 2021 @01:38PM
(#26959043)
A few hot takes:
- Library is under the GPL 3, vastly more restrictive than most existing GUI toolkits
- WebAssembly rendering in Firefox most certainly not living up to the name. I think the slide animations on the print example are managing around 5-10 fps
- Keyboard input / control focus seems absent in the demos. This would also suggest the much more important detail of accessibility also missing
- Compiles layouts to code. Is this really necessary? Visual cortex places severe restraint on how much complexity can go into a UI. Code generation on the other hand says a lot about how painful the dev-build-debug cycle is likely to be.
Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by tronical on Tuesday April 27, 2021 @03:40PM
(#26960489)
Sad to hear that it’s not fluent for you :(
We went for dual licensing (GPL / commercial) in hope of creating a sustainable project.
We do have basic focus handling but the demos don’t really try to show that off - that’s more tailored towards touch based input at the moment. But we’d love to have a17y, full desktop like tab focused etc.
Regarding the compilation: the ability to live preview individual components or the entire design and seeing changes being applied on the fly (we have an interpreter for that) speeds the ui dev cycle a lot. Give it a try :)
Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by lalaithion on Tuesday April 27, 2021 @01:11PM
(#26958718)
This is pretty cool, and it probably works very well on other platforms, but the compiled-to-WASM isn't great. For one, text boxes don't actually focus while capturing input, so my keyboard shortcuts kept firing while I was trying to type into their text box.
Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by tronical on Tuesday April 27, 2021 @03:43PM
(#26960539)
Python should be fairly straightforward to do.
Golang with the interpreter we well, but the RealThing(tm) would be a full code generator and binding to the runtime library. That would be awesome, but a little bit more work.
I quite like Go, it’s simplicity and GC is really convenient.
Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by tronical on Tuesday April 27, 2021 @03:03PM
(#26960034)
Lsp can be used with any IDE, better markup language (static typing, proper module concept), rust and JS APIs, markup compiled to proper C++/Rust AOT, compiler can do asset optimizations (todo) - for example:).
In short: we try to do one thing (UI) and do it well :)
Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by ogoffart on Tuesday April 27, 2021 @04:17PM
(#26960967)
The use of the Qt backend is only temporary to get native style quickly on every platform. In the future, we would use a native windows and mac bckend.
Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by nyanpasu64 on Tuesday April 27, 2021 @01:33PM
(#26958973)
> This release also includes new Rust and C++ APIs to dynamically load .60 files, with the sixtyfps-interpreter crate in Rust, and the sixtyfps::interpreter library in C++. This also allows embedding a component as a QWidget in a Qt application.
in case Widgets and QML and HTML in one app wasn't bad though
Re:SixtyFPS v0.0.6 GUI Toolkit: Now with IDE Support
by tronical on Tuesday April 27, 2021 @03:47PM
(#26960586)
Maybe it could be brought over the top by compiling Qt to wasm and mixing that in. A bit tricky with the emscripten runtime vs wasm32-unknown-unknown target mixing of Rust though ;-).
Jokes aside, we added this embedding because of a specific user need.
SixtyFPS is the first project with a company behind it which uses femtovg, a Rust nanovg port. https://github.com/femtovg/femtovg for rendering. SixtyFPS added WebGL support which lets you run femtovg in the browser https://tronical.github.io/femtovg/examples/index.html.
Recently, femtovg added an experimental wgpu backend which is for now in my fork of the project https://github.com/adamnemecek/femtovg.
Join the femtovg discord https://discord.com/invite/V69VdVu.
https://github.com/sixtyfpsui/sixtyfps#the-60-markup-languag...
- Library is under the GPL 3, vastly more restrictive than most existing GUI toolkits
- WebAssembly rendering in Firefox most certainly not living up to the name. I think the slide animations on the print example are managing around 5-10 fps
- Keyboard input / control focus seems absent in the demos. This would also suggest the much more important detail of accessibility also missing
- Compiles layouts to code. Is this really necessary? Visual cortex places severe restraint on how much complexity can go into a UI. Code generation on the other hand says a lot about how painful the dev-build-debug cycle is likely to be.
We went for dual licensing (GPL / commercial) in hope of creating a sustainable project.
We do have basic focus handling but the demos don’t really try to show that off - that’s more tailored towards touch based input at the moment. But we’d love to have a17y, full desktop like tab focused etc.
Regarding the compilation: the ability to live preview individual components or the entire design and seeing changes being applied on the fly (we have an interpreter for that) speeds the ui dev cycle a lot. Give it a try :)
EDIT: Profiler says CPU-wise the page is 95% idle.
Golang with the interpreter we well, but the RealThing(tm) would be a full code generator and binding to the runtime library. That would be awesome, but a little bit more work.
I quite like Go, it’s simplicity and GC is really convenient.
In short: we try to do one thing (UI) and do it well :)
and sure enough, i was right back in HN after a few clicks. https://news.ycombinator.com/item?id=24786721
in case Widgets and QML and HTML in one app wasn't bad though
Jokes aside, we added this embedding because of a specific user need.