39 pointsby teleforce8 hours ago4 comments
  • cardanome6 minutes ago
    Immediate mode GUI is the way to go.

    Retaining state is a pain and causes bugs. Trying to get fancy a la react and diffing the tree for changes makes not sense. That was a performance hack because changing the DOM in JS used to be slow as hell. You don't need that.

    Just redraw the whole thing every frame. Great performance, simple, less bugs.

  • dazzawazza9 minutes ago
    > While it’s far from perfect, writing it taught me more about UI systems than I ever would have learned by sticking to established solutions alone.

    This is a great attitude to have. Keep up the great work.

  • giveexamplesan hour ago
    rectcut is a good API for layout if you have a fixed viewport (eg eink display)

    the API is a very simple one where you slice parts off an initial Rect. the only feature it provides is that it tracks (x, y, h, w) for you.

    it doesn't work well with intrinsic sizes - it's more of a top down, fixed size thing.

    • spiffyk31 minutes ago
      I actually use a very similar paradigm successfully in a game [1] whose (immediate-mode) UI is fully responsive. I allow more operations than just cutting to do that, but the basic idea seems to be the same. The code may look like a bit of a mess at a first glance [2], but I still find it easier to work with and make it do what I actually want with some very basic vector maths, than with the layout-container rules of most UI frameworks.

      [1]: https://fruitsandtails.fghj.cz/

      [2]: https://codeberg.org/spiffyk/FruitsAndTails/src/branch/main/...

  • mbmproductions5 hours ago
    author here - thanks for posting :D would love to hear any thoughts or questions.
    • socalgal23 hours ago
      At what point do you think you’d give in and use an existing solution?

      I’m going through similar “hell” (my words). I just wanted some simple Ui for WebXR but the dipshits that designed XR for the web fucking threw all the web parts out so you can not just put up a few simple html elements up in XR. You have to write your own UI library from scratch. It’s so mind bogglingly stupid.

      In any case, having to write it, like you I started small and the it quickly ballooned because even simple things get complicated quickly, all the while I’m cursing under my breath there is a perfectly unable system but TPTB chose not to offer it >:(

      • mbmproductions2 hours ago
        existing solutions for my specific use case were limited, i intentionally wanted something barebones so that I could hack at the raw surfaces / display buffers to cut corners for performance. one part learning experience, one part stubbornness.

        WebXR sounds like a different beast entirely. do you have to write your own rendering backend in WebGL for that?

        • socalgal2an hour ago
          Webgl or webgpu, but for ui you can just draw to a canvas and copy that canvas into webgl/webgpu. That means you can easily iterate on the ui system in 2d with mouse input similar to what you’ve been doing in python

          But, as an example of similar complexity. I hacked together the first Ui I needed. It was 6 buttons and a slider. Then I realized I needed two more Ui panels and started to write more real Ui classes to abstract stuff out and, it just starts getting more and more complicated.

          A slider needs to “capture the pointer”, meaning as you drag it, if to drag past the end of the slider and the pointer is now over another widget the events should still go to the slider. It’s not hard to implement, it’s just frustrating for me that I don’t actually want to write it. I just want to make my panel and if I could just use html id be done. Instead I’m spending my limited free time making this ui system. I don’t have that much and would be much further along in my actual goals except for this road block