www2 wrote:how soon i can except canvas, settimer and navdb api in python?
As you can see, I am not generally opposed to the idea of Python support in FlightGear, but I somehow doubt that having support for the Canvas system will provide what you are hoping for - so maybe you could fill us in and tell us what you'd like to do exactly ?
Keep in mind that the Canvas system is running in the single-threaded main loop, and it is directly rendering related (most of it is using native OSG code, unlike other legacy code using raw OpenGL). In other words, Canvas is really just an abstraction mechanism for 2D rendering - and it is doing that using the property tree, which it treats as a "dump space" for events, where you can create a hierarchy of primitives and trigger events to create/update/animate/transform and remove primitives that reside in the global FlightGear property tree.
For the time being, the whole Canvas system is a conventional SGSubsystem, where each "canvas" is represented in the form of a RTT/FBO (offscreen rendering context), so textures get basically updated sequentially (with a few exceptions, mainly nested Canvases, i.e.a texture referencing another Canvas via a sub-texture lookup).
Also, Canvas is primarily a FlightGear specific technology, i.e. it's OSG code mapped onto the FlightGear property tree code to trigger C++ method calls, so unlike most existing libraries, there is not much of a technology stack outside SG/FG when it comes to Canvas. The primary bindings/code is available in FlightGear, and happens to be in written in Nasal.
That being said, once bugman has provided integration with properties and the global property tree, you could -in theory- access the global tree and trigger events in /canvas/texture[x] to create/update textures dynamically - so you don't need much in terms of explicit bindings to do that.
To see for yourself, I suggest to use the telnet/httpd interfaces to modify a Canvas dynamically, e.g. a tooltip or the Aircraft Center dialog (while it is shown) - you will find that you can directly manipulate the sub-tree without any Nasal code whatsoever.
So at the end of the day, it all boils down to what your goals are here - because Python support may not buy you much.
If you are hoping for multi-threading, that is a completely different issue - and it would require establishing the "one-tree-per-canvas" concept, so that each texture maps to a private property tree that is owned by the SGSubsystem/SGThread, so that Python (or Nasal) can safely lock/access it, without much impact on frame rate/spacing.
Obviously, that would then also mean that the same tree would no longer be safe to mutate/modify from other threads, including the main thread. But it would mean that people could have worker threads per Canvas texture, which could be mapped to osg::UpdateVisitor for better efficiency.