Announcing Luigi -- WIP teaser
clayasaurus
clayasaurus at gmail.com
Mon Nov 13 08:55:47 PST 2006
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
More information about the Digitalmars-d-announce
mailing list