Evaluating OrbTK

(Ellie Fagerberg) #1

From the maintainer of OrbTK:

As erlend_sh mentioned OrbTk (0.3) is inspired by Flutter / React and is based on an ECS library.

Here you can find more information about OrbTk:

OrbTk could be a good opportunity for the Amethyst editor. It’s also written in Rust, uses ECS, should be ? easy to use, you could define a custom theme and it works on many platforms.

OrbTk is based on OrbClient. It uses SDL2 for Window handling and drawing (except of Redox OS, there we uses a custom implementation). But we are thinking about to switch to glutin, but gfx-rs could be also possible. If we reached that point, OrbTk should fulfill your basic requirements.

Maybe there is an opportunity to work together. You could help us to implement a Vulkan based solution for OrbTk / OrbClient and we can help you to implement the features in OrbTk you need to create your editor.

I guess we can reach a version of OrbTk to start with the editor within half a year.

My personal take is that I think this sounds pretty great and I like the progressive approach. My main worry is that we’ll end up spending more time on fixing OrbTK than we will spend on actually creating the editor. There also seems to be a general lack of documentation right now of what can be done with OrbTK which makes it hard to evaluate at the current stage. A quick write up about the current state of OrbTK and how to use it by the maintainers would be very appreciated :smile:

(Florian Blasius) #2

First off all thank you for your interest in OrbTk :slightly_smiling_face:.

The current state
OrbTk 0.3 will be a complete redesign of the code and visual design. It is inspired by functional-reactive frameworks like flutter and React. The base architecture and core components like the CSS-Engine, Render-, Layout- and Eventpipeline are relatively far advanced. But there is still some work to do like the completion of css properties and refactoring to cleanup code and to further improve performance. But it’s still far enough to create custom widgets and views.

Type of widgets OrbTk still provides:

  • TextBlock: read only Text widget
  • TextBox: Text input widget (WIP)
  • Button
  • Center: Layout widget that centers its child
  • Container: Layout widget that draws a box and add padding to its child
  • Column: Layout widget that orders its children vertical
  • Row: Layout widget that orders its children horizontal
  • ScrollViewer: Layout widget that add scrolling to its child (WIP)

The roadmap

  • Documentation (state: in progress)
  • Tests: (state: in progress)
  • Widget template macro to simplify widget creation (state: in progress)
  • Book (state: planned)
  • Info website (state: in progress)
  • More widgets like Menu, ToggleButton, CheckBox, ComboBox, Lists, … (state: planned)
  • Vulkan / OpenGL backend: One point you maybe could help us :wink:
  • Port all Redox applications to OrbTk 0.3 (state: planned)
  • Code editor written with OrbTk (state: planned)

How to start with OrbTk

What OrbTk mainly depends on

  • OrbClient: Used for window drawing and event handling
  • DCES: ECS library created for OrbTk

The cooperation
I think a cooperation between Amethyst and OrbTk should be a benefit for both. Soon I will start with a Vulkan / OpenGL based backend for OrbTk. You can help us with your experience to implement it. This gives you the opportunity to define the feature set the backend should provide. On the over side we can help you to create missing features and widgets in OrbTk you need for your editor. We could also help you / give feedback by creation of the editors frontend architecture, building views and layouts. I’m working as (UX) Software Engineer at Ergosign and I’m a specialist for exactly these topics :wink:. And your feedback will help us to constantly improve OrbTk.

I could also check if one of our UX Designers would be happy to help you, if you want help on the design of your editor. Two of our UX Designers still working on a new default visual design for OrbTk / Redox OS. That could I check independent from a cooperation.

I know a bunch of features are missing, but we are working constantly on it. From my personal point of view we achieve rapid progress. My employer also spent me and an other developer each a day per month to work on OrbTk.
Sure there would be bugs if you start creating the editor with OrbTk. But we will working hard to eliminate these. Because we will port all Redox applications to the new OrbTk we will find and fix some bugs before.

Amethyst and OrbTk are both exciting Rust based projects. We think the possible cooperation of both projects very exciting. I hope you will give it a chance :slightly_smiling_face:.

(Thomas Schaller) #3

One thing I want to bring up early here is how we make things compatible with two different ECS libraries.

The two obvious options are:

  1. Create a core that works completely without ECS and is generic wrt to the data in and output, similar to rhusics / rhusics-ecs.
  2. Use OrbTk from Amethyst and synchronize the state as necessary.

(Ellie Fagerberg) #4

I honestly think this sounds absolutely awesome. As you say, I really think the collaboration could benefits us both in many ways. I especially like the fact that your goal is to have all redox applications be written in OrbTK. Looking through what you guys have right now, I have a few questions however (none of them are that major but I just want to clear things up in my mind :sweat_smile:):

  • Looking at the different examples, the API looks somewhat cumbersome to use right now with a lot of Rc::new(...) and ..Default::default() which I’m not a huge fan of. Is there any chance we could sprinkle some syntactical sugar on it?
  • I don’t quite understand how orbclient operates. Is it just using SDL’s drawing functions or is it based on OpenGL? What are the goals for it?
  • I’m obviously a bit biased on this point being a web developer by day but I’m somewhat concerned I can’t see anything flexbox related. How advanced is your layouting system?
  • How much of the usual CSS do you guys want to implement in OrbTK? Are we just talking the basics or do you want to reimplement webrender? :stuck_out_tongue:
  • How long are you guys estimating it will take until you can start using OrbTK for your own projects?

(Dustin Bensing) #5

To answer your first Question. Take a look at one of the examples widgets line 9 this is the goal by implementing a macro that would generate the Rc::new(...) and ..Default::default() stuff. If this gets to a point where its usable you basically write your layout like you would in Flutter (at least very close to it)

    Row {
        children: [
            Container {
                child: Button {
                    label: "Click me",
                    handler: ButtonHandler {
                        on_mouse_up: || {
                            println!("Button 1 mouse up");
            Container {
                child: TextBox {
                    label: "Insert",
                    handler: TextBoxHandler {}

(Ellie Fagerberg) #6

That is indeed nicer, but I usually don’t enjoy macros in Rust, mainly because of poor support from IDEs. I was thinking if there could be some sort of middle ground with helper functions for the most common scenarios instead?

(Florian Blasius) #7

I’m glad to hear that :grinning:.

To your questions:

  • Orbital is Redox’s Windowing and Compositing System and OrbClient is a client library for it. On Linux, macOS and Windows OrbClient is using SDL2 instead of Orbital. Currently we are using SDL2’s WindowCanvas to draw a window and its pixel buffer to draw pixels on the screen (OrbClient SDL2 line 71). OrbClient also uses the SDL2 event pipeline and convert the events to Orbital events (OrbClient SDL2 Line 319). The renderer of OrbClients provides a function to draw a single pixel and all other render functions like arc and rectangle uses this function (check OrbClient renderer). Our goal is it to replace all SDL2 parts with glutin or gfx-rs. Than we are able to draw 3D objects, can easier provide a wider range of supported platforms like iOS, Android and WebAssembly and I hope it will also help us to improve OrbClients render performance.
  • Our layout system should already be flexible enough to create a layout widget like flexbox :wink:. It’s funny my manager suggested to implement a flexbox like layout for OrbTk :smile:.
  • Mainly we uses CSS for widget styling: colors, sizes, padding, fonts, … . All other stuff like layouts are handled and defined in Rust. What could be also imagined that we implement some CSS animation features later.
  • The Calculator is still based on OrbTk 0.3. Next projects could be follow in the next weeks. More widgets we create, more projects and projects parts could be ported.

You’re welcome to ask me more questions. Also how we could coordinate a cooperation :wink:.

(Florian Blasius) #8

That would be possible. I’ve been playing around with some alternates for fun. I could deepen my research.

(Florian Blasius) #9

We handle now the project management of OrbTk on our Issue board. There you could check what is going on and what is in the pipeline. Feel free to create additional issues or comment the existing ones :wink:.

(Ellie Fagerberg) #10

Awesome! Are you on our Discord yet? It would be nice to have a quick chat :smile:

(Florian Blasius) #11

I’m in :wink:

I’ve you are interested you could also request access to the Redox OS chat https://redox-os.org/community/. There is an orbital channel, where we discuss the most time about OrbTk.

(Erlend Sogge Heggen) #12

Is the plan to make one from scratch or would you be making something like a front end for the xi-editor? I’d be pretty worried about your workload if it’s the former.

(Florian Blasius) #13

There is currently a rudimentary text editor on Redox OS based on the old OrbTk. The plan is to port the old editor to OrbTk 0.3 and to expand its features bit by bit. I play with the thought to use the rsl with the editor. But I have to check if it is possible. Maybe we could thought about using an existing backend like xi for the editor.

The main goal of the editor is to have the possibility to write code direct in Redox. Besides I’ve been dying for this for a long time :wink:.

But my main focus will be always OrbTk and to bring it to level comparably to Gtk+, Qt or WPF as soon as possible. Therefor I’ll spent most of my time.

(Simon Rönnberg) #14

If you’re looking to swap to using glutin or gfx as the render backend I would recommend looking at using gfx-hal directly instead of doing multiple large refactors in a short amount of time :slight_smile:

Either that or abstract out rendering and provide multiple render backend implementations, or allow users to build their own.

(Erlend Sogge Heggen) #15

In the wake of Flutter’s v1.0 release I’ve seen an inordinate amount of people praise its hot-reloading. Is this a planned feature in the near term for OrbTk as well?

(Florian Blasius) #16

We want to port OrbClient to gfx-hal. I saw that it provides also an abstraction for WebGL, if I’m not wrong this means we could use OrbTk than also with WebAssembly. And cargo still provides hot-reloading for WebAssembly, I’ve tested it by my self.

Either way hot-reloading is a planned feature of OrbTk.

(W. Brian Gourlie) #17

Is this provided by cargo, or by WebPack/Parcel? I always thought it was the latter.

(Florian Blasius) #19

You could add a wasm target:

rustup target add wasm32-unknown-unknown

and then run

cargo build --release --target wasm32-unknown-unknown