The GUI to end all GUI libraries (Let's Dream!)

[Bill Baxter]

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