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

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

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

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

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

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

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

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

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

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