How ready is this?

[Zauberklavier]

I'm thinking of using this for work for a prototype of a thing. I'm wondering if Azul is ready enough to be used for things that may be used in a production-ish-like setting atm or if it's a heavy work in progress with no assurance of stability, incomplete features and all the rest that comes with growing up a project. Let me know how it is. Thanks!

[fschutt]

I don't think it's ready yet, the 0.1 release is roughly in a month or two away. You can take a look at the 0.1 project board to see how far certain features are.

There are features that are missing, that I'd consider "necessary" for any non-hello-world app, that should be part:

• Tracking input focus (right now text fields can only be entered if the mouse cursor is hovering over them, because there is no "currently focused" text field). This also needs to track the focus across frames.
• Text selection and inline-block layout (to implement text cursors and document-like layout).
• Scrolling (implemented already, but disabled due to clipping problems)
  • Also needs a programmatic API to programatically scroll divs to a certain state
  • Needs to display scroll bars with overflowing elements, otherwise there's not much use in having scrollable elements if a user can't scroll them
• Multi-window handling
  • This is mostly a problem with OpenGL, since sharing one OpenGL context between multiple windows easily leads to segfaults
  • Needs a better API so that you can seamlessly transition between an absolute-positioned div and a new window
• Drag & drop support like in HTML (with ondragstart, ondragend, etc.)
• Mac & Wayland display issues (right now "cross platform" just means "Windows and X11")
• Dependency issues and webrender bugs (webrender isn't on crates.io yet, webrender has known bugs related to gradients).

That's not to say that Azul isn't useful yet, but I wouldn't use it for a production app yet. Below is a screenshot of the application I'm currently programming using this framework, so I'm trying to verify that the programming model can scale to more complex apps:

However, for example text fields currently just push and pop characters at the end of the string, since there is no "text cursor" yet - since I am writing the app for myself, that works fine, but for a production app, it would be a very bad user experience not to have a text cursor. And of course, this doesn't really scale to thousand-line documents, where you'd need different types of datastructures, not just a string.

So I'd expect the 0.1 version to be released in 1 - 2 months (i.e January / February 2019). I'll do a "release announcement", so you can "watch for releases only" on this repository if you want to be notified.

[Zauberklavier]

Alright, got it. I'll have a look again at that time then. Thanks.

[fschutt]

Hm, I'd leave this open for now, because I get this question a lot - usually people don't take a look at the project board, only at the issues, so I'll leave this issue open until the 0.1 release, for better visibility.

[OtaK]

Hey, I'm also thinking of betting on azul (I already have a lot of experience with Conrod, but hey, I like Azul's design and underlying concepts, so I want to give it a try) for a production app, and I'd be super open to contribute back on the issues we'd fix. Would that be a thing for you or not?

[fschutt]

@OtaK Well, the issues right now are fairly managable, the main problem is that they sort-of depend on each other. Ex. I can't implement drag & drop support without implementing multi-window handling first (because during the dragging, the element needs to be rendered in a seperate window, so it depends on multi-windowing). I can't re-enable scrolling without solving the clipping situation first, I can't publish parts of the API without solving dependencies in webrender first, etc.

And at least for now, I have lots of time to work on these internals - it's faster for me to implement these things on my own, rather than to coordinate PR merges. However, if you want to help: develop widgets (or at least try to)! For example, try creating:

• a calendar widget
• a slider
• a checkbox
• a tree view
• a ListView
• a dropdown menu

Take a look at the widgets/table_view.rs on how to structure these kinds of components. Or try:

• fixing the table view to correctly select cells and allow input to the correct cells
• using xml-rs to parse XML and output a DOM, as described here - useful to create GUI builders and hot-reloadable DOM elements later on
• refactoring azul/layout.rs and text_layout.rs as well as widgets into their own crates

This would probably help more than trying to mess with internals (which currently break the API every 24 hours) - plus you'd learn how to use azul in the process. As it is right now, the 0.1 release would be done without any widgets (just releasing the "core" library, and widgets are then added in 0.2). But someone has to write standard widgets at some point, so that's something you could help me with.

[OtaK]

I guess before thinking of making full-fledged widgets, the elementary building-block views need to be made I think (eg: React Native's FlatView, addressing the common use case of long item lists that need to be only partially redrawn on scroll to save memory and CPU). Our project will have a completely custom UI so commonly-used widgets won't be much of use to us, building blocks will be much more useful.

That's a task I can afford to do since I'll do it anyway ¯_(ツ)_/¯

I'll start working on the said project at the beginning of January so I (or members of my team at @YellowInnovation) will be in touch here.

[fschutt]

(eg: React Native's FlatView, addressing the common use case of long item lists that need to be only partially redrawn on scroll to save memory and CPU).

That already exists in azul, it's called an IFrameCallback. This is how the table demo is implemented (since tables are infinitely large, after all) - the callback gets called with the desired size (after layout is done), then the DOM can adjust itself to however large the desired size is.

So if you have 100000 elements, you can make an IFrameCallback, which will then be called with a size of let's say 100 x 200 px, then you can add event listeners to On::Scroll and calculate what items need to be rendered on the screen.

[antonok-edm]

@fschutt It might be a good idea to open some issues with good first issue tags for newcomers. I think a lot of the Rust community is really interested in this project and could provide a lot of value, even with just simple tasks like adding new CSS property parsers. Sure, the inner workings aren't stable yet, but it takes time for a new contributor to get up to speed with the basics anyways.