It would be better to tell us exactly what you want to change, so that this can be made configurable - it should typically only take 20-30 lines of Nasal code to expose such things to some kind of UI (e.g. by clicking the display/screen). Alternatively, it would be possible to use instance specific properties for these defaults, and register a listener so that the fg1000 can apply any changes.
Regarding Thorsten's comment, that's true - what you will see in the /canvas/by-index sub-tree is basically a bunch of elements that are chained together in a cascaded fashion. While the Canvas system started out using solely the property tree, this is no longer the case - i.e. features added later on, would break this encapsulation boundary, so that most stuff involving the GUI, widgets and layouting no longer works primarily via properties, but via the so called cppbind mechanism - which is a much cheaper (faster) way to hook up OSG machinery to Nasal and vice versa - but obviously at the cost of not necessarily going through the property tree any longer, which is to say that certain stuff will break in multi-instance setups, or re-implementations of the Canvas system (think FQGCanvas).
It is out of this very realization that the people originally involved in prototyping Canvas instruments arrived at the conclusion, that the purely Nasal-based way of accessing the Canvas system is potentially problematic, because we are abandoning the property tree abstraction - especially in anything involving multi-instance setups (multiplayer, dual-pilot, FSWeekend/LinuxTag or FGQCanvas).such setups to work reliably
For the Canvas system to become future-proof, it would have to expose the simgear::canvas::Element API to scripting space, so that new/custom elements can be prototyped and implemented in scripting space, so that all crucial canvas state lives indeed in the property tree, so that such state can be propagated/synchronized (replicated) to other instances using solely properties.
While the corresponding elements would still be implemented in Nasal "as is", their interfaces would be better formalized by going through the sc::Element/PropertyBasedMgr structure, which in turn also provides for a sane way to deal with versioning and upgrading elements, even by re-implementing certain elements in native code, without any front-end code having to be touched at all.
Basically, our current way of using/exposing the Canvas system simply isn't very scalable, because it is too low-level for most non-coders, and it requires a fair amount of boilerplate code/machinery to deal with use-cases such as multi-instance setups.
This is why it is crucial to actually create frameworks to formalize/encapsulate such use-cases, or people will have to re-invent the wheel over and over again.
In other words, people not using the FG1000 approach (namely, Richard's MFD framework in conjunction with Emesary) are unlikely to come up with a structure that actually scales - so that such Nasal/Canvas contributions will continue to reflect badly upon Nasal and Canvas unfortunately - whereas it would actually be prudent to expose the core sc::Element/Group APIs to scripting space so that contributors can create their own Canvas based elements using the existing, and PROVEN, Canvas API: http://wiki.flightgear.org/Canvas_Devel ... FlightGearAnyway, if you really do have a need to navigate such a Canvas structure at run-time, it is fairly straightforward to open property-browser.xml and add roughly 30 lines of code to it, so that it can recognize any Canvas structure, and create a deep copy of the current node to render a preview of the group/node, which can be a great asset for troubleshooting purposes:
(the canvas widget can be trivially hidden/shown as needed, by evaluating the currently selected property path)