[Smtk-developers] Pie in the sky

[David Thompson]

> In this configuration, where would the Pybind11 binding code and nlohmann json code go?

I assumed they would stay as subdirectories of whatever source they wrap/serialize, but we could move them up to

  core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx}
  core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx

  extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx}
  extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx

if you prefer.

	David
> 
>> On Mar 20, 2018, at 4:06 PM, David Thompson <david.thompson at kitware.com> wrote:
>> 
>> Hi all,
>> 
>> Following up on the "pie in the sky" talk we had at the meeting today, what about this directory-structure change to go along with the attribute-collection/model-manager/mesh-collection rename:
>> 
>> core/smtk/{PublicPointerDefs,SharedFromThis, ...}.h
>> core/smtk/{attribute, mesh, model}/Resource.{h,cxx}
>> core/smtk/model/Session.h
>> 
>> extension/smtk/model/polygon/{Resource,Session,...}.{h,cxx}
>> extension/smtk/paraview/{server, components, ...}
>> extension/smtk/qt/{qtAttributeView,...}.{h,cxx}
>> extension/smtk/vtk/{source, ...}
>> 
>> testing/smtk/{attribute, mesh, model}/{cxx,python}/...
>> 
>> applications/{template-editor, attribute-preview, ...}
>> cmake
>> data
>> doc/{userguide,tutorials,reference}
>> python/smtk/{__init__.py, testing.py, simple.py}
>> utilities
>> 
>> Everything in core would become smtkCore. Subdirectories of extension/smtk would be separate projects with their own library(ies). In the end, projects in both core and extensions would install their public headers to ${CMAKE_INSTALL_PREFIX}/include/smtk/.... That way, directories could always correspond to namespaces (starting with "smtk", not core or extension) and there wouldn't be a question any more about whether Qt stuff should live in smtk::extension or not -- if it lived in a namespace at all, it would be smtk::qt.
>> 
>> Moving testing out of the core directory would make it clear that tests could depend on extensions (such as polygon/discrete/mesh model resources). Tests would live in the directory/namespace of the most abstract thing they tested, so a test of the model resource that just happened to use a polygon model would live in testing/smtk/model while tests of the polygon session would live in testing/smtk/model/polygon.
>> 
>> 	David
>> _______________________________________________
>> Smtk-developers mailing list
>> Smtk-developers at smtk.org
>> https://smtk.org/mailman/listinfo/smtk-developers
>