Provide a status, timeline and ultimate ambitions for Python (and PyCharm) support.

[resmond]

I'm a thirty year plus system level developer in C / C++ (and assembly on occasion) who has always found it annoying to resort to JavaScript for a modern UI.

Then TypeScript came along and took some of the sting out of the performance hit by offering such amazing structured creativity to sooth my efficiency annoyance.

Now Python is becoming similarly interesting by providing an 'on-ramp' for the developers (like me) to experiment with creativity in both structured typing and also adaptations of the syntax and platform itself, which opens the door to dramatic gains in efficiency and performance as opposed to trading such for syntactic sugar.

As far as I can tell in 4-5 hours of delving through your GitHub comments and release notes it appears then Slint might providing a very interesting ingredient for bridging between Python, Rust and C++. No performance related Python applications perform core computation in the interpreter. Numpy, Numba, Cython and/or custom C++/Rust functions are just a few of the options available for the heavy lifting but when it comes to UI its usually plain old Python that is used.

It seems to me that Slint, with it's ability to integrate the majority of those platforms to a single UI could be a very powerful avenue for avoiding having to move data back up through the boundary layer into Python simply to push it down again to get it to the screen. This is especially true when Python code becomes the filter/transform mechanism for that connection between computed results and the UI.

I'm very interested in seeing what can be accomplished at the boundary API layer to allow Python to define the pathways and transformation parameters at the scripting layer and then let C++ / Rust do their magic to provide a efficient pipeline to do the work.

My ask is this:

1. Provide some guidance on when Python will be moved from Alpha to Beta
   *) Be listed as a supported language / platform on the Slint landing page
   *) Have an entry for progress notes for releases, etc
2. Provide some guidance on the ultimate goals for Python and also SIMD / GPU support
   *) Python / Slint developers will be seeking performance-computing at scale
   *) Dropping down into C++ & Rust to get SIMD / Cuda options is intoxicating
   (just have to make sure that nothing Slint-related is in the way)

So, those are my thoughts. I am very much impressed with what you have done and grateful that another Python UI library developer called Slint out as an alternative to his own with positive things to say. I love the opensource community ethos.

Be sure that I will be watching for any feedback or thoughts.

Richard Esmond
[email protected]

[tronical]

Hey Richard,

Thanks for the detailed post :). You'll be delighted to learn that in our next release in the coming days, we're promoting the Python APIs from Alpha to Beta. This includes being listed as supported language in the Slint Language Documentation landing page, reference documentation, as well as typings for mypy. We'll also more prominently mention any changes in the change logs now.

Provide some guidance on the ultimate goals for Python and also SIMD / GPU support

Generally speaking, there are many ways to access GPU exposed functionality with Python. One of the things we've been eyeing lately is wgpu support in Slint, for which also Python bindings exists. Our philosophy is to have interfaces in Slint that permit combining Slint with other powerful libraries, so as such we're interested in the ability to combine the output of other WGPU based renderers (for example using Python) with Slint, by integrating textures.

Do you have a specific use-case in mind here?

[resmond]

Thanks for taking the time to provide some very meaningful insight into what is going on and I recognize who you are from all of my hours walking through years of your commits. Thank you for your service! :)

What I have been working towards is fairly ambitious.

I have made a personal commitment to two open source projects related to Computer Aided Design / Modeling and Computer Numerically Controlled Machining / Manufacturing.

They are:

• FreeCAD
• LinuxCNC

Each of these projects represent ecosystems that have evolved over three decades to become amazing open-source platforms around which to build solutions for manufacturing for hobbyists on up to mid-sized organizations.

What I am hoping to help facilitate is to internally align these two independently evolved projects into a single hybrid set of libraries and versions that could be used by both teams and be greater than the sum of the parts.

Each of these teams is small but committed and brings tremendous expertise to central challenges that are shared by both platforms - and by fortuitous coincidence they each chose very 'similar' methods / platforms for their development:

• Qt
• Python
• C/C++
• LinuxCNC is Linux only, but FreeCAD absolutely thrives on it as well

The challenge will be that under the covers their are differences in versions and support / glue libraries such as PyQt(4/5) / PySide2 / PySide6, etc. Each of the teams wishes to re-sync to newer versions, so that is where I'm targeting my initial contributions. I just need to get my skills equal to that task as quickly as possible.

You can use these freely downloadable 'Drawing' package to envision some part you wish to bring into existence on your hobby CNC desktop router, but then you find out that there isn't any magical [Preview / send to Printer] button where you can Tab through some default settings and watch the show.

The 'glue layer' between CAD and Execution of complex three-dimensional motion control involves all kinds of personal investment in self-education, learning through failure and very often custom assembly and integration of various components.

When an excited hobbyist researches desktop CNC routers that are 'plug & play' they don't realize they 'play' is the operative word unless you are talking about high-end professional systems. Replacing the hardware / software the drives the stepper-motors and learning how to integrate that all together is a total bitch!

That is the remaining challenge that I'm hoping to engage with and bring the expertise at building custom graph-engines to some very similar problems I see here.

When I ran across SLint it immediately looked like something that I needed to start making an investment in learning.

But I hope to be able to do a test integration of my code-base with Slint in the next week or two.

Talk to you soon,

Richard Esmond
[email protected]