View mode: basic / threaded / horizontal-split · Log in · Help
November 13, 2006
Announcing Luigi -- WIP teaser [25k image attachment]
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
November 13, 2006
Re: Announcing Luigi -- WIP teaser [25k image attachment]
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
November 13, 2006
Re: Announcing Luigi -- WIP teaser
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
November 13, 2006
Re: Announcing Luigi -- WIP teaser
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
November 13, 2006
Re: Announcing Luigi -- WIP teaser
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
November 13, 2006
Re: Announcing Luigi -- WIP teaser
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?
November 13, 2006
Re: Announcing Luigi -- WIP teaser
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?
November 13, 2006
Re: Announcing Luigi -- WIP teaser [25k image attachment]
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 ?
November 13, 2006
Re: Announcing Luigi -- WIP teaser [25k image attachment]
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.
November 13, 2006
Re: Announcing Luigi -- WIP teaser
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home