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. Regards, Tom ------------------------------------------------------------------------------ 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
