John Reimer wrote:
> clayasaurus wrote:
> 
>> You can either
>> A) Try and use DUI over at dsource.org, which is essentially GTK for D
>> B) Roll out your own and become famous
>>
>> As for a newsreader, go to mozilla.com and grab a hold of Thunderbird, it has search functionality and makes the newsgroup readable.
>>
>> If you decide to roll your own, here are some more options
>>
>> 1) Work with the dsource.org community to try and make a standard OpenGL GUI for D. This way other D programmers interested in the same thing can give you support and be your advanced beta testers. I'll promise you at least two people will be interested in it. ;)
>>
>> 2) Make bindings for an already existing D OpenGL GUI. You can get C and C++ libraries to work in D, albeit C++ takes a little more effort as you bind from C++ --> C --> D.
>>
>> Goodluck, for whichever path you may choose.
>> ~ Clay
> 
> 
> What about Terra? It is a GUI framework done fully in OpenGL, I believe. The project looked like it was getting off to a good start.  Maybe that's of interest here?
> 
> -JJR

Well, I did say 'work with the dsource.org community and try to make a standard OpenGL GUI for D,' Terra would certainly pertain to this. The ownly downside is that I assume Trevor is busy with Titan (kernel) and that Terra's SVN doesn't contain anything ATM.

clayasaurus wrote:
> John Reimer wrote:
> 
>> clayasaurus wrote:
>>
>>> You can either
>>> A) Try and use DUI over at dsource.org, which is essentially GTK for D
>>> B) Roll out your own and become famous
>>>
>>> As for a newsreader, go to mozilla.com and grab a hold of Thunderbird, it has search functionality and makes the newsgroup readable.
>>>
>>> If you decide to roll your own, here are some more options
>>>
>>> 1) Work with the dsource.org community to try and make a standard OpenGL GUI for D. This way other D programmers interested in the same thing can give you support and be your advanced beta testers. I'll promise you at least two people will be interested in it. ;)
>>>
>>> 2) Make bindings for an already existing D OpenGL GUI. You can get C and C++ libraries to work in D, albeit C++ takes a little more effort as you bind from C++ --> C --> D.
>>>
>>> Goodluck, for whichever path you may choose.
>>> ~ Clay
>>
>>
>>
>> What about Terra? It is a GUI framework done fully in OpenGL, I believe. The project looked like it was getting off to a good start.  Maybe that's of interest here?
>>
>> -JJR
> 
> 
> Well, I did say 'work with the dsource.org community and try to make a standard OpenGL GUI for D,' Terra would certainly pertain to this. The ownly downside is that I assume Trevor is busy with Titan (kernel) and that Terra's SVN doesn't contain anything ATM.
> 

Another thing I forgot to add, he wants an API independent GUI lib. Wouldn't a GUI lib in Terra force API dependence on Terra? What if he wants to use it with SDL or GLFW?

John Reimer wrote:
> Tom S wrote:
> 
>> clayasaurus wrote:
>>
>>> You can either
>>> A) Try and use DUI over at dsource.org, which is essentially GTK for D
>>> B) Roll out your own and become famous
>>
>>
>> I don't get it. Why are you suggesting DUI ? Chad was certainly asking about a GUI that draws in a 3D api, not a general purpose system-level GUI like GTK or DWT, etc. Something just like CEGUI, Terra's GUI or my own.
>>
>>
> 
> Because of this line:
> 
> "It has to use OpenGL, unless someone can tell me how to make OpenGL
> and some other GUI lib using a different renderer work in harmony in the same app, on the same window."
> 
> It was just ambiguous enough so that we thought he meant a GUI that could access opengl.  Otherwise I agree... he was quite plain about what he really wanted.
> 
> -JJR

Yes, and DUI may suit his purposes especially if he is doing a level editor. The more options he has the better.

Interesting.  Yes it needs to be good for games.  This means skinnable and I'm also thinking it will need to be capable of HUD (heads up display) type functionality (alpha blending perhaps?), incase the player wants to put widgets/icons/whatever ontop of the game's viewport.  It also needs to be fast.  I am really hoping for something that is strictly a GUI system, not an API.

Now I haven't given an entirely thorough look at all of the suggestions, but I did give a glance.  I still have plenty of reading to do.  Anyhow, here are my impressions:

DUI - Yeah seems too system oriented.  If it meets some of the other criteria though, I wonder how difficult it would be to add on some game-developer friendly code in there?  Perhaps add the option to make it function like I suggested in my original post: let the person using it plug in their own API for it to work ontop of.

Terra - I am having trouble understanding what exactly its intent is.  I probably just haven't read the forum on dsource enough.  I read Trevor's welcoming post and he said this "Terra is not meant for game development, it's meant for application development. It is not so different from SDL or GLFW, spare the fact that it's written in D, instead of being a binding to a compiled C library."  He then said that a GUI toolkit could be built ontop of Terra and OpenGL.  That would suggest that it is primarily an API... I get the feeling I am wrong about this though.

Qt - Qt looks BIG.  It is probably far more than I could port or replicate.  If I had plenty of help though it might be possible.  It also looks expensive (at least for my bedroom programmer/college student budget), unless the D version could be made free somehow.  And it seems to want to be an API as well as a GUI, and I dunno how problematic that may or may not be.  Those things aside though, it looks very impressive.

Tom/h3r3tic's GUI - I tried to run the demo (TechDemo #5), but it crashed :/  It gave me the same error that the Mirrors demo gave JJR. Mirrors also crashed for me in the same way.  FYI I am using a Radeon 9500 PRO / 9700 on a Windows XP SP2 system.  I may try running it on another system to try and get it to work.  It sounds very close to what I need.

If I were to make my own or port/bind something from C++, my initial instinct is to model it after CEGUI and make it strictly a GUI, and nothing else.  Then hopefully other things could be built ontop of it, underneath it, or... or even next to it!, ideally with a minimum of hassle for whoever uses it.  I am not sure I'd be able to do that though, and I might have to settle for a pretty minimalistic GUI subsystem.

Chad J wrote:
> I have decided that I want to write my computer games in D, instead of C#, C++, or anything else.  That said, I will need a GUI toolkit for any game I want to make in D.  It has to use OpenGL, unless someone can tell me how to make OpenGL and some other GUI lib using a different renderer work in harmony in the same app, on the same window.  So far I have been unable to find any GUI libs that will work with both D and OpenGL, and I was wondering if one is available or in the works.
> 
> If there isn't a good OpenGL GUI around that works in D, I am probably going to code one myself.  I've decided that it would probably be easier to just port some C++ code from one of the OpenGL GUI libraries rather than do it from scratch.  One I am particularly interested in is CEGUI, or Crazy Eddie's GUI System (http://www.cegui.org.uk/modules/news/).  So far I like it.  It is skinnable, uses XML for said skinning, seems straightforward enough, and is used in games.  One thing caught my attention though: CEGUI can use different renderers to display the GUI.  It made me start to think, why not have a GUI that can use any renderer or basic API?  I get the feeling that most of the code in a GUI library deals with its behavior, accepting inputs, and deciding where to draw images, and only a small fraction is dedicated to actually rendering the images.  I'm thinking it might be possible to make a layer that would work between the GUI and the renderer, and allow people to write modules for the GUI system that tell it how to handle rendering.  That way all of the GUI code would be reused, and people who want a different API/renderer would just need to tell the GUI system how to draw an image to the screen.  Another problem I see with GUI lib reliance on APIs is input.  CEGUI handled that by having the coder inject mouse/keyboard events into it.  Such a library could have little or no reliance on any API, native or otherwise.  Please correct me if I'm wrong, or let me know if this sort of thing is happening already.
> 
> One last thing - I am unable to find a "search" option on this forum/newsgroup. Is there an easier way to look for things besides looking through the forum one page at a time?
> 
> 

Check out this C version of something close to what you're looking for.
  The code is almost guaranteed not to compile as-is, but it is valid
code taken straight from a project of mine.  I can provide you the
entire project (I've been meaning to release it open-source anyway) soon
if you're interested.

The main stuff you'll want to check out is in glwindows.c, which has all the OpenGL calls to render the windows, controls, handle clicks, push buttons, call event handlers - everything.  It's not as nice as I would've liked it to be, but it definitely got the job done for my purposes (a map editor which was really quite impressive).

It sports a very rudimentary set of controls: button, label, panel, checkbox, radiobutton, and window.  It is all mouse-driven, no keyboard event handler yet since there isn't any control which requires keyboard input.  I meant to add a textbox control in order to get basic keyboard support in...  Also, the code is not dependent on any API for mouse events - there is an 'OnMouseDown' function and an 'OnMouseUp' function which should be called when the mouse click goes down and when the mouse click is released, respectively.

The glwindows.h header declares three extern variables which must be defined: 'GUITexture', 'Window', and 'Mouse'.

The 'GUITexture' is simply a GLUint which is a texture handle generated from glTexImage2D and the like.  Gen some textures, load em up, and set that ID.

The 'Mouse' is a simple struct defining X and Y coords for the mouse cursor and the button status.  These fields are to be set by the host application whenever the appropriate mouse move and click events are received.

The code is attached with most of the supporting files.  I'll see what I can do in the mean time about porting it to D; it doesn't look that hard.

P.S. - it's "skinnable" in that you can load up different textures to define how the controls and windows appear (see GUIwood.tga vs. GUIstone.tga).  Hope this helps.

P.P.S. - the image files will be attached in a reply-to post.

James Dunne wrote:
> Chad J wrote:
> 
>> I have decided that I want to write my computer games in D, instead of
>> C#, C++,
>> or anything else.  That said, I will need a GUI toolkit for any game I
>> want to
>> make in D.  It has to use OpenGL, unless someone can tell me how to
>> make OpenGL
>> and some other GUI lib using a different renderer work in harmony in
>> the same
>> app, on the same window.  So far I have been unable to find any GUI
>> libs that
>> will work with both D and OpenGL, and I was wondering if one is
>> available or in
>> the works.
>> If there isn't a good OpenGL GUI around that works in D, I am probably
>> going to
>> code one myself.  I've decided that it would probably be easier to
>> just port
>> some C++ code from one of the OpenGL GUI libraries rather than do it from
>> scratch.  One I am particularly interested in is CEGUI, or Crazy
>> Eddie's GUI
>> System (http://www.cegui.org.uk/modules/news/).  So far I like it.  It is
>> skinnable, uses XML for said skinning, seems straightforward enough,
>> and is used
>> in games.  One thing caught my attention though: CEGUI can use different
>> renderers to display the GUI.  It made me start to think, why not have
>> a GUI
>> that can use any renderer or basic API?  I get the feeling that most
>> of the code
>> in a GUI library deals with its behavior, accepting inputs, and
>> deciding where
>> to draw images, and only a small fraction is dedicated to actually
>> rendering the
>> images.  I'm thinking it might be possible to make a layer that would
>> work
>> between the GUI and the renderer, and allow people to write modules
>> for the GUI
>> system that tell it how to handle rendering.  That way all of the GUI
>> code would
>> be reused, and people who want a different API/renderer would just
>> need to tell
>> the GUI system how to draw an image to the screen.  Another problem I
>> see with
>> GUI lib reliance on APIs is input.  CEGUI handled that by having the
>> coder
>> inject mouse/keyboard events into it.  Such a library could have
>> little or no
>> reliance on any API, native or otherwise.  Please correct me if I'm
>> wrong, or
>> let me know if this sort of thing is happening already.
>> One last thing - I am unable to find a "search" option on this
>> forum/newsgroup.
>> Is there an easier way to look for things besides looking through the
>> forum one
>> page at a time?
>>
>>
> 
> Check out this C version of something close to what you're looking for.
>  The code is almost guaranteed not to compile as-is, but it is valid
> code taken straight from a project of mine.  I can provide you the
> entire project (I've been meaning to release it open-source anyway) soon
> if you're interested.
> 
> The main stuff you'll want to check out is in glwindows.c, which has all the OpenGL calls to render the windows, controls, handle clicks, push buttons, call event handlers - everything.  It's not as nice as I would've liked it to be, but it definitely got the job done for my purposes (a map editor which was really quite impressive).
> 
> It sports a very rudimentary set of controls: button, label, panel, checkbox, radiobutton, and window.  It is all mouse-driven, no keyboard event handler yet since there isn't any control which requires keyboard input.  I meant to add a textbox control in order to get basic keyboard support in...  Also, the code is not dependent on any API for mouse events - there is an 'OnMouseDown' function and an 'OnMouseUp' function which should be called when the mouse click goes down and when the mouse click is released, respectively.
> 
> The glwindows.h header declares three extern variables which must be defined: 'GUITexture', 'Window', and 'Mouse'.
> 
> The 'GUITexture' is simply a GLUint which is a texture handle generated from glTexImage2D and the like.  Gen some textures, load em up, and set that ID.
> 
> The 'Mouse' is a simple struct defining X and Y coords for the mouse cursor and the button status.  These fields are to be set by the host application whenever the appropriate mouse move and click events are received.
> 
> The code is attached with most of the supporting files.  I'll see what I can do in the mean time about porting it to D; it doesn't look that hard.
> 
> P.S. - it's "skinnable" in that you can load up different textures to define how the controls and windows appear (see GUIwood.tga vs. GUIstone.tga).  Hope this helps.
> 
> P.P.S. - the image files will be attached in a reply-to post.
As promised, the related image files.

In article <dnqi4p$269s$1@digitaldaemon.com>, Chad J says...
>Tom/h3r3tic's GUI - I tried to run the demo (TechDemo #5), but it crashed :/  It gave me the same error that the Mirrors demo gave JJR. Mirrors also crashed for me in the same way.  FYI I am using a Radeon 9500 PRO / 9700 on a Windows XP SP2 system.  I may try running it on another system to try and get it to work.  It sounds very close to what I need.

Sorry for that. It happens on most ATI cards. Not entirely my fault. It crashes on DSL initialization when SDL_HWSURFACE is passed to the window's initializer. Not sure why. Try testing it on an nVidia. I'll put an updated executable online today.

--
Tomasz Stachowiak a.k.a. h3r3tic

Tom S wrote:
> In article <dnqi4p$269s$1@digitaldaemon.com>, Chad J says...
> 
>>Tom/h3r3tic's GUI - I tried to run the demo (TechDemo #5), but it crashed :/  It gave me the same error that the Mirrors demo gave JJR. Mirrors also crashed for me in the same way.  FYI I am using a Radeon 9500 PRO / 9700 on a Windows XP SP2 system.  I may try running it on another system to try and get it to work.  It sounds very close to what I need.
> 
> 
> Sorry for that. It happens on most ATI cards. Not entirely my fault. It crashes
> on DSL initialization when SDL_HWSURFACE is passed to the window's initializer.
> Not sure why. Try testing it on an nVidia. I'll put an updated executable online
> today.

Ok... here's a link (3MB):
http://158.75.59.9/~h3/download/smallTest.rar

It's not the same app as in test5.rar nor is it my most recent code. The latest code doesn't work, because of me doing some hack'n'slash on it ;)
It should work on ATI carts, at least it worked when I tested it :). Oh, and make sure to extract files to a directory without a space in its path. I'll make a workaround later.


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Of course, there is derelict providing bindings to the famous SDL libraries.  Since they lack GUI functions (although there are GUI libs for SDL that you might create bindings for) it probably isn't what you want.

-Sebastian

Chad J schrieb:
> I have decided that I want to write my computer games in D, instead of C#, C++,
> or anything else.  That said, I will need a GUI toolkit for any game I want to
> make in D.  It has to use OpenGL, unless someone can tell me how to make OpenGL
> and some other GUI lib using a different renderer work in harmony in the same
> app, on the same window.  So far I have been unable to find any GUI libs that
> will work with both D and OpenGL, and I was wondering if one is available or in
> the works.  
> 
> If there isn't a good OpenGL GUI around that works in D, I am probably going to
> code one myself.  I've decided that it would probably be easier to just port
> some C++ code from one of the OpenGL GUI libraries rather than do it from
> scratch.  One I am particularly interested in is CEGUI, or Crazy Eddie's GUI
> System (http://www.cegui.org.uk/modules/news/).  So far I like it.  It is
> skinnable, uses XML for said skinning, seems straightforward enough, and is used
> in games.  One thing caught my attention though: CEGUI can use different
> renderers to display the GUI.  It made me start to think, why not have a GUI
> that can use any renderer or basic API?  I get the feeling that most of the code
> in a GUI library deals with its behavior, accepting inputs, and deciding where
> to draw images, and only a small fraction is dedicated to actually rendering the
> images.  I'm thinking it might be possible to make a layer that would work
> between the GUI and the renderer, and allow people to write modules for the GUI
> system that tell it how to handle rendering.  That way all of the GUI code would
> be reused, and people who want a different API/renderer would just need to tell
> the GUI system how to draw an image to the screen.  Another problem I see with
> GUI lib reliance on APIs is input.  CEGUI handled that by having the coder
> inject mouse/keyboard events into it.  Such a library could have little or no
> reliance on any API, native or otherwise.  Please correct me if I'm wrong, or
> let me know if this sort of thing is happening already.  
> 
> One last thing - I am unable to find a "search" option on this forum/newsgroup.
> Is there an easier way to look for things besides looking through the forum one
> page at a time?
> 
> 

> If there isn't a good OpenGL GUI around that works in D, I am probably
> going to code one myself.  I've decided that it would probably be
> easier to just port some C++ code from one of the OpenGL GUI libraries
> rather than do it from scratch.  One I am particularly interested in
> is CEGUI, or Crazy Eddie's GUI System
> ...

http://www.asahi-net.or.jp/~cs8k-cyu/index_e.html
there are 5 games on this site coded in D, and they all come with full source code. He uses and SDL library ported to D. The game Gunroar compiles easily with the latest version of dmd, but the other games used older versions of the compiler and don't compile without changing the code a little bit. 

I don't know the legality of using this code, you probably need to contact the guy who wrote them.

P.S. Tumiki Fighters is fun ;)

Chris