November 27, 2007
Julio César Carrascal Urquijo wrote:
> Lutger wrote:
>> Another interesting idea is immediate mode gui. It basically means that no or almost no state is maintained, at least as far as the user is concerned. Instead, the gui is recreated as needed. I've been playing a bit with it and it works nicely, but somehow I had some trouble with more complex gui's.
>>
>> Here's a link, the video is worth it imo:
>>
>> https://mollyrocket.com/forums/viewtopic.php?t=134
> 
> 
> What worries me about immediate mode guis is performance. I suppose they are great for building the gui portion of a game or some really flashy app but I don't see an improvement for typical applications where the gui doesn't change unless until it receives some input from the user.
> 
> Just picture a dumb +30 fields form that's using 100% CPU because it is repainting it self every frame.

My guess is that, like OpenGL programs, you don't have to refresh regularly if nothing is happening.  But if something does happen then, yes, you do need to repaint everything.

--bb
November 27, 2007
Bill Baxter wrote:
> My guess is that, like OpenGL programs, you don't have to refresh regularly if nothing is happening.  But if something does happen then, yes, you do need to repaint everything.
> 
> --bb

Well, from what I've seen before they refresh the screen each frame. Even in the video in the OP, the guy says something like: If you don't want some widget painted you just don't paint it.


-- 
Julio César Carrascal Urquijo
http://jcesar.artelogico.com/
November 27, 2007
0ffh wrote:
> 
> Also, I've been quite satisfied with DFL, which is a
> mature solution for Windows and moving towards the Xes.
> 
> regards, frank

X-platform DFL/Entice would be enough to satisfy me GUI wise. I don't need any fancy new features that will be obsolete in a couple years, just a solid, functioning easy to use GUI. :-P

~ Clay
November 27, 2007
On Tue, 27 Nov 2007 01:44:38 -0000, Bill Baxter <dnewsgroup@billbaxter.com> wrote:

> (with a nod to Don ;)
> No, I don't have the perfect GUI.
> I'm just throwing this out as a topic for discussion.  I've yet to find a GUI that isn't tedious to use.  With 2.0 const hopefully nearing completion, and the new closure support in 2.0, maybe it's a good time to dream again about what the ultimate D GUI would look like.
>
> I don't have anything concrete, but I was thinking a bit about some interesting GUI-ish things from Python recently and thought I'd mention them here.
>
> There's a library called "Trellis" [1] that I think has an interesting idea for how to maintain GUI state.
>
> The basic idea is that you define rules rather than explicit event handlers, and execution of those rules is triggered by built-in dependency analysis.  The analogy made on the web page is to a spreadsheet.  When you use a spreadsheet you just say how the values in this cell depend on all the others and then it all gets automagically updated for you recursively whenever any dependency changes.
>
All you need is an updateWindow function.
Perhaps instead of D a suitably enhanced version of make is what we require. ;)
November 27, 2007
Julio César Carrascal Urquijo wrote:
> 
> What worries me about immediate mode guis is performance. I suppose they are great for building the gui portion of a game or some really flashy app but I don't see an improvement for typical applications where the gui doesn't change unless until it receives some input from the user.
> 
> Just picture a dumb +30 fields form that's using 100% CPU because it is repainting it self every frame.
> 

You can, instead of using a frame-based approach, repaint as needed. The lack of state is in the interface, behind the scenes a library can do caching. I don't remember the link, but there was some guy who rewrote his traditional gui for a cellphone to an imgui one, and stated that performance was about the same.

One benefit though is that in normal gui's, a whole lot a state is retained and duplicated between the application and the gui library. In complex application, that sucks performance.

November 27, 2007
I would like a versatile GUI with many rendering back-ends (X/SDL/OpenGL) because I'd like to start working on an equivalent of openFrameworks (openframeworks.cc/forum) in D (this is a bit like processing, but written in C++ to be more efficient although it cannot be shown on the web like Java/Flash -- how about a VM for D with a firefox plug-in =) ?), this would be the equivalent of the 'Element' project that seems to have stalled, somehow ...
November 27, 2007
Julio César Carrascal Urquijo wrote:
> Bill Baxter wrote:
>> My guess is that, like OpenGL programs, you don't have to refresh regularly if nothing is happening.  But if something does happen then, yes, you do need to repaint everything.
>>
>> --bb
> 
> Well, from what I've seen before they refresh the screen each frame. Even in the video in the OP, the guy says something like: If you don't want some widget painted you just don't paint it.
> 
> 

That's because it's discussed in the context of games, but such a frame based approach is not neccessary.
November 27, 2007
Bill Baxter wrote:
> (with a nod to Don ;)
> No, I don't have the perfect GUI.
> I'm just throwing this out as a topic for discussion.  I've yet to find
> a GUI that isn't tedious to use.  With 2.0 const hopefully nearing
> completion, and the new closure support in 2.0, maybe it's a good time
> to dream again about what the ultimate D GUI would look like.

There is a few good ideas in this video http://video.google.com/videoplay?docid=9052934777843395388

November 27, 2007
Bill Baxter wrote:
> (with a nod to Don ;)
> No, I don't have the perfect GUI.
> I'm just throwing this out as a topic for discussion.  I've yet to find a GUI that isn't tedious to use.  With 2.0 const hopefully nearing completion, and the new closure support in 2.0, maybe it's a good time to dream again about what the ultimate D GUI would look like.

I like lots of ideas from WPF: http://en.wikipedia.org/wiki/Windows_Presentation_Foundation
November 28, 2007
Lutger wrote:
> You can, instead of using a frame-based approach, repaint as needed. The lack of state is in the interface, behind the scenes a library can do caching. I don't remember the link, but there was some guy who rewrote his traditional gui for a cellphone to an imgui one, and stated that performance was about the same.
> 
> One benefit though is that in normal gui's, a whole lot a state is retained and duplicated between the application and the gui library. In complex application, that sucks performance.
> 

All the implementations I've seen use real-time redrawing which is obviously overkill for this type of application. But you are right, it is certainly possible.


-- 
Julio César Carrascal Urquijo
http://jcesar.artelogico.com/