OKAY.
the moment i have dreaded for so long has come.
sxpp is implemented and nearly complete.
nudl is implemented and nearly complete.
now i'm going to implement tukan in nudl.
nothing is done yet.
i'm not going to use dear imgui.
instead i'm going to bootstrap visual editing from structured text editing (similar to our 2015 IDE prototype written in Lua, see screenshot).
the first thing we do is solve text rendering. we need to display *a lot* of fixed width text.
took a breather today for reorientation, you probably noticed.
checked that i haven't forgotten anything.
we're definitely going to go the text IDE route first: start as a humble editor for nudl code. then add texty features. more texty features.
but then the first in-editor written slider widget to control float values. the limitation is that the widget can not appear in its own source code - but that's fine.
from then on it's mostly obvious i hope.
i picked a few old classic computing bitmap fonts as possible bootstrap fonts and generated C arrays to embed them directly into the main executable.
worked over my "text-mode deluxe" plans and figured out a pipeline.
https://git.sr.ht/~duangle/texts/tree/master/item/ponder/graph_editor.md
idea here is that only 2 pages are needed for classical text. more pages needed for graphical widgets, drag & drop animations, smooth scrolling, etc.
this is the source code for this program (without shader), and the generated data flow
per-glyph style (RGB, inverted) is now also translated
looks like it's time to do actual text logic now.
nudl's logic/reactive nature leads to variables updating only when a dependency has actually changed.
left is the relevant listing, right is a video of the resulting runtime behavior
(the slow window performance is due to x11/vulkan/SDL internals. it's much faster on wayland.)
been mulling over whether to do structured text editing over an AST like structure or something more plain, and plain text won out, because it's just ubiquitously more useful.
so how do we get widgets in the text window? like this:
got loading text -> gap buffer done, which involves a UTF-8 -> UTF-32 conversion.
also added a bunch of other editing operations.
https://git.sr.ht/~duangle/tukan/tree/master/item/src/gapbuffer.n
what's not clear yet is how to build the interface for this. particularly "read value then change value" moves against DAG scheduling (change value then read value).
took a while to figure it out but now i have something nice to query, observe and change cursor offset. it's done with a virtual table (not the same as a virtual table in C++).
a very emotional experience, this.
as long as i struggle to express a concept and find bugs on top, i'm feeling like "perhaps all this was a fatal mistake and i am a deeply flawed human being"
but then the bugs are fixed and i also end up with something elegant and feel instant relief and redemption.
and repeat.
which is no way to be. it's nerve wracking.
we are now rendering a text document from a gapbuffer to the GPU. it's a direct stream-and-parse, there is no line analysis or anything.
presently, it happens only when the window is resized, because we're not interactive otherwise.
@lritter one byte per pixel is a bit wasteful isn't it? ;)
I did the same thing in sokol_debugtext.h (actually extracting the font data from various home computer ROM dumps), but with 1 bit per pixel. Fits into 2 KByte per font for 256 chars:
Looks like this when rendered:
@lritter ...just remembered that in a much older version I also used the more visual 'one byte per pixel' storage format :)
https://github.com/floooh/oryol/blob/master/code/Modules/Dbg/private/debugFont.cc
I am not very happy with imgui, as it is not declarative enough for me... but it does allow me to target audio pllugins, Android, etc.
maybe... this needs an abstraction
LR
Andre Weissflog
d@nny disc@
Gerard Braad
rich