Announcing Luigi -- WIP teaser

[clayasaurus]

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