mirror of
https://github.com/slint-ui/slint.git
synced 2025-08-29 14:54:07 +00:00
92 lines
3.4 KiB
Markdown
92 lines
3.4 KiB
Markdown
# Slint development guide
|
|
|
|
The build instructions are in the [building.md](./building.md) file.
|
|
The testing instructions are in the [testing.md](./testing.md) file.
|
|
|
|
## Repository structures
|
|
|
|
### `helper_crates`
|
|
|
|
A set of crates that are somehow not strictly related to Slint, and that could be moved to
|
|
their own repository and have their own version release at some point.
|
|
|
|
### `internal`
|
|
|
|
`internal` contains code that is not meant to be used directly by a user of Slint.
|
|
|
|
#### `compiler`
|
|
|
|
The main library for the compiler for .slint.
|
|
|
|
Nothing in there should depends on the runtime crates.
|
|
|
|
There is a **`test`** subdirectory that contains the syntax tests.
|
|
These tests allow to test the proper error conditions.
|
|
|
|
#### Runtime libraries
|
|
|
|
The library crates that are used at runtime.
|
|
|
|
* **`core`** is the main library. It is meant to be used for all front-ends. Ideally it should
|
|
be kept as small as possible. **`corelib-macros`** contains some procedural macro used by core library.
|
|
* **`backends`** contains the different backend for the different platform, separated from
|
|
core library. Currently there is just the gl backend
|
|
* **`interpreter`** is the library used by the more dynamic languages backend to compile and
|
|
interpret .slint files. It links both against core library and the compiler lib
|
|
|
|
### `tools`
|
|
|
|
* **`compiler`** is the tool to generate the target language (e.g. c++) from the .slint files for
|
|
frontend that have a compilation step and generated code.
|
|
* **`viewer`** is a tool that allow to open and view a .slint file.
|
|
|
|
### `api`
|
|
|
|
Here one find the frontend for different language.
|
|
|
|
### `tests`
|
|
|
|
The integration test that are testing a bunch of .slint with different front-ends
|
|
|
|
See [testing.md](./testing.md)
|
|
|
|
### `examples`
|
|
|
|
Some manual tests
|
|
|
|
## Documentation
|
|
|
|
There are some documentations comments in the code.
|
|
HTML documentation can be generated with something like
|
|
|
|
```sh
|
|
cargo doc --document-private-items --no-deps --open
|
|
```
|
|
|
|
## Rust to C++ bindings
|
|
|
|
We use a rather complex mechanism to expose internal data structures implemented in Rust to C++, in a way that allows us to provide a nice C++ API.
|
|
|
|
As a starting point, we recommend reading the blog entry we published about this:
|
|
|
|
[https://slint-ui.com/blog/expose-rust-library-to-other-languages.html](https://slint-ui.com/blog/expose-rust-library-to-other-languages.html)
|
|
|
|
What this article omits are how we invoke cbindgen and what kind of tweaks we apply on various levels:
|
|
|
|
The C++ library consists of four components:
|
|
|
|
1. The `slint-cpp` cdylib created by `cargo`/`rustc` from `api/cpp`.
|
|
1. The public header files in `api/cpp/include`.
|
|
1. Internal header files generated by `cbindgen`, via `cargo xtask cbindgen`.
|
|
1. The CMake project to tie it all together by invoking `corrosion` to call `cargo` and invoking `cbindgen`.
|
|
|
|
### `cbindgen`
|
|
|
|
The `cbindgen` xtask generates multiple header files for four different modules:
|
|
|
|
1. The types in the core library. This is the bulk of the generated code.
|
|
1. The entry points into the C++ library for creating backends, invoking the event loop, etc. - from `api/cpp/lib.rs`.
|
|
1. The types specific to the Qt backend used by the Qt style, such as `NativeButton`, etc.
|
|
1. The types used by the C++ interpreter API, written to `slint_interpreter_internal.h`.
|
|
|
|
Typically the input to `cbindgen` is within `ffi` sub-modules in the corresponding input crates to `cbindgen`. These `ffi` modules are gated with `#[cfg(feature = "ffi")]`.
|