2012/7/26 James Turner <zakal...@mac.com>:
>> We could for example just add some more parseXXX functions (like
>> parsesvg) which parse a dialog/hud/whathever file and create a canvas
>> from it. So we would just have to modify eg. the show-dialog command
>> to create a canvas and call the parser.
> We need to keep the existing way of specifying GUI files via XML - it's a 
> nice, declarative way of building the dialogs. Switching to an imperative 
> system would be a step backwards. I do like the idea of a 
> gui/widget/widgetname.nas structure so we can easily create a factory 
> function and hack / add widgets.

I didn't meant to replace the existing way, but instead only changing
the implementation to use the Canvas system in Nasal space. Just
mapping the existing dialog-show command to a Nasal function which
creates a window and parses a GUI xml file. This wouldn't change
anything on how dialogs are specified and shown.

> Have you thought where the layout logic will work in this scheme? Right now 
> it's all in C++, and a layout manager might make sense for the canvas in 
> general (think about laying out text or elements on an MFD or EICAS), 
> possibly even in C++, but again you maybe already have a solution.

I think the best place would be doing it with Nasal, as there is
already all the information needed available. C++ doesn't know
anything about widgets...

> Right, clipping is needed for 2D panel support too. We need to consider this 
> one carefully since it's needed for various GUI widgets as well, and there's 
> a few different implementation strategies. Stencil planes are one option, I'm 
> unsure about the performance of 'real' GL clipping on modern hardware.

We will need to support clipping using the stencil buffer in any case,
as it allows arbitrary shapes to be used. We need to check if OpenGL
clipping planes are faster - if it's the case we should use them for
rectangular clipping regions.

> I have some knowledge of this from doing the MapWidget and NavDisplay, happy 
> to take a look.

You will probably find some parts you already know :) Basically I
wanted to loosely follow the ideas from ARINC 661.

> Picking is surely needed already for building widgets, unless you mean 
> something more detailed? Like obtaining the X/Y position inside a widget? In 
> general I think the event handling will evolve once PUI is not involved at 
> all (see next point)

I meant to determine which element the mouse is currently pointing at.
This could either be the (leaf) element where the mouse position is
inside the bounding box or a bit more complicated exactly inside the
element by checking which element the current pixel belongs to
(similar to OpenGL picking). The exact mouse position should also be
passed to the widget, as this could be needed eg. by a map widget to
determine where the user actually clicked in world coordinates and add
waypoints or something else.

> I had a look at the wiki and the major thing is we need to switch away from 
> the CanvasWidget approach you're using now - I.e we need a C++ dialog 
> implementation that wraps a canvas and has /no/ PUI dependency at all. (As 
> you already started discussing) Actually that code is going to look quite 
> similar to the osgWidget base class :)

Maybe we can use some ideas from it :) Basically we only need to pass
mouse/keyboard events and handle dragging/resizing and input
focus/stacking order of multiple dialogs.


Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Flightgear-devel mailing list

Reply via email to