The last widget we need in our GUI framework

Поділитися
Вставка
  • Опубліковано 16 гру 2024

КОМЕНТАРІ • 5

  • @cryptonative
    @cryptonative День тому +2

    Sometimes I get happy about this GUI framework like I’m the one who builds it lol

  • @tobeypeters
    @tobeypeters День тому

    Multi-Select items work?

  • @vk-hm6te
    @vk-hm6te День тому

    you say that you hate every other GUI framework in the notes, but what don't you like about imgui specifically?
    or is it just wanting to make ur own thing for the sake of making ur own thing which i can totally respect

    • @sphaerophoria
      @sphaerophoria  День тому +5

      I think its just that guis are complex beasts. Theres a lot of surface area required to be a reasonable generalized framework. This automatically comes with complexity and a lot of effort spent on learning the ins and outs of a specific framework. Tradeoffs have to be made, and with so much stuff. eventually a different tradeoff has to be made then the one i would make
      With imgui I just struggle with putting things where I want, styling things the way I want, the way it uses labels under the hood can be confusing, its easy to misuse and get runtime errors, I dont know how to write my own custom widgets, I have to use null terminated strings, i end up writing a non immediate mode gui ontop of an immediate mode gui, no accessability, etc. etc.
      Now a lot of this stuff is easily resolved. I believe a refusal to read docs, or try very hard to gain context, results in an unfair judegment. I dont think theres anything wrong with imgui, but im also not happy when using it
      I do not think what I am doing is better, but it behaves the way specificall i expect it to, and i enjoy working on it

    • @DoctorGester
      @DoctorGester День тому

      @@sphaerophoria in our game I made my own imgui framework which solves some of the issues you mentioned:
      1. After UI code runs there is a layout pass which actually positions the elements instead of using a cursor system. So we have auto sized containers (from sizes of children), % sized containers, alignment, etc. For inputs basically previous frame layout is used.
      2. Instead of having low level primitives like rectangles and whatnot we instead have a concept of elements which have their own “render” code. So if there is a complicated UI element we don’t have to express it in our layout engine, we can just drop down to the renderer and write any code based on UI bounds provided by layout.
      I feel like that fixes lots of issues I had specifically with dear imgui