Announcing Luigi -- WIP teaser

Bill Baxter wbaxter at gmail.com
Mon Nov 13 08:45:23 PST 2006


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



More information about the Digitalmars-d-announce mailing list