On 25 Jul 2012, at 17:27, Thomas Geymayer <tom...@gmail.com> wrote:
> 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.

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.

> - Clipping: For different reasons we will need to be able to clip
> some elements to certain regions. It should work with specifying
> either a clipping rectangle or by using a path. OpenVG seems to have
> support for it, although I haven't looked into it too deep. We also
> need to ensure that it also works with text.

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.

> - Geographic Mapping: It's very experimental, missing different
> projection modes (eg. vertical projection) and especially the Nasal
> API feels very hackish.

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

> - Picking: For mouse handling some kind of picking would be nice. As
> already mentioned, at least bounding box intersections will be needed.

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)

> - Improve PUI to allow eg. receiving mouse over events.

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 :) That will get rid of the legacy (GLUT based) 
mouse event API that PUI uses, and mean we can support any mouse event 
supported by osgGA and osgViewer - mouse wheel, buttons and mouse-over.


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