I think the python annotation could be improved to be more generic and versatile.
There is a few axes of improvements :
Let the user import any python modules
Simplify the construction of complex expressions
Use a better editor
A simple way to fix this from a user point of view is to use, instead of a one-liner, a more “ProgrammableAnnotation” approach, where a specific variable, let say, output, should contain a string at the end of the execution of the python script. This string is then processed by the same mechanism as the current python annotation.
This basically fixes all three problematic exposed here.
Of course, we could ensure retro compatibility by still evaluating one-liner as a potential output string directly.
Alternatively, adding a field for the user to specify which python modules to import before evaluating would also be acceptable.
Can you provide an example please? It’s unclear to me why not just use a Programmable Filter, in that case? Is it that Programmable Filter cannot easily produce “text”? If so, maybe that’s what we need to fix.
A simple example is to show the current date using datetime module, but one could think of anything not already imported. platform, sys come to mind.
Is it that Programmable Filter cannot easily produce “text”?
Unless I’m mistaken, there is no way to create a text representation out of a programmable filter. I did not investigate how complex it would be but it would definitelly be more complex that adding a new output type as the representation needs to be a vtkTextRepresentation.
My vote would be to see how we can make this possible in Programmable Filter (or a new and improved version of the same). That should largely make Python Annotation obsolete, which sounds like a positive development to me.
Note, the Matplotlib rendering is not unique to Python annotation, it’s supported for all text representations even when the source is simply Text or Annotate Time. So yes, it would be supported.