On 26 Jul 2012, at 11:09, Thomas Geymayer <tom...@gmail.com> wrote:
> 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.
Okay, I wasn't clear from the Wiki page what the final idea was. As you say, so
long as we're going through show-dialog it should be fine. My feeling is we
still want a C++ hook around creating individual widgets, so we have the option
the create custom widgets in C++, but it's not a difficult thing to change
internally.
> 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...
Hmm, I wonder if having a C++ base class for widgets in the canvas will
simplify picking and mouse-over. To avoid such details to the basic canvas item.
> 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.
Right, in practice rectangular clipping is what's need 90% of the time so I'd
rather optimise for that case, whether that means stencils, GL scissors clip or
clip planes.
>> 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.
Right the NavDisplay is really an ARINC 661 display - it takes a list of
symbols, a list of items and combines then using a projection to create a final
display. The only additional code is to deal with special things that can't
easily be described by a simply symbol, especially the flight-plan/route path.
>> 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.
This is certainly where things need to start, then. I'd hope dragging and
resizing can be mostly handled by the Nasal layer, the C++ only needs to keep
the window and canvas texture in sync when a resize happens.
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
