Difference between revisions of "IVAS Feedback/3.0"

From Northwestern University Center for Atom-Probe Tomography
Jump to navigation Jump to search
Line 2: Line 2:
 
==Bugs==
 
==Bugs==
  
When using the clipping control for a large( z > 1000 nm) dataset, I kept getting "not a valid number" when I tried to manually type in values for the z range.  This is even though they were positive integers that were less than the end z value... When using the slider bar I didn't get any error message.
+
When using the clipping control for a large( z > 1000 nm) dataset, I kept getting "not a valid number" when I tried to manually type in values for the z range.  This is even though they were positive integers that were less than the end z value... When using the slider bar I didn't get any error message.  Also, if I removed the comma from the fields, I didn't get the error message.
  
 
==Feature Requests==
 
==Feature Requests==

Revision as of 10:59, 10 November 2006

This feedback will be sent to Imago based on demand. Feedback presented at the training meeting has been moved to IVAS Feedback/3.0/training. Please sign your comments with four tildes (~~~~).

Bugs

When using the clipping control for a large( z > 1000 nm) dataset, I kept getting "not a valid number" when I tried to manually type in values for the z range. This is even though they were positive integers that were less than the end z value... When using the slider bar I didn't get any error message. Also, if I removed the comma from the fields, I didn't get the error message.

Feature Requests

API/Scripting and Batch Processing Enhancements

  • An API would be nice
    • It would be nice, but David doesn't know when we'll get one. It doesn't sound like plans to add one have been canceled.
    • Regarding the API. As you might have noticed IVAS has changed quite a bit since 2.3. While the GUI shouldn't see drastic change in the future, the underlying implementation of certain functionality will still be subject to some drastic changes. We are still at a point where we can't publish an API and be certain we are able to maintain it from release to release. Also, we don't have any internal customers who would utilize this feature so it's been very hard for the development team to determine what the proper scope should be. If you could give me an prioritized list of what you would want access to it might help us to start targeting stability in the various APIs we implement and use. Note that I can't commit to delivering anything, but it's never too early to start.

Specific wants for API

Please re-order by your priority!

Documentation!
  • Even minimal documentation (auto-generated javadoc or doxygen would be fine to start with) on all classes which could be accessed from jython would be immensely useful
  • This could be fairly easily expanded so that we'd know what was "stable" and what may be changed
  • For stable and commonly used methods, more helpful/detailed (human-generated) comments would be the nest step
  • Finally, some particularly useful methods may benefit from examples
Precipitate properties
  • A stable way to access the ellipsoid methods used in precip.py
ROIs
  • A method to get a list of all ROIs and a mehod to return properties on an individual RO (to sort/select them by area/volume/roughness)
  • A method to generate a proxigram on a given ROI
  • A method to export the proxigram to CSV
  • A method to export a POS for a given ROI
3D window interaction
  • A method to insert text in the 3D analysis window
  • A method to draw basic shapes (the cube/cylinder/spheres (without locked aspect ratios))in the 3D analysis window

Questions