www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Announcing Luigi -- WIP teaser [25k image attachment]

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
Nov 12 2006
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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(&guiobs rver.watchButton1); Just some ideas. ~ Clay
Nov 13 2006
parent reply Bill Baxter <wbaxter gmail.com> writes:
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
Nov 13 2006
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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(&guiobs
rver.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
Nov 13 2006
parent reply Bill Baxter <wbaxter gmail.com> writes:
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
Nov 13 2006
parent clayasaurus <clayasaurus gmail.com> writes:
Bill Baxter wrote:
 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

I don't think I'll be done anytime soon, it might be complete around the time D 1.0 is released. I think I have slightly different design goals for my GUI, the number one for me being that it is meant for users of my 2D game library. I'd recommend that you keep on working on yours, and we can share code/ideas as necessary, and learn what works well and what doesn't work well for OpenGL based GUI libraries. PS: I made a previous reply to this NG, but it got lost? Hrm...
Nov 13 2006
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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?
Nov 13 2006
parent Bill Baxter <wbaxter gmail.com> writes:
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
Nov 13 2006
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
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?
Nov 13 2006
prev sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Bill Baxter wrote:
 The demo is using GLFW, but the input source and window management 
 library is abstracted out to be easily replaceable.

Nov 13 2006
next sibling parent reply Bradley Smith <user domain.invalid> writes:
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.


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.
Nov 13 2006
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bradley Smith wrote:
 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.


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.

Sure, is there someplace I can get GLD while dsource remains down? --bb
Nov 13 2006
parent Bradley Smith <digitalmars-com baysmith.com> writes:
While dsource is down, you can get it at http://www.baysmith.com/d/gld-2.zip


Bill Baxter wrote:
 Bradley Smith wrote:
 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.


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.

Sure, is there someplace I can get GLD while dsource remains down? --bb

Nov 13 2006
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bradley Smith wrote:
 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.


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.

Looks like to get schooner to compile you need implib.exe, which I found here: http://ftp.digitalmars.com/bup.zip You might want to mention that in the readme or on the dsource page. --bb
Nov 26 2006
parent Bradley Smith <digitalmars-com baysmith.com> writes:
Bill Baxter wrote:
 Bradley Smith wrote:
 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.


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.

Looks like to get schooner to compile you need implib.exe, which I found here: http://ftp.digitalmars.com/bup.zip You might want to mention that in the readme or on the dsource page. --bb

Thanks for pointing that out. I forgot that implib.exe was not part of the standard DMD distribution. I'll update the documentation, and create binary distributions.
Nov 27 2006
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
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 ?

That should work too. I just used the first thing I could manage to get working, which was Derelict's GLFW. --bb
Nov 13 2006
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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.


Just checked in a new GLD input adapter for Luigi. Works like a charm. The hardest part was figuring out how to compile gld given that all the paths where it expects to find things are embedded in a D source file. And it needs implib.exe, which I had to go looking for. Once I had GLD compiled then it was just a matter of s/glfw/gld/g on all the working GLFW code. So Luigi now supports GLD. Luigi also now has working * buttons * textfields * checkboxes * sliders And you can see on the screenshots page that there's a snazzy texture-based theme in the works (texture currently borrowed from the DirectX utility toolkit). I've only implemented buttons for that so far. Luigi URL: http://www.dsource.org/projects/luigi Screenshots: http://www.dsource.org/projects/luigi/wiki/screenshots --bb
Nov 26 2006