Philosopher wrote in Wed Nov 06, 2013 8:22 pm:Okay, I think I'm beginning to get what you're saying. *.draw still needs to provide the drawing routines, but *.model should provide the predicates for drawing them... I'll have to think about a controller; would that just be commands that say "please update since
this changed"? I'm leaning towards calling update() every frame anyways...
Originally, the idea was that we want to avoid the ongoing degree of copy/paste programming that could be seen in the airport selection dialog - next, the 744 ND duplicates lots of code used in the airport dialog, but also in the underlying framework - all without using inheritance or delegates/predicates to customize things. So over time, we would end up with tons of custom code that is highly specific to each aircraft/display and GUI dialog.
From a low-level point of view, it shouldn't matter to the draw routines if they're called by an aircraft instrument or by a GUI dialog. However, once they contain use-case specific logic, such as getprop() calls and other conditionals, things do get messy pretty quickly. Thus, what I have been doing is simply copying things to separate *.draw files for different scenarios, i.e. I now ended up with airport.draw and airports-nd.draw for example - that isn't all that elegant, but at least it solves the problem of having to implement full models and controllers for each scenario (well for now), because all the embedded logic can stay, and only needs to be refactored later on.
Thus, the idea is basically this:
*.draw files contain the low-level logic to draw arbitrary symbols (runway, waypoint, taxiways, airports, traffic) - without knowing anything about the frontend/user - so that such details needs to be separately encapsulated. The *.model files merely determine what is to be drawn, data-wise, as in NasalPositioned queries and their results - all stored in a single Nasal vector. The layer files turn everything into a dedicated canvas group that can be separately toggled/redrawn/updated - the currently missing bits are controllers that tie everything together, so that each frontend (instrument, MFD, GUI dialog, widget) can separately specify and customize behavior by registering their own callbacks.
Most of this is already working here (with very minor regressions so far that Gijs won't be too happy about ...), but otherwise I managed to turn Gijs code into layers/models that can be directly used by the old framework, i.e. I can now add a handful of new ND layers (fixes, vor, MP or AI traffic, route etc) to the airport selection dialog (or any other dialog actually), and things do show up properly.
What's still missing is the controller part, and styling for different aircraft/GUI purposes - also, Gijs' ND routines are currently used directly, without any LOD applied - but I think that can be easily solved by using the canvas's scale() method.
For now, I'll just upload/push my changes, fully realizing that I introduced a few regressions - but the point is that those are relatively easy to solve, and that the map dialog can now even be re-implemented just by editing an XML file (unless there are layers that we're still missing?). Likewise, a route widget can now be added to the route manager dialog, all using Gijs' backend code, which is now shared.
I had to add quite a few hacks to support things without major refactoring, but at least there's fair degree of code sharing possible now.
EDIT: Here's the whole mess:
https://gitorious.org/fg/hoorays-fgdata ... canvas/map @Gijs: Probably it would be a good idea if you could quickly test things and report back all regressions that you noticed, some stuff is probably more obvious to you than anybody else - otherwise, I'll try to get rid of the known issues over the next few days/weeks.