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. James ------------------------------------------------------------------------------ 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
