After some trials and tests. The below arch is not going to be very usable. Going to put this into a branch in case I want to redevelop this idea, but there were some major problems:
1. Problems with maintaining two whole systems plus a server remote backend. Not very good for versioning, support and long term consistency.
2. The web editor view would never be consistent with the application output. This is important for gfx oriented applications or games.
3. Alot of complexity needed for data sharing and management. Would prefer a simple db than this sort of mess.
4. Web visuals and their libraries are _huge_ resource hogs (both file an mem) and I want this to be a more lightweight system.
I want an easily extensible system (for developers) but I also need it to be clean and user friendly for people coming into development for the first time. The web view is kinda ok for the second goal, but not really for the first.
The result. I will be building my own gui layer (yeah, I know) which will be a structured lua format that allows for functionality to be built into the gui elements themselves. Think of it like an SVG format with actions that can be applied to any element.
Fixed build editor:
to run ```.\bin\win64\luajit.exe .\tools\build\rbuilder\rbuilder.lua```
This can compile a project into an executable package with resources (which will eventually be a resource bundle). This works in another project I have, I will work to get some example build projects working so this can be used as-is. Some of the widgets and tools have been moved into the engine. This will begin to form the basis of the built-in themable GUI.
Expect incoming updates over the weekend. With maybe a small game as well.
Its been a long time. Life gets in the way as usual. I have been using this toolkit for a number of projects so I wanted to update it. I have built a complete fbp system using it (to be shared later) and I have made a luajit based html rendering engine that is coming along nicely (with the same toolkit).
Obviously this is for win64 atm. And there might be browser compatibility issuse too. If you use Firefox or similar it should work fine, but dont expect miracles :)
The sokol api has been built into dll's (this may change in the future) and it is executed in the best (imho) runtime system there is using its amazing ffi module:
Some of the source files have been modified to support shared libraries a little better and make the binding of ffi a little easier. There are only small changes, but this is kept in this location - do not use as a source for sokol itself.
https://github.com/dlannan/sokol
The build process builds Win, Linux, Mac OSX, IOS but not Android atm. I need to build a shared library mechansim for this to work well. Thus, the build for it currently fails.
## Luajit Sokol
The only provided main luajit binaries are for win64.
To run other platforms, please build luajit for your platform and place in the bin/<yourplatform> directory.
You will also need to modify the paths at the top of the samples lua scripts to match. I will update this to be more friendly in the future (by using ffi.os).
The Wasm part of sokol might not be able to be utilized in this manner. However I do have plans to compile Luajit->wasm and embed sokol generated bytecode. It should be possible, but that is along term goal.
- There are a number of objects that must be created as pointers. In ffi the easiest way to do this is to make an array object of size 1 and this way the handle in lua is a pointer and the object access uses the array indexing.
- No performance considerations have been taken into account. These are almost direct 1 to 1 mappings of the sokol C samples to luajit samples.
- pathing is not yet made friendly (31/10/2024 - It has been improved dramatically. Little more to do.)
