design vedo-based API carefully

[haesleinhuepf]

I would like to rename a lot of functions before merging https://github.com/haesleinhuepf/napari-process-points-and-surfaces/pull/23

Goal:

• functions that were there before should not be renamed or removed (backwards compatibility)
• new functions currently have the vedo_ prefix. This is bad practice. We should rename them.

[haesleinhuepf]

We can inspect the API of both versions like this

import napari_process_points_and_surfaces as nppas
dir(nppas)

And use tools such as beyond compare to reveal differences. The following functions should be renamed, again without overwriting pre-existing:

 'vedo_convex_hull',
 'vedo_fill_holes',
 'vedo_points_to_convex_hull_surface',
 'vedo_remove_duplicate_vertices',
 'vedo_sample_points_from_surface',
 'vedo_smooth_mesh',
 'vedo_subdivide_adaptive',
 'vedo_subdivide_butterfly',
 'vedo_subdivide_linear',
 'vedo_subdivide_loop',
 'vedo_subsample_points',

Potentially conflicting with these:

 'convex_hull',
 'fill_holes',
 'points_to_convex_hull_surface',
 'subdivide_loop',

What's the difference between vedo_subsample_points and sample_points_uniformly?

The name 'vedo_smooth_mesh' is suboptimal, as we call it surface in Napari, and not mesh.

All changes to the API should be documented carefully. I think it makes sense to write a short transition guide from 0.3.3 to 0.4.0 for users.

[haesleinhuepf]

https://github.com/haesleinhuepf/napari-process-points-and-surfaces/tree/api_changes_0.4.0