Simplified wrapper for C++, Python and JS/TS

[dpasukhi]

Description

New layer need to be added for simplification and consistent API.
Python layer needs to became replacement for TCL tests.
Update planned for that year as beta version as poc. Architecture and API can changed up to 8.0.0 versions.

First version, to preview: https://dpasukhi.github.io/OCCT-Light/guide/getting-started.html

Patch will be merged into original OCCT repo, except the web page with samples,which will be separated repo.

Use Case

Python coding, simple c++ integration, front-end.

Benefits

Simplified API single for a few languages

Additional Context

No response

[adam-urbanczyk]

Looks interesting, what is the planned feature coverage? I.e. could stop using OCP in the long run?

[dpasukhi]

I assume all high level API will be covered.
The main difference of all existed wrappers and LOCCT is API. New classes have totally different names and methods.
Also, the idea of project -hide all the low level code and provide only hight level commands.
It means, if you do something low-level, then it will be complicated to migrate. But if you use something straight forwards - yes. It will be smooth migration.
For now the existed https://dpasukhi.github.io/OCCT-Light/api/ is a sample which I was planning to cover.
For now the next iteration of OCCT Light is slightly different, but the idea the same.
_
The project will not use SWIG, There will be all JS and Python custom wrappers to provide more clarity. (not automatic, but manual)

[trelau]

nice idea. will this be distributed as part of OCCT? or a different project? i've been using/working on python bindings for OCCT (started using pythonocc-core, then eventually wrote my own for a while). i'm not attached to the python bindings, in fact lately i started to write my own thin C++ API for Python because wrapping all of OCCT is a headache. this seems very similar to "light occt" in spirit, although the API design i was following was wrapping more types that just Curve, Surface, etc. this isn't published anywhere just a local project i've been playing with.

anyway, in my case i'd like to be able to generate meshes for FEA/CFD and have so far been using SMESH for that (and pySMESH for the python bindings). But again, binding all this low-level C++ stuff is a headache...

would a "light SMESH" that pairs with "light OCCT" make sense someday?

[dpasukhi]

Smesh is not a part of OCCT and will be not targeting to that project.

[trelau]

understood. i was thinking, outside of OCCT, about conceptually following the same design patterns as "light OCCT" to build a "light SMESH" project is all.

[dpasukhi]

Light OCCT will be external project and will combine more 3rd party as a module.
It will depends on OCCT and OCCT will depends on LOCC because it will be used for python tests.
Maybe in the future Smesh will be added as a module, but originally it will be not designed in the same manner

[dpasukhi]

The publishing is a little delayed.
We are continue to work on that task and it will be released in coming weeks.