36 ms·

This looks cool, but I don’t do a lot of GUI work. Why would one use this as opposed to Qt?

by avidphantasm 4y ago

fpiazza 4y ago
rapid development/prototyping
- bombolo 4y ago
  But it's faster to use a QList<Whatever> than having to do the same in C (repeat for all the non GUI classes that Qt brings in).
  - cshenton 4y ago
    Not faster to integrate it into a build system or compile it though.
    - bombolo 4y ago
      C++ is most certainly slower to compile… it's no problem to build it. Anyway usually the consensus is that it's worth to save human time increasing compilation time. Otherwise nobody would use Rust instead of C
M4v3R 4y ago
QT is a huge dependency that you have to bundle with your app. This is tiny in comparison. Also probably easier to prototype with.
flohofwoe 4y ago
License issues aside the typical use case is that you want to integrate the UI with an existing 3D renderer (e.g. you have a 3D engine, and want an UI overlay for tooling and debugging). 'Bring your own renderer' UI frameworks like Nuklear or Dear ImGui are perfect for this use case. With 'traditional' UI frameworks like Qt, WPF, GTK... this is a massive PITA and even if it's possible would add an incredible amount of bloat. ...and then there's also the convenience of writing immediate mode UI code. Personally, I would never want to go back to event-/callback-/signal-driven UIs.
- synergy20 4y ago
  will immediate mode keep the cpu active thus not power saving friendly?
  - 0x0203 4y ago
    Immediate mode UIs tend to be more practical in applications where you're updating the entire screen every frame anyway. If your application is going to be mostly static anyway, a retained mode UI will probably better serve your needs, and also be easier on power.
  - tomovo 4y ago
    You can pause your main loop when there is no input or animations that would require a redraw. That saves a lot of CPU when the app is idle. You need to run on mouse moves if you want hover effects though.
0x0203 4y ago
In addition to what others have said, they are different types of GUI systems. As an immediate mode UI, the logic behind what gets drawn to the screen in Nuklear runs every frame, and it draws/updates the entire screen every frame. A retained mode UI like QT draws elements once when they need to be updated, and they get left there until an event occurs that requires something change. So immediate mode UIs like Nuklear and Dear ImGUI, tend to be more appropriate for rendering the UI elements of games and other programs that already draw/update the screen each frame. Retained mode tends to be more useful for traditional "desktop" like applications where interacting with the standard toolkit widgets serves the primary purpose of the program. Of course there are many ways of blurring the lines and using either for both, so this isn't a hard and fast rule, just a rule of thumb.

This looks cool, but I don’t do a lot of GUI work. Why would one use this as opposed to Qt?

fpiazza 4y ago

rapid development/prototyping

bombolo 4y ago
But it's faster to use a QList<Whatever> than having to do the same in C (repeat for all the non GUI classes that Qt brings in).
- cshenton 4y ago
  Not faster to integrate it into a build system or compile it though.
  - bombolo 4y ago
    C++ is most certainly slower to compile… it's no problem to build it. Anyway usually the consensus is that it's worth to save human time increasing compilation time. Otherwise nobody would use Rust instead of C

M4v3R 4y ago

QT is a huge dependency that you have to bundle with your app. This is tiny in comparison. Also probably easier to prototype with.

flohofwoe 4y ago

License issues aside the typical use case is that you want to integrate the UI with an existing 3D renderer (e.g. you have a 3D engine, and want an UI overlay for tooling and debugging). 'Bring your own renderer' UI frameworks like Nuklear or Dear ImGui are perfect for this use case. With 'traditional' UI frameworks like Qt, WPF, GTK... this is a massive PITA and even if it's possible would add an incredible amount of bloat. ...and then there's also the convenience of writing immediate mode UI code. Personally, I would never want to go back to event-/callback-/signal-driven UIs.

synergy20 4y ago
will immediate mode keep the cpu active thus not power saving friendly?
- 0x0203 4y ago
  Immediate mode UIs tend to be more practical in applications where you're updating the entire screen every frame anyway. If your application is going to be mostly static anyway, a retained mode UI will probably better serve your needs, and also be easier on power.
- tomovo 4y ago
  You can pause your main loop when there is no input or animations that would require a redraw. That saves a lot of CPU when the app is idle. You need to run on mouse moves if you want hover effects though.

0x0203 4y ago

In addition to what others have said, they are different types of GUI systems. As an immediate mode UI, the logic behind what gets drawn to the screen in Nuklear runs every frame, and it draws/updates the entire screen every frame. A retained mode UI like QT draws elements once when they need to be updated, and they get left there until an event occurs that requires something change. So immediate mode UIs like Nuklear and Dear ImGUI, tend to be more appropriate for rendering the UI elements of games and other programs that already draw/update the screen each frame. Retained mode tends to be more useful for traditional "desktop" like applications where interacting with the standard toolkit widgets serves the primary purpose of the program. Of course there are many ways of blurring the lines and using either for both, so this isn't a hard and fast rule, just a rule of thumb.