3 ms·
Well the example application seemed fairly solid, well worthy of a screenshot. I would like something like this for some simpler custom tools every now and then
by scoopr 8y ago
Well the example application seemed fairly solid, well worthy of a screenshot. I would like something like this for some simpler custom tools every now and then.
It does seem to exhibit the usual custom rendered app issues. I suppose it is constantly redrawing the screen, as it seems to have constant cpu usage even when doing nothing, so not laptop friendly (though perhaps fixable still).
Some of the widget seem fairly arcane but usable. No keyboard control that I could find. Screens that needed to scroll didn't. Text input is custom, so that will be a source of frustration for many for a long time (lack of cursor control, IME, etc.), likely fine for internal tools for a while.
One thing that was very alien to me was the build tooling and language/runtime. It was easy enough to run the example per the readme instructions, but it is quite hidden what kind is the end product. I eventually found an actual executable of around 4MB (3.3MB stripped), but I'm not quite sure how self-contained that is. Also how easy would it be to link C/Rust lib, so that revery would only be used as the UI layer for something else.
- bryanphe 8y agoHey scoopr! Thanks a lot for trying it out. > It does seem to exhibit the usual custom rendered app issues. I suppose it is constantly redrawing the screen, as it seems to have constant cpu usage even when doing nothing, so not laptop friendly (though perhaps fixable still). Yes, at least when there is an animation active (we redraw the screen in that case). Most event-based apps, though, would only redraw in response to user input or for a temporary animation - our initial demo is constantly animating at 60hz, so maybe not the best performance demo... > Some of the widget seem fairly arcane but usable. Definitely. Still a lot of work needed here. We've had some excellent help from the community getting an initial palette of controls; but still a ways to go! > One thing that was very alien to me was the build tooling and language/runtime. This is great feedback. We should include more details in our README about this. The stack is really Esy [1] -> Dune [2] -> OCaml compiler (ocamlopt) [3]. Then C linker for your platform. > Also how easy would it be to link C/Rust lib, so that revery would only be used as the UI layer for something else. I haven't tried Rust, but C libs are doable with Reason/OCaml's C FFI [1]. In fact, several of the underlying pieces of technology powering Revery (GLFW, FreeType2, Harfbuzz) are used via this FFI [4]. [1] https://esy.sh/ https://esy.sh/ [2] https://dune.readthedocs.io/en/latest/quick-start.html https://dune.readthedocs.io/en/latest/quick-start.html [3] https://caml.inria.fr/pub/docs/manual-ocaml/native.html https://caml.inria.fr/pub/docs/manual-ocaml/native.html [4] https://github.com/bryphe/reason-glfw https://github.com/bryphe/reason-glfw
- nv-vn 8y agoFun fact in terms of the binary: by default OCaml uses static linking for pretty much everything except your libc, so unless something in the stack is doing something weird wrt linking that binary should contain all the dependencies.