View mode: basic / threaded / horizontal-split · Log in · Help
November 28, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 28, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 28, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!) [semi-OT]
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
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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=digitalmars.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
1 2 3 4
Top | Discussion index | About this forum | D home