[Smtk-developers] SMTK python script

[Yumin Yuan]

On Thu, Oct 30, 2014 at 10:23 AM, David Thompson <david.thompson at kitware.com
> wrote:

> Hi Yumin,
>
> I'm including this on the devel list because... well, it's a shiny new
> mailing list. :-)
>
>
Right, I was too focused to see the shiny new list  :)


> > ...
> >>> I think an "import" operator may fit better here since we may need to
> handle other file formats that CMB used to load.
> >>
> >> In terms of the SMTK API, I agree that it should be a separate
> operator. But from the application perspective, a user does not want
> importing a model to be a multistep operation where first an empty model of
> the proper type must be created before running the import operator on it.
> This is complicated by the fact that SMTK provides a list of file
> extensions that each modeling kernel+engine combination can read (using its
> "read" operator). How would we handle the file formats added by "import"?
> >
> > Perfect timing for this discussion, because I am working on getting
> vtkCmbMoabReader (with CMake option to build or not) into smtk. I am
> planning to use the same pattern as the cgm bridge, ie, using the
> hand-edited Bridge_json.h to add file types supported by this reader (if it
> is built) to the discrete bridge, then ...
> >
> >> I see 2 ways to go about it:
> >> 1. Keep everything in the "read" operator but find a way to mark some
> file formats as native and others as "import" formats. The operator would
> then internally either read or import based on the format.
> >>
> > I am leaning toward this approach, since 1. "import" still needs a
> "read" first, then 2. builds a cmbModel from its output, and finally 3.
> converts cmbModel to smtkModel. For a cmb file, we only need 1 and 3.
> Eventually (in the far far future), we could possibly make "import" skip 2
> too by directly building an smtkModel from read's output.
> >
> > I am not sure what "mark file formats" as native and import will help,
> the read operator will still need separate logic to handle the "import"
> file formats like 2dm, 3dm, map, poly, vtk, exo, etc.
>
> The benefit would be that users understand
> 1. They will not necessarily be able to save changes back in the original
> file format.
> 2. Not all of the features in the original file format are necessarily
> supported.
>
> Also, it lets the application choose a better default kernel if one
> supports a format natively while another can only import the format.
>
>
Yes, I understand the benefits of differentiating "import" and "native"
file formats from user's perspective. I was inferring to the implementation
of the handle-all-formats "read" operator without an "import" operator. In
any case, the application should probably give some hints on "read" vs
"import".


> >> 2. Add an "import" operator and include information about it in the
> Bridge's metadata. Then the application would know which bridge to create
> for the desired format and to use the "import" operator instead of "read".
> >
> > This seems to move more logic to application.
>
> Yes, but it makes an important distinction, plus it keeps the read
> operator smaller and more focused.


Agreed, but I would rather the Bridge handle logics to do "read" vs
"import", meaning the application code should just tell the bridge to load
a model given a file name. We could add some UI hints (coming from bridge)
in file open dialog so that user knows "imported" vs "native" file formats.


> It would not be a lot more code. The JSON for the bridge would change from
> something like:
>
> { "kernel": "cgm",
>   "engines": [
>     {
>       "name": "ACIS",
>       "filetypes": [
>         ".iges (Initial Graphics Exchange Specification)",
>         ".igs (Initial Graphics Exchange Specification)",
>         ".sat (Standard ACIS Text)",
>         ".sab (Standard ACIS Binary)"
>       ]
>     }, // ...
>   ]
> }
>
> to
>
> { "kernel": "cgm",
>   "engines": [
>     {
>       "name": "ACIS",
>       "filetypes": [
>         ".sat (Standard ACIS Text)",
>         ".sab (Standard ACIS Binary)"
>       ],
>       "importformats": [
>         ".iges (Initial Graphics Exchange Specification)",
>         ".igs (Initial Graphics Exchange Specification)"
>       ]
>     }, // ...
>   ]
> }
>
> We could just have BridgeRegistrar::bridgeFileTypes and
> BRepModel::bridgeFileTypes return StringData instead of a StringList (i.e.,
> a map from string->vector<string> instead of a vector<string>) with "read"
> returning the list of kernel-native formats and "import" returning the list
> of files that can be read via the "import" operator. This also lets us deal
> with "write" and "export" down the road.
>
>     What do you think?
>


That looks good to me. I could use the map to add UI hints of "import" vs
"native"

Yumin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20141030/ffda9629/attachment-0001.html>