Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Raygui – A simple and easy-to-use immediate-mode GUI library

github.com

Post reply on HN
Print view View original

71–80 of 117 posts

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#71

Post by modeless »

lolinder wrote: post #66
modeless wrote: post #61

Earlier quoted context omitted.

Immediate mode is a style of API where important state is kept in user code instead of being retained inside the API implementation. For example, an immediate mode GUI checkbox implementation does not store a boolean value determining whether the checkbox is checked. Instead, user code passes that information as a function parameter whenever the UI needs to be drawn. Even the fact that a checkbox exists on screen is…

Jetpack Compose on Android has an API exactly like you describe, but I've never heard it described as an immediate-mode GUI. Is it one, or is there something else that makes a GUI toolkit immediate-mode?

Jetpack Compose is very interesting, but I don't think it's exactly what I described. It explicitly retains a lot of state including a widget tree and event handlers. Although the state is opaque because there is no DOM-like API to inspect it, the user is still required to reason about the retained state and know exactly when and which parts should be invalidated. It provides a lot of "convenience" features for the user to annotate and wrap state which is expected to change so that invalidation can happen semi-automatically. But that results in a lot of rules you must follow which can't be automatically checked or enforced, which ends up being rather complex I think: https://developer.android.com/jetpack/compose/state and https://developer.android.com/jetpack/compose/side-effects

Here's a checkbox in Jetpack Compose with the required state annotation and event handling stuff, which if forgotten or done incorrectly will make the checkbox silently malfunction:

    val checkedState = remember { mutableStateOf(true) }
    Checkbox(
        checked = checkedState.value,
        onCheckedChange = { checkedState.value = it }
    )
And here's a checkbox in Dear Imgui which just uses a plain bool and no event handlers (also note that this includes a clickable text label which would require additional event handlers with Compose):

    static bool foo = true; // could be any bool in the application, nothing special about this one
    ImGui::Checkbox("Foo enabled", &foo)
Here's a great example of how the retained state in Jetpack Compose can confuse people: https://stackoverflow.com/questions/70040541/jetpack-compose...

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#72

Post by nikki93 »

a-priori wrote: post #12

Before you start picking up a library like this, keep in mind that no immediate-mode GUI library I'm aware of (including this one from what I can see in the source code) has support for assistive technologies such as screen readers. To them the whole UI is one big black box, so your program is completely useless to anyone with a wide range of disabilities.

I've been using an immediate mode api that generates html elements in web, so that you do get the things that html offers. I basically have a thin wrapper around http://google.github.io/incremental-dom/ (I'm using it from wasm) -- calling it per frame has actually been reasonable perf-wise.

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#73

Post by ahefner »

panzerboiler wrote: post #65
AbuAssar wrote: post #53

Does anyone care to explain what immediate mode means?

The best explanation is probably the one by Casey Muratori ( https://caseymuratori.com/blog_0001 ). He devised the technique and conied the term in 2002.

Can't imagine he was the first person to use this technique. I'd assume any game written from the point where it was reasonable to continually redraw the screen instead of using incremental repainting would've used such a technique, because it's simply the easiest way to implement random ad-hoc GUIs if you don't have a widget toolkit underneath you (and possibly even if you do).

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#74

Post by jcelerier »

milansuk wrote: post #15
a-priori wrote: post #12

Before you start picking up a library like this, keep in mind that no immediate-mode GUI library I'm aware of (including this one from what I can see in the source code) has support for assistive technologies such as screen readers. To them the whole UI is one big black box, so your program is completely useless to anyone with a wide range of disabilities.

Do operation systems have APIs, so the program can send them what is on the screen? I mean just description like: There is the button with title "Push me" in the rectangle(50, 50, 100, 70), etc. Or are there any "screen reader" libraries?

Yes, OSes have APIs. Another commenter talked about the Mac one, Linux has AT-SPI and Windows has MSAA (historic) and UIA. If I'm not mistaken, they generally are about representing the UI as a tree of items as this is what the accessibility hardware expects / works best with.

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#76

Post by throwaway684936 »

infogulch wrote: post #48
hexomancer wrote: post #41

Earlier quoted context omitted.

All these pixels have to be pushed every frame even with classic GUI. The only difference is that it is usually done by the operating system.

The advantage of a declarative design is that it can be accelerated by the GPU which has a much better scaling computational architecture to serve this need.

Dear-imgui, the most popular and mature immediate mode GUI library, renders with OpenGL/Vulkan/DirectX.

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#77

Post by throwaway684936 »

infogulch wrote: post #40

There has been a recent explosion of immediate-mode GUIs recently, but I'm skeptical that an immediate-mode solution can cover our GUI needs now and into the future. High refresh rate screens are a reality so you only have 3-6ms to render each frame, as well as high resolution screens at 4k-8k. That's a lot of pixels to push with a CPU on every frame. As another comment points out we also need accessibility. I would…

>What is driving their authors to pursue this design?

The fact that it requires an order of magnitude less code to do functionally the same thing as traditional toolkits.

>Why aren't they choosing a declarative design?

Because they aren't trying to build a native, standalone desktop application. Declarative design makes little sense for quick and dirty developer tools that just need to directly view and modify simple data structures.

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#79

Post by mwcampbell »

eliasnaur wrote: post #42
a-priori wrote: post #12

Before you start picking up a library like this, keep in mind that no immediate-mode GUI library I'm aware of (including this one from what I can see in the source code) has support for assistive technologies such as screen readers. To them the whole UI is one big black box, so your program is completely useless to anyone with a wide range of disabilities.

The immediate mode Gio (gioui.org) toolkit has support for accessibility (on Android for now), IME and, recently, RTL text layout. Disclaimer: I'm the author.

I can also report some modest progress on my own work on accessibility of immediate-mode GUIs. I have a branch of the Rust egui library [1] that has basic accessibility on Windows using my AccessKit project [2]. I do have a long way to go to make this fully usable and ready to submit upstream, especially when taking non-Windows platforms into account.

[1]: https://github.com/mwcampbell/egui/tree/accesskit

[2]: https://github.com/AccessKit/accesskit

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#80

Post by elcritch »

999900000999 wrote: post #29
rstat1 wrote: post #28

Earlier quoted context omitted.

Changing attributes of UI elements defined in code vs some XML format is in my mind the same level of effort. button.SetBackground( ) or " /> I see no difference there. EDIT: Ok the main difference I guess would be having to switch files (and thus context) which could be annoying. Plus there's also the non-zero performance impact from having to parse an XML format.

What if you have stacked elements, or elements within elements. In code it's something weird like Box(button( Icon() )))

I prefer the best of both worlds. I've been making a YAML like widget syntax in code using an immediate mode GUI written in Nim. It let's me write things like:

    Horizontal:
      box 10.WPerc, 100, 8.Em, 2.Em

      Button:
        text: fmt"Clicked4: {self.count:4d}"
        setup: size 8.Em, 2.Em
        onClick: self.count.inc()
https://github.com/elcritch/fidget/blob/devel/tests/basicwid...
Post reply on HN