2012/7/25 James Turner <zakal...@mac.com>:
> 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 think it now slowly reaches a state where everything starts to
stabilize. The API is really easy to use and most things should be
already possible without any modification to the C++ code. Now we need
to extend the API, create some helper functions/classes and have a
look what is possible and what is still missing.

> 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 have based the implementation on many ideas from different existing
technologies and projects. The most important are the Javascript DOM
API and some Javascript/SVG/drawing APIs (eg. jQuery SVG [1]).

For mouse handling I like the idea of having event handlers (eg.
click, drag, hover, etc.). So instead of just one property holding the
events of the whole dialog/canvas I want to forward the event to the
according element by using picking or maybe for a first step just
bounding box checking with the current mouse position. It would still
just set the three properties like before (button, x, y) but we could
add an helper function which adds a listener to the button property
and calls a function with all three parameters if the event was
triggered. (I always want to keep the basic idea of only communicating
via the property tree).

> 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.

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.

> So, yes, if you could explain your plan here, and where people could help,
> that would be useful.

Missing things:

 - Documentation: Read, ask questions, extend. I haven't done too much
documentation (apart from inline documentation) just due to the reason
that the API is not completely stable yet. You could also try
different use-cases and maybe find some examples where the API lacks
some features.
 - 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.
 - Geographic Mapping: It's very experimental, missing different
projection modes (eg. vertical projection) and especially the Nasal
API feels very hackish.
 - Picking: For mouse handling some kind of picking would be nice. As
already mentioned, at least bounding box intersections will be needed.
 - Animations: I don't know if we should do animations just be using
interpolator and settimer from Nasal or if we should implement some
time-based animations directly in C++. At least we need some helper
functions (eg. for blinking elements -> cursor, fading, ...)
 - Improve PUI to allow eg. receiving mouse over events.
 - Improve the Nasal API: Add some helper functions for animating
different glass cockpit displays (I have already some basic code, but
it needs some generalization).
 - Implement some widgets in Nasal.
 - Check what is missing to implement the different hardcoded instruments.
 - Allow placing images inside the canvas.
 - Maybe support displaying shapefiles.
 - I also want to unify the canvas creation a bit, such that canvases
can be moved seamless between the different placements (gui, model,
hud, etc.). The normal model placement is great but the gui widget
placement needs to be able to also use an already existing canvas.
 - Support copy&paste: I'm working on the selection part, but have no
clue yet on how to access the system clipboard.
 - Find more work I've currently forgotten about :)

Please also have a look at the wiki [2]. There is already plenty of
brainstorming outcome and also information about some current


[1] http://keith-wood.name/svg.html
[2] http://wiki.flightgear.org/Canvas

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