ltkx

GUI toolkit for X11 (old)
git clone git://lumidify.org/ltkx.git (fast, but not encrypted)
git clone https://lumidify.org/ltkx.git (encrypted, but very slow)
git clone git://4kcetb7mo7hj6grozzybxtotsub5bempzo4lirzc3437amof2c2impyd.onion/ltkx.git (over tor)
Log | Files | Refs | README | LICENSE

NOTES (2387B)


      1 Maybe use XCheckWindowEvent? - this would eliminate need for hash (could just store window ids in array)
      2 -> Is it okay to block until event found? Loading bars, etc. should still work since control is in another
      3    function (or even thread?) which has to call ltk_update_progress_bar or something similar.
      4 HarfBuzz - need to add option to LTK functions to allow user to choose language system manually
      5 LtkTextSegment - just use array instead of linked list - just need to get actual number of glyphs in advance from hb
      6 Add void* to LtkWidget to hold specific widget instead of doing weird casts to simulate OOP
      7 When the screen size is set differently by the window manager on startup, the original drawing stays on screen - any way to fix this?
      8 Change list of windows to simple array or binary search tree - hash overkill since there usually won't be too many windows
      9   -> maybe optimize for common case of one window so no need to search at all
     10 Fribidi - needs to be run on entire paragraph first; line breaking later - needs to take paragraph dir into account
     11 Should widgets be reference-counted?
     12 
     13 Ideas for text editor:
     14 https://en.wikipedia.org/wiki/Rope_(computer_science)
     15 https://en.wikipedia.org/wiki/Piece_table
     16 https://en.wikipedia.org/wiki/Gap_buffer
     17 LtkTextLine should be abstracted out to be a generic
     18 rope or gap buffer with the glyphs for the characters
     19 also included at all times so they don't get out of
     20 sync. The rendering function for LtkTextLine doesn't
     21 need to know about shaping or anything - different
     22 functions for actually rendering the glyphs just return
     23 an abstract LtkTextLine that can be rendered without
     24 caring about such details. This would easily allow
     25 one file for shaping with harfbuzz, one for just
     26 using the regular kerning with stb_truetype, etc.
     27 
     28 Text editor tags (highlight, etc.) - just store in
     29 linked list or something similar in sorted order;
     30 when looping over characters to draw them, keep a
     31 pointer to the current tag, then change it to the
     32 next one if the end of its bound comes
     33 
     34 Create a version of ltk_fatal that exits the actual program
     35 and creates a "failsafe" error window (just using basic
     36 XDrawString, etc.) to show errors (like index out of bounds,
     37 etc.). Still print the error, of course, in case creating
     38 a window doesn't work.
     39 
     40 Idea: Make interface primarily key-driven; store keybindings
     41 in config so they can easily be configured