"You can have "explicitly persistent state" without needing a library to store it for you. You can just store "blah" in a variable in your own renderer, instead of asking the library to store it for you and then storing a reference to it"

Why is this such a new idea to the IMGUI converts? It's called *data binding*. It's been around for a very long time in the RMGUI world. Technologies like WPF make it explicit and indeed are designed around it.

But the main issue for me with IMGUIs is that they're a complete and utter mess once you get beyond a certain level of complexity. The real problem here is that some developers are lazy and they don't want to learn how to use or develop a proper RMGUI library. There is nothing more to it than that!

Quote:Original post by Burnhard
Why is this such a new idea to the IMGUI converts? It's called *data binding*. It's been around for a very long time in the RMGUI world. Technologies like WPF make it explicit and indeed are designed around it.

Data binding is like a step towards the power of IMGUI, but it doesn't go all the way.

Quote:But the main issue for me with IMGUIs is that they're a complete and utter mess once you get beyond a certain level of complexity. The real problem here is that some developers are lazy and they don't want to learn how to use or develop a proper RMGUI library. There is nothing more to it than that!

This is pretty hilarious to me. Two hours ago you were googling for examples of IMGUI, and now you're reporting back to us on your experience with using it in complex projects?

But I'd still ilke to hear you justify these claims...

I'm looking at sample code and then transposing the concepts onto projects I've previously worked on. To me it looks like a throw-back to the 1970's.

Quote:Original post by MoundS
No it doesn't. That's a common misconception with IMGUI. There was a lot of discussion on the first page about how to associate state with IMGUI widgets.

I think the real misconception is that an API can only be one or the other. If what you're proposing is an IMGUI which transparently persists elements of widget state, then what you're talking about is an immediate mode facade over a (at least partially) retained mode implementation.

Quote:Original post by apatriarca
Well, in my opinion an RMGUI should manage the GUI state and the event dispatching logic itself (so no updateGUI function in the application code). If it's the application who manage the state each frame (the GUI don't change or display without explicit user interaction), then it's immediate mode. I can be wrong obviously.

Obviously the application has to update the widget's state occasionally, regardless of your UI paradigm. For example, the text displayed in a current health widget is going to get updated somewhere. Of course, you could do this in an RMGUI using an observer pattern so the UI update isn't explicit, but that's getting ahead of ourselves and obviously not a fundamental mechanism of such a UI.

Quote:Original post by apatriarca

if (doWindow(ui_state, INVENTORY_ID, "Inventory", ..., event)) {    handle_inventory_update(ui_state, event);}

Okay, and if we continue the chain of program logic down we'll end up having a big switch statement based on what event it is, that forwards the details further along to an even more fine-grained bit of update logic. An event-based system avoids all that by just letting you bind your logic directly to the event that triggers it, and then the library handles everything for you; no calls to handle_inventory_update, no need to figure out which event it was and keep passing it along, it's all direct and transparent.

Quote:Original post by MoundS
You can have "explicitly persistent state" without needing a library to store it for you. You can just store "blah" in a variable in your own renderer, instead of asking the library to store it for you and then storing a reference to it. And with an IM interface, if you need "blah" to change from frame to frame, you can replace "blah" with a call to a function that returns different results depending on its inputs. That's not so easy in RM. Like you said, they're RM for performance reasons, but this makes them harder to use, not easier.

Of course you can. But the question is, if we're talking about state that only the renderer cares about (e.g. the position of a window for the GUI), then why on earth would you want to? It's just one more thing for the library user to take care of that the library could easily just handle behind the scenes.

Quote:Original post by Burnhard
I'm looking at sample code and then transposing the concepts onto projects I've previously worked on. To me it looks like a throw-back to the 1970's.

Well, a lot of people look at sample code and come away with stuff that is irrelevant to IMGUI. This is how these misconceptions get started. Some of us have been trying to set the record straight in this thread, but we can't help clarify things for you if all you do is through out shallow accusations and insults.

I see nothing here that amounts to a paradigm. What I do see, however, is the potential for a lot of cyclometric complexity. A game GUI can maybe get away with things like this because compared to LOB or scientific applications (for example), their interfaces tend to be trivial.

Quote:Original post by Shinkage
I think the real misconception is that an API can only be one or the other. If what you're proposing is an IMGUI which transparently persists elements of widget state, then what you're talking about is an immediate mode facade over a (at least partially) retained mode implementation.

I didn't say you couldn't have both in the same API. OpenGL is a good example of a library with both. I was just correcting you when you said the library user would have to manage the state with an IM API, cause that's not true.

Quote:Of course you can. But the question is, if we're talking about state that only the renderer cares about (e.g. the position of a window for the GUI), then why on earth would you want to? It's just one more thing for the library user to take care of that the library could easily just handle behind the scenes.

Again, a library with a purely IM API can associate state with widgets "behind the scenes", without the library user knowing or caring. I don't know why you keep bringing this up as a supposed weakness of IM APIs when I just explained that it's not true.

Quote:Original post by Burnhard
I see nothing here that amounts to a paradigm. What I do see, however, is the potential for a lot of cyclometric complexity. A game GUI can maybe get away with things like this because compared to LOB or scientific applications (for example), their interfaces tend to be trivial.

Again, your statements are meaningless without a justification. Why don't you try telling us what property of IM APIs leads you to this conclusion?

One of the concepts behind an RMGUI is that the user interface represents a transformation of the underlying model - a presentation layer if you like. For that reason the model knows nothing about the GUI. In theory, assuming a real-time system, the model will continue to work if the GUI is completely removed.

But from what I'm seeing with IMGUIs, the model needs to know about the GUI because it has to explicitly pass gui-type state to its components (enabled/disabled state for a button being a trivial example). If the component does not know what state it's in, then that state has to be stored elsewhere. So, where do you store it? If you store it with the IMGUI component then where is the conceptual difference between the IMGUI and the RMGUI? There's a structural difference (you don't like OO and you can't be bothered to build a robust observer model). If you store it elsewhere, you're already breaking one of the supposed advantages of using IMGUI in the first place (no state). Except the difference is that the GUI state is no longer stored close to the component that uses it. We're peddling backwards and passing by a couple of decades of good OO practice in the process.

It seems to me that IMGUI techniques are an excuse to be lazy and suffer from a kind-of conceptual confusion. That's my considered opinion.

Quote:Original post by MoundS
I didn't say you couldn't have both in the same API. OpenGL is a good example of a library with both. I was just correcting you when you said the library user would have to manage the state with an IM API, cause that's not true.

Again, a library with a purely IM API can associate state with widgets "behind the scenes", without the library user knowing or caring. I don't know why you keep bringing this up as a supposed weakness of IM APIs when I just explained that it's not true.

Let's me restate it another way. Tell me what you think of this claim: all sophisticated IM libraries are essentially RM libraries accessed through an IM facade.

That is to say, the user accesses them through a seemingly immediate-mode API, but, internally, advanced IM libraries manage state in essentially the same way an RM library would. Whether they encapsulate the state is irrelevant really--it can be stored as a variable that the user puts somewhere or that the library puts somewhere, it doesn't matter, because the library is the only thing that actually manipulates it.

This is why I'm claiming that the debate is actually event-based vs. polling-based, not IM vs. RM.

EDIT:

Quote:Original post by Burnhard
So, where do you store it? If you store it with the IMGUI component then where is the conceptual difference between the IMGUI and the RMGUI? There's a structural difference (you don't like OO and you can't be bothered to build a robust observer model).

This is precisely my point. The kind of sophisticated IMGUI libraries being proposed as sufficiently functional to provide a complex user interface are conceptually no different from RMGUI libraries.