www.digitalmars.com         C & C++   DMDScript  

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

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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.


Why not use the D native GLD ?
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.


 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.
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.


 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.
 


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.


 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.


 
 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.


 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.
 



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.


 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.


 
 
 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.


 Why not use the D native GLD ?


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