I mentioned a while back that I was interested in having a simple OpenGL-based GUI toolkit that would be easy to use.

I spent most last week working on it, and thought I'd show what I've got so far.

The layout in the screen shot is done completely using Luigi "Arrangers" which is what most other toolkits call "Layouts".  The arrangers I've implemented so far are clones of some of the basic Java ones -- BorderArranger, FlowArranger, and GridArranger.  What you can see in the screenshot is a BorderArranger with a FlowArranger on the North and South, and a GridArranger on the West.

Not so many widgets implemented yet as you can see. :-(

The demo is using GLFW, but the input source and window management library is abstracted out to be easily replaceable.  Eventually I'd like to have input adapter modules also for SDL, GLUT, raw Win32 etc.

The theme is Win32-like, but that also is abstracted out and replaceable.

I'm using std.signals for notifications.

Tab-Focus shifting and drawing all work properly with hierarchically nested widgets (something other simple toolkits often overlook), but it's very hard to do generic arrangers or (eventually) scrollable panels without that.

License will be ZLIB.

(Sorry for the big attachment - I would have put the screen shot on Luigi DSource page, except for the current unavailability of DSource)

--bb

Bill Baxter wrote:
> I mentioned a while back that I was interested in having a simple OpenGL-based GUI toolkit that would be easy to use.
> 
> I spent most last week working on it, and thought I'd show what I've got so far.
> 
> The layout in the screen shot is done completely using Luigi "Arrangers" which is what most other toolkits call "Layouts".  The arrangers I've implemented so far are clones of some of the basic Java ones -- BorderArranger, FlowArranger, and GridArranger.  What you can see in the screenshot is a BorderArranger with a FlowArranger on the North and South, and a GridArranger on the West.

Will you allow users to create their own 'arrangers' ?

> 
> Not so many widgets implemented yet as you can see. :-(
> 

Could you create a system that allows users to create their own widgets out of simple 'building block' widgets?

> The demo is using GLFW, but the input source and window management library is abstracted out to be easily replaceable.  Eventually I'd like to have input adapter modules also for SDL, GLUT, raw Win32 etc.
> 
> The theme is Win32-like, but that also is abstracted out and replaceable.
> 

How do you plan on supporting themes? Do you plan on allowing 'skinning?'

> I'm using std.signals for notifications.
> 
> Tab-Focus shifting and drawing all work properly with hierarchically nested widgets (something other simple toolkits often overlook), but it's very hard to do generic arrangers or (eventually) scrollable panels without that.
> 
> License will be ZLIB.
> 
> (Sorry for the big attachment - I would have put the screen shot on Luigi DSource page, except for the current unavailability of DSource)
> 
> --bb
> 
> ------------------------------------------------------------------------
> 

I'm also working on a GUI. My setup is like this...

Basic Widgets:
 - label
 - button
 - textfield
 - image

Can be recombined to create 'higher level' widgets, like a FileDialog.

skin.xml --> holds the images used to represent different widget functions (button, button_pressed, button_hover, etc.)

layout.xml --> holds a 'layout', a combination of widgets to create new widgets, like a filedialog

gui.xml --> holds all the layouts a single program will use, simple load it up with

GUI gui = new GUI("gui.xml");

and hook up signals like so...

gui.getLayout("filedialog").getWidget("btn1").connect(&guiobserver.watchButton1); 


Just some ideas.

~ Clay

clayasaurus wrote:
> Bill Baxter wrote:
> 
>> I mentioned a while back that I was interested in having a simple OpenGL-based GUI toolkit that would be easy to use.
>>
>> I spent most last week working on it, and thought I'd show what I've got so far.
>>
>> The layout in the screen shot is done completely using Luigi "Arrangers" which is what most other toolkits call "Layouts".  The arrangers I've implemented so far are clones of some of the basic Java ones -- BorderArranger, FlowArranger, and GridArranger.  What you can see in the screenshot is a BorderArranger with a FlowArranger on the North and South, and a GridArranger on the West.
> 
> 
> Will you allow users to create their own 'arrangers' ?

Yep, no problem.  The current arrangers have no special access that user classes wouldn't have.  You just have to implement the Arranger interface.

>>
>> Not so many widgets implemented yet as you can see. :-(
>>
> 
> Could you create a system that allows users to create their own widgets out of simple 'building block' widgets?

I think so.  Just make a Panel subclass that creates and arranges the more basic widgets.  I haven't actually done it yet, so I'm sure there's something I've left out, but it's the approach I'm planning to take to implement numeric Spinners.

> 
>> The demo is using GLFW, but the input source and window management library is abstracted out to be easily replaceable.  Eventually I'd like to have input adapter modules also for SDL, GLUT, raw Win32 etc.
>>
>> The theme is Win32-like, but that also is abstracted out and replaceable.
>>
> 
> How do you plan on supporting themes? Do you plan on allowing 'skinning?'

I haven't worked out all the details yet, but drawing code is completely separated from the behavior code.  All drawing takes place in a class that implements the Theme interface, so new implementations of Theme can be created to draw things however you wish.

Personally, I'm not that excited by GUIs that require loading lots of external XML files to define their appearance, but you could certainly create a Theme implementation that behaves that way.

> I'm also working on a GUI. My setup is like this...

Is it also OpenGL based?

> Basic Widgets:
>  - label
>  - button
>  - textfield
>  - image

> Can be recombined to create 'higher level' widgets, like a FileDialog.

> skin.xml --> holds the images used to represent different widget functions (button, button_pressed, button_hover, etc.)
> [...]

Yeh, I understand that the XML thing is probably useful for non-coders creating GUIs, but I'm more interested in having something that makes it as easy as possible to create GUIs through code.  Preferably 1-line per widget in most cases.  For instance this is the kind of API I'm going for:

Panel westGroup = gui.add_widget!(GridPanel)(2,0,Gaps(2)).arrangement(Region.West);

Says, add a new GridPanel constructed with args (2,0,Gaps(2)) and set it to be arranged with 'Region.West' flags.

Unfortunately that doesn't currently work because of limitations with IFTI and variadic templates, but the idea is one line of code whenever possible.

> and hook up signals like so...
> 
> gui.getLayout("filedialog").getWidget("btn1").connect(&guiobserver.watchButton1);

for me it's
button.clicked.connect(&observer.watchButton1), but yeh, same thing.

Anyway, I'm going for the level of functionality where it's easy to take an existing OpenGL program and slap a few basic gui controls on it with a minimal amount of code.  I'm not going for a full-fledged wxWidgets replacement or anything.  In particular I'm not planning to have a very complicated event dispatch mechanism.   For instance in wxWidgets some types of events first search for handlers in a widget's most derived subclas, then all its base classes, then the parent container, and all its base classes, then the grandparent, and all it's base classes, etc, until the event gets to the top level window, and then I think maybe it gets sent to the App subclass finally.

Currently what I'm doing is dispatching events to the widget, period. If you want something fancy besides that to happen then you'll have to do it yourself.

--bb

Bill Baxter wrote:
> clayasaurus wrote:
>> Bill Baxter wrote:
>>
>>> I mentioned a while back that I was interested in having a simple OpenGL-based GUI toolkit that would be easy to use.
>>>
>>> I spent most last week working on it, and thought I'd show what I've got so far.
>>>
>>> The layout in the screen shot is done completely using Luigi "Arrangers" which is what most other toolkits call "Layouts".  The arrangers I've implemented so far are clones of some of the basic Java ones -- BorderArranger, FlowArranger, and GridArranger.  What you can see in the screenshot is a BorderArranger with a FlowArranger on the North and South, and a GridArranger on the West.
>>
>>
>> Will you allow users to create their own 'arrangers' ?
> 
> Yep, no problem.  The current arrangers have no special access that user classes wouldn't have.  You just have to implement the Arranger interface.
> 
>>>
>>> Not so many widgets implemented yet as you can see. :-(
>>>
>>
>> Could you create a system that allows users to create their own widgets out of simple 'building block' widgets?
> 
> I think so.  Just make a Panel subclass that creates and arranges the more basic widgets.  I haven't actually done it yet, so I'm sure there's something I've left out, but it's the approach I'm planning to take to implement numeric Spinners.
> 
>>
>>> The demo is using GLFW, but the input source and window management library is abstracted out to be easily replaceable.  Eventually I'd like to have input adapter modules also for SDL, GLUT, raw Win32 etc.
>>>
>>> The theme is Win32-like, but that also is abstracted out and replaceable.
>>>
>>
>> How do you plan on supporting themes? Do you plan on allowing 'skinning?'
> 
> I haven't worked out all the details yet, but drawing code is completely separated from the behavior code.  All drawing takes place in a class that implements the Theme interface, so new implementations of Theme can be created to draw things however you wish.
> 
> Personally, I'm not that excited by GUIs that require loading lots of external XML files to define their appearance, but you could certainly create a Theme implementation that behaves that way.
> 
>> I'm also working on a GUI. My setup is like this...
> 
> Is it also OpenGL based?
> 

Yep :)

>> Basic Widgets:
>>  - label
>>  - button
>>  - textfield
>>  - image
> 
>> Can be recombined to create 'higher level' widgets, like a FileDialog.
> 
>> skin.xml --> holds the images used to represent different widget functions (button, button_pressed, button_hover, etc.)
>  > [...]
> 
> Yeh, I understand that the XML thing is probably useful for non-coders creating GUIs, 

Yea, I plan of having XML support, but my GUI will be able to be defined in the code as well.

but I'm more interested in having something that makes it
> as easy as possible to create GUIs through code.  Preferably 1-line per widget in most cases.  For instance this is the kind of API I'm going for:
> 
> Panel westGroup = gui.add_widget!(GridPanel)(2,0,Gaps(2)).arrangement(Region.West);
> 
> Says, add a new GridPanel constructed with args (2,0,Gaps(2)) and set it to be arranged with 'Region.West' flags.
> 
> Unfortunately that doesn't currently work because of limitations with IFTI and variadic templates, but the idea is one line of code whenever possible.
> 
>> and hook up signals like so...
>>
>> gui.getLayout("filedialog").getWidget("btn1").connect(&guiobserver.watchButton1); 
>>
> 
> for me it's
> button.clicked.connect(&observer.watchButton1), but yeh, same thing.
> 
> Anyway, I'm going for the level of functionality where it's easy to take an existing OpenGL program and slap a few basic gui controls on it with a minimal amount of code.  I'm not going for a full-fledged wxWidgets replacement or anything.  In particular I'm not planning to have a very complicated event dispatch mechanism.   For instance in wxWidgets some types of events first search for handlers in a widget's most derived subclas, then all its base classes, then the parent container, and all its base classes, then the grandparent, and all it's base classes, etc, until the event gets to the top level window, and then I think maybe it gets sent to the App subclass finally.
> 
> Currently what I'm doing is dispatching events to the widget, period. If you want something fancy besides that to happen then you'll have to do it yourself.
> 
> --bb

Looks neat, I'll keep an eye on it :)

~ Clay

clayasaurus wrote:
> Bill Baxter wrote:
>> Is it also OpenGL based?
>>
> 
> Yep :)

How close to done are you?  I don't really want to be spending time writing this, I just needed something like it and there didn't seem to be anything out there yet.

--bb

Bill Baxter wrote:
(...)
> Yeh, I understand that the XML thing is probably useful for non-coders creating GUIs, but I'm more interested in having something that makes it as easy as possible to create GUIs through code.  Preferably 1-line per widget in most cases.  For instance this is the kind of API I'm going for:
> 
> Panel westGroup = gui.add_widget!(GridPanel)(2,0,Gaps(2)).arrangement(Region.West);
> 
> Says, add a new GridPanel constructed with args (2,0,Gaps(2)) and set it to be arranged with 'Region.West' flags.
> 
> Unfortunately that doesn't currently work because of limitations with IFTI and variadic templates, but the idea is one line of code whenever possible.

Cool, I'm looking forward to checking it out once dsource is back online. I think XML has more benefits, such as using it with a visual designer and being able to modify the GUI without recompiling (modding comes to mind).

>(...) 
> Anyway, I'm going for the level of functionality where it's easy to take an existing OpenGL program and slap a few basic gui controls on it with a minimal amount of code.  I'm not going for a full-fledged wxWidgets replacement or anything.  In particular I'm not planning to have a very complicated event dispatch mechanism.   For instance in wxWidgets some types of events first search for handlers in a widget's most derived subclas, then all its base classes, then the parent container, and all its base classes, then the grandparent, and all it's base classes, etc, until the event gets to the top level window, and then I think maybe it gets sent to the App subclass finally.
> 
> Currently what I'm doing is dispatching events to the widget, period. If you want something fancy besides that to happen then you'll have to do it yourself.
> 
> --bb

That is good to hear, there is no gui like this for D yet, even in c / c++ there are but a few easy to slap in gui toolkits, mostly still too bloated imho.

Besides GLFW, are there more dependencies?

Bill Baxter wrote:
(...)
> Yeh, I understand that the XML thing is probably useful for non-coders creating GUIs, but I'm more interested in having something that makes it as easy as possible to create GUIs through code.  Preferably 1-line per widget in most cases.  For instance this is the kind of API I'm going for:
> 
> Panel westGroup = gui.add_widget!(GridPanel)(2,0,Gaps(2)).arrangement(Region.West);
> 
> Says, add a new GridPanel constructed with args (2,0,Gaps(2)) and set it to be arranged with 'Region.West' flags.
> 
> Unfortunately that doesn't currently work because of limitations with IFTI and variadic templates, but the idea is one line of code whenever possible.

Cool, I'm looking forward to checking it out once dsource is back online. I think XML has more benefits, such as using it with a visual designer and being able to modify the GUI without recompiling (modding comes to mind).

>(...) 
> Anyway, I'm going for the level of functionality where it's easy to take an existing OpenGL program and slap a few basic gui controls on it with a minimal amount of code.  I'm not going for a full-fledged wxWidgets replacement or anything.  In particular I'm not planning to have a very complicated event dispatch mechanism.   For instance in wxWidgets some types of events first search for handlers in a widget's most derived subclas, then all its base classes, then the parent container, and all its base classes, then the grandparent, and all it's base classes, etc, until the event gets to the top level window, and then I think maybe it gets sent to the App subclass finally.
> 
> Currently what I'm doing is dispatching events to the widget, period. If you want something fancy besides that to happen then you'll have to do it yourself.
> 
> --bb

That is good to hear, there is no gui like this for D yet, even in c / c++ there are but a few easy to slap in gui toolkits, mostly still too bloated imho.

Besides GLFW, are there more dependencies?

Bill Baxter wrote:
> The demo is using GLFW, but the input source and window management library is abstracted out to be easily replaceable.
Why not use the D native GLD ?

Tomas Lindquist Olsen wrote:
> Bill Baxter wrote:
>> The demo is using GLFW, but the input source and window management library is abstracted out to be easily replaceable.
> Why not use the D native GLD ?

For those who may not know, GLD is a D language port of GLFW.

I'm in the process of setting up a dsource project called Schooner where GLD will be hosted (along with a port of FTGL, and possibly others). I was going to get everything cleaned up before announcing it, but that has been delayed by the dsource.org downtime.

It would be great if Luigi would use GLD. Since GLD is currently just a direct port of GLFW, making the switch should be simple.

Lutger wrote:
> Bill Baxter wrote:

> Cool, I'm looking forward to checking it out once dsource is back online. I think XML has more benefits, such as using it with a visual designer and being able to modify the GUI without recompiling (modding comes to mind).

Yep I can believe it is useful.  But I've been watching the development of CEGUI for a while, which took the XML-for-everything approach, and after few years at it they still don't have a good toolchain for editing their XML files AFAIK.  So instead of something easier to use than a C++-code GUI, what you have is something that still requires hand-editing text, but now it has to be done in horribly verbose XML, and without the benefit of your Intellisense IDE to help you remember what parameters each widget takes.   AND you get the complications of having to make sure your exe can find the XML files at run time.  And probably you still have to set up callbacks from the code side, so you've got additional synchronization issues between the code and the XML files.  And you've now probably added a dependency on an external XML parsing tool.

XML makes some sense in the long run, but not unless you have a whole lot of manpower, IMHO.  wxWidgets is now I think finally to the point where their XML GUI xrc stuff works pretty reliablly and is decently supported by tools.  But it took a heck of a long time, and I think the nice editing tools aren't free (DialogBlocks is the best I know of), because those take a lot of manpower to create too.

Anyway I'm after something that will be usable with a few weeks of effort, not a decade.

> That is good to hear, there is no gui like this for D yet, even in c / c++ there are but a few easy to slap in gui toolkits, mostly still too bloated imho.
> 
> Besides GLFW, are there more dependencies?

I'm using Derelict for both GLFW and GL.  But that's it for dependencies.  I'd like to figure out how to leave the choice of how to access OpenGL up to the user too, but I'm not sure how or if it's technically even possible.  Maybe I just need to extern all the gl functions I'm using?

Also, all the GLFW code is all in one file: luigi/adaptor/glfw.d
The user needs to import this in their app to get the GLFW support.

--bb