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 features. Regards, Tom [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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
