Experimenting with automated layout
... discord slowmode kicking in when trying to send multiple attachments
Did another attempt on structuring GUI from scratch. Taking a somewhat retained approach but without any messaging (no event types / routing etc) which seems to be a big contributor to complexity. Structure used is a big Ui context struct that holds state of inputs/outputs as well as stacks of layout rects, clipping rects, mouse interaction regions. Layout methods used are "RectCut" and two custom layout routines used to arrange the buttons in rows / columns. Code screenshot is how the color pickers at the bottom are assembled from more primitive elements. I feel it's reasonably concise while maintaining flexibility.
Starting a few experiments with UI design.
Trying to get the right organization here has caused me a lot of pain. Still not perfect, but it's getting better at least! And if two or more parties are involved in an operation (and you're stubborn enough to not want to have a central location that knows all the things), there is invariably a lot of bureaucracy involved.
Two nasty words I'm liking more and more: Object-oriented (actor model), Retained mode GUI. ~700 lines OpenGL + GLFW, ~1000 lines for the GUI. Effortlessly clean code (for my standards). Nice isolation and extremely generic widget implementations with deferred messaging. All the widgets have a single inbox and outbox, messaging happens strictly on the nesting hierarchy.
some progress on my Lisp from yesterday. Added strings objects/literals, but more importantly: Eval, Quasiquote, Unquote. The important realization is how macros behave exactly like functions, except they receive their arguments unevaluated.
Had another try at programming a small lisp today. I think I finally understand the evaluation process and macros better. Although macros here are not yet usable, it simply evals two times - first time to splice syntactic (unevaluated) args, and then a second eval pass over the resulting syntax node.
Some 2D UI work
Did some more work on my puzzle game. Longer video at http://jstimpfle.de/videos/DqUynavp5j.mp4
Worked on a puzzle designer / game. Also did some work on a WebAssembly port. Check it out at http://jstimpfle.de/projects/puzzle/puzzle.html
Worked on a puzzle piece designer. There are still crashes in the triangulator. Computational geometry is hard work
Worked some more on a toy lisp implementation to better understand lisp. To be honest, I still haven't found what's so great about it. The huge difference is that everything is lists, so it's much easier to make hard to debug mistakes - which I assume does not only apply to writing the compiler but also writing programs in LISP itself.
The quoting rules and name binding schemes are at least as context-dependent and confusing as say, C, must be for a novice programmer. I tried making very few special cases but haven't really found a good way, and Scheme and also @rxi 's
fe both have numerous primitive forms (which need special handling) as well.
Finally took the plunge and started moving all my code to a monorepo. I've decided to define my projects as simple python functions for now that can inspect how the project is built (Compiler/OS etc) and return the set of cfiles, includedirs, linklibs and so on. It feels great so far because I finally can fluently share code between all my projects without copying. No diverging code anymore! I also get a lot of control over my compilation process - I already have included a configuration that targets WASM/WebGL with emscripten. It's all in a single build.py file and the project definitions already outweigh the build logic code. All I'm going to add in the future is checks whether a file needs to be rebuilt.
found an app to record gifs
A little app to combine STL files in tree structures, and move objects around according to their degrees of freedom