www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The GUI to end all GUI libraries (Let's Dream!)

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
(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.

So I wonder if something like this could be done in D.  Or is there 
something about the dynamic nature of Python which allows this sort of 
idea, but makes it unworkable in a static language like D?

Anyway it's a neat idea that seems to me to have potential to take us 
beyond the same old event-driven paradigm that's been rehashed for years 
and starts to get quite cumbersome beyond a certain point.

Another interesting GUI-related lib from Python-land that I have my eye 
on is Traits from Enthought [2].  Traits are sort of objects that wrap a 
state value and automatically generate callbacks.  So the core actually 
doesn't have anything to do with GUI-ness.  More like a mechanism for 
state managment + signals.  But Traits also work with TraitsUI to create 
GUIs automatically from your Traits with very little extra coding.  That 
part seems quite useful for creating quick GUI scripts and mockups, but 
less useful for creating a big app like an IDE.  I haven't worked with 
Traits much, though, so maybe it scales up better than I think.


--bb

Links:
[1] http://cheeseshop.python.org/pypi/Trellis/0.5b1
[2] http://code.enthought.com/traits/
Nov 26 2007
next sibling parent 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
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 recently met someone [1] on IRC asking nearly exactly the same question, who is working one something. I suppose this is going to be an interesting discussion... regards, frank [1] I won't disclose his identity, but I suppose he'll word up... =)
Nov 26 2007
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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
Nov 26 2007
next sibling parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
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

Recently on IRC: [02:17] <*******> it will have arbitrary theming, backends/rendering engines, probably arbitrary shapes for windows and widgets, easy new widget creation, immediate mode interface, will be extremely configurable, etc, etc :P Whoa, I hope ******* will forgive me this... The GUI is a work in progress, and I don't want to bugger up his timing. Therefore I'll mention it no more. =) regards, frank
Nov 26 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
0ffh 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

Recently on IRC: [02:17] <*******> it will have arbitrary theming, backends/rendering engines, probably arbitrary shapes for windows and widgets, easy new widget creation, immediate mode interface, will be extremely configurable, etc, etc :P

Sounds quite feature-full. But noticeably lacking is any mention of how messaging and state management will work. To me that's the real heart of it. You can always gussy up a GUI with pretty themes later, but if the notification and state management mechanisms aren't solid, then actually coding with it will always be painful. --bb
Nov 26 2007
parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Bill Baxter wrote:
 Sounds quite feature-full.  But noticeably lacking is any mention of how 
 messaging and state management will work.  To me that's the real heart 
 of it.  You can always gussy up a GUI with pretty themes later, but if 
 the notification and state management mechanisms aren't solid, then 
 actually coding with it will always be painful.

Seems like "event processing will be done like in harmonia, that is, thru sinking and bubbling. the default rendering engine will be OpenGL + FreeType2. themes will be defined using css-alike configs, but they will be able to completely redefine what compound widgets (like buttons) are. /the api will be insane/". [my italics] We can confirm that here: http://paste.dprogramming.com/dphz72yh Is a sample of approximately how it will look like to use it... =) regards, frank
Nov 28 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
0ffh wrote:
 Bill Baxter wrote:
 Sounds quite feature-full.  But noticeably lacking is any mention of 
 how messaging and state management will work.  To me that's the real 
 heart of it.  You can always gussy up a GUI with pretty themes later, 
 but if the notification and state management mechanisms aren't solid, 
 then actually coding with it will always be painful.

Seems like "event processing will be done like in harmonia, that is, thru sinking and bubbling.

Harmonia was in its death throes when I came on the scene, so I don't know much about it.
 the default rendering engine will be OpenGL + 
 FreeType2. 

Ok, so it's a game GUI then. Not too likely to become the "GUI to end all GUI libraries" then, but maybe the game GUI to end all game GUI libraries. I'm interested int that, but I'd also like to have something with at least real native menus, popup windows, text widgets (for I18N text), and dialog boxes. Maybe they have some plan for that, though. themes will be defined using css-alike configs, but they will
 be able to completely redefine what compound widgets (like buttons) are.
 /the api will be insane/". [my italics]

I'm not sure insanity is something to strive for in an API... unless you are a Perl coder, maybe.
 We can confirm that here: http://paste.dprogramming.com/dphz72yh
 
 Is a sample of approximately how it will look like to use it... =)
 
 regards, frank

It looks like the code from those Polish game guys' GUI. I never can remember the name -- team Decad3nce or something. It also looks to be an immediate mode GUI. Very interesting, anyway. Should be good for game GUIs. Looking forward to a more formal announcement. --bb
Nov 28 2007
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Bill Baxter wrote:
 0ffh wrote:
 Seems like "event processing will be done like in harmonia, that is, thru
 sinking and bubbling. 

Harmonia was in its death throes when I came on the scene, so I don't know much about it.

It used/uses an event processing system called 'sinking and bubbling' which is superior to anything in existence ;)
 the default rendering engine will be OpenGL + FreeType2. 

Ok, so it's a game GUI then. Not too likely to become the "GUI to end all GUI libraries" then, but maybe the game GUI to end all game GUI libraries. I'm interested int that, but I'd also like to have something with at least real native menus, popup windows, text widgets (for I18N text), and dialog boxes. Maybe they have some plan for that, though.

Other rendering engines will be possible, yet native backends (thus native widgets) are not planned. Unicode text rendering will be supported :)
 themes will be defined using css-alike configs, but they will
 be able to completely redefine what compound widgets (like buttons) are.
 /the api will be insane/". [my italics]

I'm not sure insanity is something to strive for in an API... unless you are a Perl coder, maybe.

Insanity is not the goal, it's the side effect of the design and D's features / limitations. It would be nicer if D had 'trailing delegates', then the 'insane' opIndex would not be needed.
 We can confirm that here: http://paste.dprogramming.com/dphz72yh

 Is a sample of approximately how it will look like to use it... =)

 regards, frank

It looks like the code from those Polish game guys' GUI. I never can remember the name -- team Decad3nce or something. It also looks to be an immediate mode GUI.

LOL :D Team0xf :> We used an early version of the GUI in Deadlock. The GUI is a hybrid between IMGUIs and RMGUIs (it's called Hybrid, too). It does background caching and matching of widgets between frames for performance and state retaining reasons
 Very interesting, anyway.  Should be good for game GUIs.  Looking 
 forward to a more formal announcement.

Thanks :) Well, you can take a look at the prototype at http://h3r3tic.googlecode.com/svn/trunk/HybridGUI/ Rather oldish screenies: http://h3.team0xf.com/proj/hybrid/1.png http://h3.team0xf.com/proj/hybrid/2.png http://h3.team0xf.com/proj/hybrid/3.png http://h3.team0xf.com/proj/hybrid/4.png (text rendering got better) Also, old demos at: http://code.google.com/p/h3r3tic/downloads/list I'm not going to post a more formal announcement very soon, as I'm currently rewriting Hybrid to use Tango and support more features, like the extremely flexible theming. When that's done, there will definitely be an .announce post :) Frank: Thanks for posting and letting me know about this thread :) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Nov 28 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tom S wrote:
 Bill Baxter wrote:
 0ffh wrote:
 Seems like "event processing will be done like in harmonia, that is, 
 thru
 sinking and bubbling. 

Harmonia was in its death throes when I came on the scene, so I don't know much about it.

It used/uses an event processing system called 'sinking and bubbling' which is superior to anything in existence ;)

Gee thanks, that really clears it up for me. :-P But you're wrong anyway. Few people know it, but the most superior event processing system ever was the 'skulking and babbling' system invented at Xerox Parc, and promptly forgotten. By everyone. :-P
 the default rendering engine will be OpenGL + FreeType2. 

Ok, so it's a game GUI then. Not too likely to become the "GUI to end all GUI libraries" then, but maybe the game GUI to end all game GUI libraries. I'm interested int that, but I'd also like to have something with at least real native menus, popup windows, text widgets (for I18N text), and dialog boxes. Maybe they have some plan for that, though.

Other rendering engines will be possible, yet native backends (thus native widgets) are not planned. Unicode text rendering will be supported :)

Yeh, I'm not so concerned about rendering text as input. Rendering is pretty easy with FreeType. But Asian languages tend to require special input methods that guess which word you mean from the phonetics you type. And you just ain't gonna re-invent that.
 themes will be defined using css-alike configs, but they will
 be able to completely redefine what compound widgets (like buttons) are.
 /the api will be insane/". [my italics]

I'm not sure insanity is something to strive for in an API... unless you are a Perl coder, maybe.

Insanity is not the goal, it's the side effect of the design and D's features / limitations. It would be nicer if D had 'trailing delegates', then the 'insane' opIndex would not be needed.

Still, that's a pretty clever and fairly clean work-around.
 We can confirm that here: http://paste.dprogramming.com/dphz72yh

 Is a sample of approximately how it will look like to use it... =)

 regards, frank

It looks like the code from those Polish game guys' GUI. I never can remember the name -- team Decad3nce or something. It also looks to be an immediate mode GUI.

LOL :D Team0xf :> We used an early version of the GUI in Deadlock. The GUI is a hybrid between IMGUIs and RMGUIs (it's called Hybrid, too). It does background caching and matching of widgets between frames for performance and state retaining reasons

Interesting. I do remember the name "hybrid" from before, but I had no idea what it meant at the time (or what "immediate mode gui" meant for that matter -- now I do thanks to Lutger's MollyRocket link.)
 Frank: Thanks for posting and letting me know about this thread :)

Thanks for 'outing' yourself ;-). One thing I noticed last time you posted something about this library was that the code for a gui is nested like 12 levels deep. I'm guessing it's possible to call out to actual separate functions for panels rather than using an in-line delegate for everything? That would make it easier to see the high-level organization of a big GUI I think. And maybe allow you to re-use a common panel on multiple screens, etc. It's just all in one honking huge function for demo purposes, I guess? --bb
Nov 28 2007
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Bill Baxter wrote:
 It used/uses an event processing system called 'sinking and bubbling' 
 which is superior to anything in existence ;)

Gee thanks, that really clears it up for me. :-P But you're wrong anyway. Few people know it, but the most superior event processing system ever was the 'skulking and babbling' system invented at Xerox Parc, and promptly forgotten. By everyone. :-P

LOL :D Well, the concept was explained here: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.dwt&artnum=61 As for event handling itself, most of it will happen in immediate mode, e.g. if (Button().stuff().clicked) { ... }
 Yeh, I'm not so concerned about rendering text as input.  Rendering is 
 pretty easy with FreeType.  But Asian languages tend to require special 
 input methods that guess which word you mean from the phonetics you 
 type.  And you just ain't gonna re-invent that.

Can't OS APIs do that? :o Sorry, I'm not an Asian ;D
 Still, that's a pretty clever and fairly clean work-around.

Thanks :)
 Thanks for 'outing' yourself ;-).
 One thing I noticed last time you posted something about this library 
 was that the code for a gui is nested like 12 levels deep.  I'm guessing 
 it's possible to call out to actual separate functions for panels rather 
  than using an in-line delegate for everything?

Sure thing! I used that in Deadlock. The nesting is mainly due to use of many VBoxes and HBoxes (like in GTK) for layout. If I figure out how to do layout better, that might as well get pretty flat.
 That would make it 
 easier to see the high-level organization of a big GUI I think.  And 
 maybe allow you to re-use a common panel on multiple screens, etc.  It's 
 just all in one honking huge function for demo purposes, I guess?

Yup, that's just a simple test. There's nothing magical about the code that may be used there. On an additional note, the delegates passed to the overloaded opIndex are executed in the same context, so there are no worries about escaping references / lack of 'full' closures in D1.0. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Nov 28 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tom S wrote:
 Bill Baxter wrote:
 It used/uses an event processing system called 'sinking and bubbling' 
 which is superior to anything in existence ;)

Gee thanks, that really clears it up for me. :-P But you're wrong anyway. Few people know it, but the most superior event processing system ever was the 'skulking and babbling' system invented at Xerox Parc, and promptly forgotten. By everyone. :-P

LOL :D Well, the concept was explained here: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digital ars.D.dwt&artnum=61

Ah, ok. Makes sense now. Yes that is nice. It drives me mad in wxWidgets that only that *one* widget gets the event, except . I can't remember what Qt does there. But that percolation is great, and very nice to have it both ways. I think it's less popular in things like wx because they go way back to the days when we didn't have two spare cycles to rub together. These days there's not much reason to do the whole chain of responsibility thing for every event. We have the cycles.
 As for event handling itself, most of it will happen in immediate mode, 
 e.g. if (Button().stuff().clicked) { ... }
 
 
 Yeh, I'm not so concerned about rendering text as input.  Rendering is 
 pretty easy with FreeType.  But Asian languages tend to require 
 special input methods that guess which word you mean from the 
 phonetics you type.  And you just ain't gonna re-invent that.

Can't OS APIs do that? :o Sorry, I'm not an Asian ;D

Yes, every OS has it's own APIs to do it that work with varying degrees of success. I don't want to have to write the code to interface with every platform's particular way of doing it. There are also things like accessibility that come into play. Screen readers and such don't know that the little rectangle on the screen you're drawing is a text box. There are probably OS hooks for that too, on OS'es that have such things, but again, I want the GUI library to handle that for me so I don't have to worry about it and it Just Works (TM). Both of those are fairly small issues in the grand scheme, but they are roadblocks on the way to being the gui to end all guis. --bb
Nov 28 2007
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
Bill Baxter wrote:
 Tom S wrote:
 Bill Baxter wrote:
 It used/uses an event processing system called 'sinking and 
 bubbling' which is superior to anything in existence ;)

Gee thanks, that really clears it up for me. :-P But you're wrong anyway. Few people know it, but the most superior event processing system ever was the 'skulking and babbling' system invented at Xerox Parc, and promptly forgotten. By everyone. :-P

LOL :D Well, the concept was explained here: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digital ars.D.dwt&artnum=61

Ah, ok. Makes sense now. Yes that is nice. It drives me mad in wxWidgets that only that *one* widget gets the event, except . I can't remember what Qt does there.

I can't either, but the sinking/bubling reminds me of how GTK+ handles events -- although I think that there the traversal is only unidirectional. Every widget in the chain can act on an event, and either stop the traversal (handled) or let it bubble further up the chain. There is also a filtering mechanism, so widgets can be configured to never receive events that they are not interested in. Good to know that wxWidgets has that limitation. We have considered using it, but went for GTK+ instead. Bastiaan.
Nov 29 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bastiaan Veelo wrote:
 Bill Baxter wrote:
 Tom S wrote:
 Bill Baxter wrote:
 It used/uses an event processing system called 'sinking and 
 bubbling' which is superior to anything in existence ;)

Gee thanks, that really clears it up for me. :-P But you're wrong anyway. Few people know it, but the most superior event processing system ever was the 'skulking and babbling' system invented at Xerox Parc, and promptly forgotten. By everyone. :-P

LOL :D Well, the concept was explained here: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digital ars.D.dwt&artnum=61

Ah, ok. Makes sense now. Yes that is nice. It drives me mad in wxWidgets that only that *one* widget gets the event, except . I can't remember what Qt does there.

I can't either, but the sinking/bubling reminds me of how GTK+ handles events -- although I think that there the traversal is only unidirectional. Every widget in the chain can act on an event, and either stop the traversal (handled) or let it bubble further up the chain. There is also a filtering mechanism, so widgets can be configured to never receive events that they are not interested in.

Yeh, actually this is the first I've heard of a toolkit that percolates both down and then up. But I'd guess percolating up starting with the deepest widget probably covers 90% of practical cases.
 Good to know that wxWidgets has that limitation. We have considered 
 using it, but went for GTK+ instead.

wxWidgets does percolate some kinds of events up the chain like command events. Like if you click on a button you get that event at the button, at the parent, and on up until someone says they handled it. But if it makes sense to do it for those kinds of things then it makes sense to do it for everything. --bb
Nov 29 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tom S wrote:
 The GUI is a hybrid between IMGUIs and RMGUIs (it's called Hybrid, too). 

By the way, if you have big plans for your GUI you may want to consider altering the name slightly so as not to raise the eybrows of the the lawyers from the Hybrid graphics/game tools company, http://www.hybrid.fi/ -- whoops make that the NVIDIA laywers! --bb
Nov 28 2007
next sibling parent 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Bill Baxter wrote:
 Tom S wrote:
 The GUI is a hybrid between IMGUIs and RMGUIs (it's called Hybrid, too). 

By the way, if you have big plans for your GUI you may want to consider altering the name slightly so as not to raise the eybrows of the the lawyers from the Hybrid graphics/game tools company, http://www.hybrid.fi/ -- whoops make that the NVIDIA laywers!

I say, sometimes it's very useful to have a graphics specialist at hand! :) regards, frank
Nov 28 2007
prev sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Bill Baxter wrote:
 Tom S wrote:
 The GUI is a hybrid between IMGUIs and RMGUIs (it's called Hybrid, too). 

By the way, if you have big plans for your GUI you may want to consider altering the name slightly so as not to raise the eybrows of the the lawyers from the Hybrid graphics/game tools company, http://www.hybrid.fi/ -- whoops make that the NVIDIA laywers!

Hah! It may be called HybridGUI :P Thanks for the hint ;) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Nov 28 2007
prev sibling next sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
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. -- Julio CÚsar Carrascal Urquijo http://jcesar.artelogico.com/
Nov 26 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Nov 26 2007
parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
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/
Nov 26 2007
parent Lutger <lutger.blijdestijn gmail.com> writes:
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.
Nov 27 2007
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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.
Nov 27 2007
parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
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/
Nov 28 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Julio CÚsar Carrascal Urquijo wrote:
 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.

Casey does mention it as a drawback of immediate mode GUI in the video. If you want lazy updates, the burden of implementing it is on the application as opposed to retained mode GUIs where the toolkit can handle it for you. But even then a lot of GUI systems have some sort of update() or refresh() call that you have to remember to call to tell it that something changed. So it's not that different I don't think. --bb
Nov 28 2007
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Bill Baxter wrote:
 Julio CÚsar Carrascal Urquijo wrote:
 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.

Casey does mention it as a drawback of immediate mode GUI in the video. If you want lazy updates, the burden of implementing it is on the application as opposed to retained mode GUIs where the toolkit can handle it for you. But even then a lot of GUI systems have some sort of update() or refresh() call that you have to remember to call to tell it that something changed. So it's not that different I don't think. --bb

In my toy imgui, I only update when there are events, and even then only when some state has changed the thing need to be rendered again. This is all behind the scenes though, so the user doesn't have to do anything. This is lazy enough in practice, I guess it's a trade between executing the gui logic on every event in the imgui case and retaining state in rmgui.
Nov 29 2007
parent Lutger <lutger.blijdestijn gmail.com> writes:
Lutger wrote:
...
 In my toy imgui, I only update when there are events, and even then only 
 when some state has changed the thing need to be rendered again. This is 
 all behind the scenes though, so the user doesn't have to do anything. 
 This is lazy enough in practice, I guess it's a trade between executing 
 the gui logic on every event in the imgui case and retaining state in 
 rmgui.

To clarify, state in imgui is handled mostly implicitly by the library and is usually a small constant, while with rmgui the user has to do bookkeeping herself and the state involved grows proportionally with the size of the gui.
Nov 29 2007
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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

Very interesting. I watched the first few minutes and read some of the comments on the web page. Looking forward to checking out the whole video when I have the time. --bb
Nov 26 2007
prev sibling parent Jan Claeys <digitalmars janc.be> writes:
Op Thu, 29 Nov 2007 02:27:52 +0100, schreef Tom S:

 Sure thing! I used that in Deadlock. The nesting is mainly due to use of
 many VBoxes and HBoxes (like in GTK) for layout. If I figure out how to
 do layout better, that might as well get pretty flat.

Gtk also has grid/table layouts, and some programmes and libraries migh have additional layout containers (e.g. column containers that balance their subitems over a number of columns). -- JanC
Nov 29 2007
prev sibling next sibling parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Also, I've been quite satisfied with DFL, which is a
mature solution for Windows and moving towards the Xes.

regards, frank
Nov 26 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
0ffh wrote:
 
 Also, I've been quite satisfied with DFL, which is a
 mature solution for Windows and moving towards the Xes.

I've started using DFL too. It seems to be the easiest thing to use right now. But it's still pretty typical in its event driven design, and lacks many convenience features I've become accustom to in other toolkits. Things like managing tooltips, status messages, and gui state updates (e.g. whether a menu item should show checked/unchecked based on current state). --bb
Nov 26 2007
prev sibling parent Clay Smith <clayasaurus gmail.com> writes:
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
Nov 26 2007
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Bill Baxter wrote:
 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.

So a largely functional GUI framework. I think that could work decently, though you'd need to define multiple input sources, one of them being the non-GUI portion of your application.
 So I wonder if something like this could be done in D.  Or is there 
 something about the dynamic nature of Python which allows this sort of 
 idea, but makes it unworkable in a static language like D?

You could do this in D or Java or C# or C or assembly, I'm sure.
 Anyway it's a neat idea that seems to me to have potential to take us 
 beyond the same old event-driven paradigm that's been rehashed for years 
 and starts to get quite cumbersome beyond a certain point.

One complex part is ordering event handlers. I have an event that five things listen to, but one handler has to fire before another, which has to fire before a third. I haven't seen much else cumbersome with it yet, but I'm still young :) What problems have you encountered?
 Another interesting GUI-related lib from Python-land that I have my eye 
 on is Traits from Enthought [2].

I don't see how this would work. Do you register an event handler, essentially, and that is used to determine which GUI components to show? For me, I want codegen for my GUI stuff, and as little code as possible interacting directly with that generated code as possible. I also want something that makes model/view/presenter easy to use, or at least that lets me use mock objects with minimal fuss. And I want a dependency injection framework.
 --bb
 
 Links:
 [1] http://cheeseshop.python.org/pypi/Trellis/0.5b1
 [2] http://code.enthought.com/traits/

Nov 26 2007
prev sibling next sibling parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
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.

Perhaps instead of D a suitably enhanced version of make is what we require. ;)
Nov 27 2007
prev sibling next sibling parent =?ISO-8859-1?Q?Ma=ebl?= <someone somewhere.com> writes:
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 ...
Nov 27 2007
prev sibling next sibling parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
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
Nov 27 2007
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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
Nov 27 2007
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
Ary Borenszweig wrote:
 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

Could you sum them up here, the ones you like most? Bastiaan.
Nov 29 2007
prev sibling next sibling parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
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 was thinking maybe we can learn something from Ruby on rails ! All the app needs to define is the model, then the framework define the control and the view. First the apps menues is just a way to call functions. new appdata file_new(); void file_save(const appdata , filename afilename); void file_save_as(const appdata , const filename afilename); new (appdata,filename afilename) file_open(filename); Would define the file menu with new,save, save_as and open, the app. should only specify the apps functionality every thing else should be themed an styled via the gui framework or by the desktop or window manager. The first line: new appdata file_new(); tell the framework that selecting the menu file->new create a new container of type appdata, the styling of the gui framework decide if this is done in a new window or tab. The next line: void file_save(const appdata , filename afilename); tells the gui to open at dialog which allow a filename to be chosen and use the content of afilename as a default. const appdata tells the gui that the dialog should not edit appdata. The line: new (appdata, filename afilename) file_open(filename); tells the gui to open the file dialog and then load the file into a new container. Hope this is understandably. Knud
Nov 29 2007
prev sibling parent Jascha Wetzel <firstname mainia.de> writes:
not that it might end all GUI libs, but i was starting to write a Qt-ish 
GUI framework (i.e. signals&slots) that can load widget layouts from 
e.g. XML files at runtime (signal connection at runtime using runtime 
reflection). rendering will be done with OpenGL, but is abstracted s.t. 
any renderer can be added.
i ran out of time, but i'll need it in a future not too far away and 
continue work on it then.
Nov 30 2007