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
next sibling 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 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 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 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 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?





 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 Dan <murpsoft hotmail.com> writes:
/me shakes his head.

A black screen is the perfect GUI.  The machine must interpret my intentions
and perform my every wish.  I shall be at the beach enjoying iced tea.
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.


All you need is an updateWindow function.
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