It would help me if you comment your own work, your goals and non-goals.
Happy to.
I'm aiming at providing
a toolkit for creating aircraft-specific dialogs with canvas at the expense of calling just a few lines of code (as mentioned earlier, if one had a parser one could do this from xml, but many aircraft creators are familiar with canvas from instruments anyway).
The idea is that you use raster images for the layout, onto which canvas path and text element widgets are drawn procedurally - so for a typical dialog you'd
* create a canvas
* create the unchanging design as raster image and load it into the background
* create the changing elements in the init() method of the dialog by instancing widgets with certain parameters (which may in turn use raster images)
* move them to their position using setTranslation()
* update the dialog elements in an update() method as long as the dialog is open (such that graphics is generally automatically updated by just changing the value)
This'll have clickable switches (using indexed raster images for the switch state), drag'n'drop of elements, optional context help when hovering the mouse over an active element), and whatever else looks nice.
Click events can either be assigned to a widget itself or, using the clickspot widget, to an active area of the background image.
In addition, largely from creating the Shuttle HUD and PFD, I have a lib of procedural element generation functions for e.g. drawing a ladder (useful for HUDs) etc.
The main advantage of doing this procedurally as compared to SVG is that if you mess up the ladder spacing in SVG, you have to re-do it all - if you do it procedurally, you just change the parameter and it's good. That's kind of similar in spirit to what your grid and dashed line functions do.
I'm currently developing all of this inside the Shuttle repo to have a concrete use case and periodically move the generics to FGData.
It'd be good if you take a short look into
https://sourceforge.net/p/fgspaceshuttl ... al/canvas/canvas_widgets.nas are the dialog widgets, they're instanced in
canvas_dialogs.nas - currently you can study a (rather involved) example of the propellant dialog where you can add a child window for details of every tank and the temperature distribution
canvas_draw.nas contains simple shape functions which return elements, if you want to see a use case
https://sourceforge.net/p/fgspaceshuttl ... D_main.nasis the HUD - completely SVG-less, it's all drawn by calling shape functions for the various elements.
May I suggest you look a bit into the code, perhaps (if it runs for you) fire up the devel version of the Shuttle in orbit and look at the dialogs how you like the concept - and then we can discuss better whether we ought to join forces or provide separate toolkits.