On 25 Jul 2012, at 11:42, stefan riemens wrote:
> This is very convincing! Congratulations, that looks really neat.
> Having seen this, I think we'd better go with the canvas approach. It
> would require quite a lot of code to get osgWidget to produce that...
Okay, I think Stefan and I are convinced :)
Thomas, I have the impression you've been working on this stuff for a while,
could you please summarise how you see it developing so Stefan and I can see
where we might help.
I'm pretty concerned to keep the Nasal code sufficiently structured that we
vary the widget implementation without updating the dialogs. In particular, I'm
concerned that we don't end up with inline Nasal dialog XML which depends on
the widget implementation internals, simply because that's convenient in Nasal.
(for example, the current dialog XML files don't know anything about
'mouse-handling', they work exclusively in bindings, and that's a good
separation of UI events from semantic behaviours)
I'd also like to see / understand how we manage XML / property-list file
processing in a nice way, to support the various formats we want to create
canvas elements from - GUI dialogs, 2D panels and HUDs.
So, yes, if you could explain your plan here, and where people could help, that
would be useful.
Regards,
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