roots/log.txt at main · printfdebugging/roots · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
*log.txt*

--------------------------------------------------------------------------
@printfdebugging                           Thu Aug 13 12:47:58 PM IST 2026

             TODO: REIMPLEMENT THE FONT RENDERING PIPELINE ~
- |https://github.com/harfbuzz/harfbuzz/issues/6131|
- |https://harfbuzz.github.io/harfbuzz-hb-gpu.html|

--------------------------------------------------------------------------
@printfdebugging                           Wed Aug 12 01:03:05 PM IST 2026

                        RENDERING MULTIPLE LINES ~
- I need abstractions for that. For a renderer which just stores the
  visible quads, I would need a reLayout function of some sort & that
  means I need some abstractions around the harfbuzz code for
  re-shaping the lines..

- Created a `struct Editor` to store the editor state & a `struct Layout`
  to store the layouting/relayouting/shaping logic, though most of
  that is yet to be moved to `layout.c` functions.

- I now face the same problem as before, `layout.c` functions need
  access to the editor object and vice-versa & when we add the
  renderer to the mix, everything accesses everything else. So I would
  need some kind of wrapper object, but I wonder if that would lead me
  down the abstraction hell (I just came out of).

  |https://github.com/printfdebugging/editor|
  |https://github.com/printfdebugging/engine|
  |https://github.com/printfdebugging/external|

- Thinking more about it, I realized that I was treating the file
  boundaries (editor.c/layout.c) as a hard wall which the objects
  cannot cross, but the `Layout` object doesn't exist in vacuum, it's
  editor's layout. So it should be more like editorReLayout than
  reLayout.. >c
        void editorReLayout(struct Editor *editor); // good
        void reLayout(struct Layout *layout);       // bad
<
- The file boundary might help decide how much of the state should be
  accessed and in what way (readonly/read-write).

--------------------------------------------------------------------------
@printfdebugging                           Fri Aug  7 12:51:42 PM IST 2026

- i should have a log file in the project itself. it does not make
  sense to have it outside the project as then i have to juggle
  between repositories and sync things in my head about what i did the
  last time and what to do next.

- with this here, i don't have to write a blog about things, devs can
  just read this file and know what's going on.

vim:ft=help