Add:

/** @function canary_script_update
 * @param script
 * @param dt
 */
void canary_script_update (canary_script_t *, float);

Updates occur on a per-script level, not per-panel.

And for hover, select, drag, and deselect events:

/** @function canary_script_on_x
 * @param script
 * @param x
 * @param y
 */
void canary_script_on_x (canary_script_t *, float, float);

Tie these events in through the SDL test harness with the mouse.

Make issue: Implement panel space transposition for SDL test windows

To export from AssemblyScript:

export function update(dt: f32): void {
  // ...
}

export function on_x(panel_impl: PanelImpl, x: f32, y: f32): void {
  // ...
}

Remember to write about these callbacks in the design doc.

Our current unit tests may as well not exist. They only cover initialization and cleanup of draw_list. There need to be more unit tests to provide a safety net during rapid development, especially for script, since it's the point closest to user functionality. On the same note, the script callbacks in panel-api.h must also be tested.

Absolute test coverage isn't too important right now, it's only important that we have ANY unit testing as opposed to none. It won't be difficult a little further on to do proper gcov reporting in CI to get us the rest of the way to full test coverage.

If you have any questions, please ask! Any confusion can be cleared up with better documentation, so that it's easier for other contributors to pick up the design. For this reason, this issue is a good way to become familiar with the existing code.

AssemblyScript/symbols:

@external("", "UiPanel_getWidth")
getWidth(): f32

@external("", "UiPanel_getHeight")
getHeight(): f32

@external("", "UiPanel_setSize")
setSize(width: f32, height: f32): void

C API:

void canary_panel_set_size (canary_panel_t *, const float[2]);
void canary_panel_get_size (canary_panel_t *, float[2]);

Remember to add to README.

It's unnecessary and adds unneeded complexity

- [ ] mdo-utils as a submodule #27

• #32
• what about OpenGL and GLFW?
• test in a virtual machine
• continuous integration

For now, the source code will remain unlicensed. This does NOT place it in the public domain, so I'm explicitly saying here that it's alright to begin contributing, under the mutual agreement that the code will be properly licensed under an open source license in the near future.

The main option I'm considering is the Mozilla Public License (MPL) version 2.0. This is a free software license that protects closed-source code modifications, while not making it too difficult for proprietary developers to integrate it into their own application. I originally considered the LGPL-v3.0, but I decided that the steps that licensing under LGPL requires the application developers to take (dynamically linking, providing a way to modify the librarary) is too harmful to easy integration with other platforms... even proprietary ones, like VRChat or Neos.

@humbletim also suggested licensing each "layer" of the codebase (scripting API, shape primitives, input mapping, etc.) under different licenses depending on the needs for that layer. Personally, I believe that this is too complex, and that it would be too easy for a determined defendant to find loopholes allowing them to get away with acts we never intended if we ever run into any legal issues.

More thoughts and suggestions are welcome and encouraged.

Many variable/parameter names still have the ui_ prefix from before this repository was officially named Canary. This can be abbreviated, i.e. from ui_script to just script and from ui_panel to just panel.

I originally wrote the Vulkan renderer because I'm familiar with Vulkan and I haven't used OpenGL in many years, but this turned out to be a bad idea, considering the simplicity of the renderer. The Vulkan renderer source file is nearly one thousand lines of code already, even using the vk-bootstrap helper library, and will expand even more as I actually make it render draw calls, which is unnecessarily difficult because of Vulkan's complexity.

Porting to OpenGL is dead simple... for anyone familiar with OpenGL. It only has to upload the vertex and index buffers for each draw list, then call a draw indexed command every frame. Vulkan would also need to be replaced with OpenGL in the tests/CMakeLists.txt file.

If anybody would be willing to step up and write a new renderer using OpenGL instead, it would be much appreciated. Please ask if you have any questions.

https://github.com/charles-lunarg/vk-bootstrap
Shout-out to Charles for being the man

wasmtime provides win64 releases that so far have proven fruitful in the interest of Windows Support, however, functionality at runtime needs to be confirmed and interaction with other layers of the engine also confirmed on Windows

mdo_result_t and accompanying functions are clunky and obnoxious to use, mdo_allocator_t is pointless, and mdo-utils as a whole is painful to set up and link properly. Canary would be better off without it.

Unit tests are basically non-existent right now, but I'd like for that to change as soon as possible, and CI is also useful just for ensuring that it cleanbuilds on both Windows and Linux.

I believe that the Wasmtime library target needs to be automatically downloaded and setup by CMake as an interface library, located in lib/CMakeLists.txt. Right now, the (Linux-only) library is included in the source tree, which is a little hacky.

Installing mdo-utils in CI should be pretty straightforward. Checkout the repo, configure with an install prefix, then compile, test, and install. Caching for the install prefix would also be straightforward here, although I don't think that the added complexity is worth it for the compile time improvements. If compile times ever become a problem in CI, then we'll have to set up that caching.

Third-party dependencies can be installed on Windows with vcpkg, or perhaps another package manager like Chocolatey. Dependencies on ubuntu-latest can be installed with apt.

If anyone would like to tackle this, leave a comment, otherwise I'll do it myself when I have the time.