TheTom wrote:Thorsten wrote:Say, we get a map displayed, and there are drag-and-drop symbols of low pressure areas, fronts,... to the right, we drag them to the map, edit pressure values and so on, and the weather engine then converts this into winds, cloud configs etc.
It'd be rather easy to modify the weather engine to do that, just the GUI scared me quite a bit, but this seems entirely capable of handling the problem.
If you don't know how to implement a certain type of widget/gui/dialog just tell me what you want to achieve and I will tell you what you need to too, or I will implement what is missing. Now it's a good point helping to shape the API
It would take us (i.e. the MapStructure guys) roughly 50-100 lines of code to allow "map" layers to be "dynamic" in the sense that tooltips can be registered and so that mouse events can be handled by each layer, i.e. to freely move symbols around on a map, and invoke callbacks once a mouse button is released, e.g. to call geo.put_model() and/or write stuff to XML or call some arbitrary Nasal/AW APIs (e.g. showing another dialog to edit settings). I played with this a while ago when Bomber came up with the whole "chain home" idea:
Conceptually, this would not even have to be a hack or workaround, we really only need to add a few base classes that can be used by the lcontroller files to receive the corresponding notifications, so that each "interactive" layer would just implement the corresponding interface by providing 2-3 methods.
And as can be seen in the other thread, we've started turning MapStructure into a generic/reusable Canvas widget, too:
Personally, I kinda prefer that approach because it would be pretty consistent and it would allow us to reuse the same code that is ultimately used by maps/MFDs.
However, the type of coding involved in Canvas/GUI is very different from the type of code used in Advanced Weather, i.e. pretty focused on OOP, data structures and events/callbacks, as well as OpenVG and SVGs. But if this is something that you'd be interested in, I can help and come up with a working prototype that you could extend over time.
Capabilities-wise, you'll probably feel right at home, because there's Canvas functionality that's overlapping with your GLSL/effects background, i.e. dealing with textures, overlays/layers, rendering masks, texture maps, clipping etc. Conceptually, you can consider a Canvas like a texture that has various bounding boxes for which listeners (Nasal callbacks) are registered, which is used to handle GUI events like click, double click, mouse move (hover) etc - the corresponding callback can then transform elements on the canvas, i.e. to animate something. Most Inkscape SVG files can be directly used by the Canvas system for all kinds of purposes - transformations are typically timer/listener based.
For the sake of completeness, the other possibility would be using TorstenD's mongoose work to provide a HTML5/JavaScript-based browser GUI that directly gets/set properties