Support for more programming languages other than python?

[rubyFeedback]

I filed this under Question because this seems to cover most of it, but it is also a suggestion,
so ... not solely a question only.

I looked on the homepage and python code is shown:

from azul import *

css = """
    .__azul-native-label { font-size: 50px; }
"""

From this I infer that python code works for azul too, and even (!)
CSS. Which is great.

I am looking for alternatives to gtk but also libui (which, at the least,
works on windows out of the box in ruby) - but I am looking to want
to use ruby. gtk has one advantage in this regard in that it offers
bindings via gobject-introspection.

How difficult would this be to add for ruby, and what would be necessary?

I assume it is a "finite" problem set as python already works on azul (I
assume so from the example). Could someone perhaps add a short
document explaining what would be necessary for adding more language
bindings? This is one area where libui excelled - tons of people created
bindings in the respective language.

Unfortunately my C/C++/Rust knowledge is very limited. I am quite ok-ish
with ruby, I can even use python too just fine, but preferably I would want
to use ruby since I wrote so much code in the last ~20 years in this
regard already. All my commandline stuff for instance. Right now I use
either the www or ruby-gtk3 for add-on GUIs to the commandline
code.

[rubyFeedback]

So this is also a bit a request for documentation. A separate file
would be nice, linked in from the main README. It's also ok
if this is outdated. Better to have outdated documentation than
no documentation.

[fschutt]

How difficult would this be to add for ruby, and what would be necessary?

You need to build a "C extension" for Ruby (or any other language). Azuls entire API is defined in a JSON file: https://github.com/fschutt/azul/blob/master/api.json

The JSON file describes the entire public API, data types and functions, including documentation. The Python binding code (and the C and C++ headers) are then auto-generated from the build.py file:

azul/build.py

Lines 1200 to 1201 in e0bcb55

	# Generates the azul-dll/python.rs file (pyo3 bindings)
	def generate_python_api(api_data, structs_map, functions_map):

The build.py file itself generates a 20000-line python.rs file: https://github.com/fschutt/azul/blob/master/azul-dll/src/python.rs. I am using PyO3 to generate the bindings for Python, you'd have to use something like Helix or raw Ruby-FFI. There are also guides for binding Ruby to Rust: https://www.cloudbees.com/blog/improving-ruby-performance-with-rust, but you just need to Google that. I recommend building a small hello-world extension first and testing that helix works.

The python extension bindings generate a lot of extra code, which is why they are behind a --feature=python-extension feature-flag. Overall it should be relatively easy to generate the necessary Rust code, if you know how to parse a JSON file and output text to a file (with 20 years of experience, I think you should be able to handle that).

The only special thing with managed languages is how to pass function callbacks into Rust. For that, there are special "patches" to create a PyFunction object here: https://github.com/fschutt/azul/tree/master/api/_patches/python, especially how to invoke python function objects from Rust, see the layout_callback.rs file. I just adapted the PyO3 examples: https://pyo3.rs/v0.14.5/python_from_rust.html. Same thing would have to be done for Ruby.

The CSS string is a feature of PyO3 (converting a Python String into a Rust String). Python creates the string object, passes it into a Rust function where it gets converted into a Rust String, then the CSS parser parses the string.