MathPlayer replacement -- interface suggestions wanted

[NSoiffer]

This is tangentially related to #9039 (MathPlayer COM problem... maybe).

I am working on a replacement to MathPlayer because WIRIS won't allow me to update/fix MathPlayer. The replacement will be open source. I've made some good progress on it and just started on the COM interface. The replacement is written in Rust (I wanted to learn something new). Rust's COM support is still in flux and I'm having trouble with it. Rust has a library that provides a python interface that I've just started to play with. It makes the Rust code look just like a python module as far as a python coder is concerned (although it is MUCH faster ;-).

Here's my question to developers, especially those dealing with COM issues/interface issues: would it be better if I avoided COM in the rewrite? I originally was planning on "cheating" and reusing MathPlayer's UUIDs so that no code in NVDA would need to change to support the new MathPlayer. But the problems with COM in Rust have caused me to question this, and #9039 (and other) COM problems further make me question this idea. Would it be better if I avoided COM?

[ABuffEr]

Hi @NSoiffer ,
is there a public accessible repo of your work?
I have always dream a open-source replacement of MathPlayer, performing better than this and providing more flexibility and customization. I don't know Rust, only Python, but I'd be happy to learn and contribute, if possible.
In any case, good luck for your project! :)

[Adriani90]

cc: @feerrenrut, @michaelDCurran

[XLTechie]

Might this be good to raise on the dev and/or addons lists also? https://groups.io/g/nvda-devel https://groups.io/g/nvda-addons

[NSoiffer]

@ABuffEr: I haven't moved it to github yet as I'm am still getting a feel for the way to write good code in Rust. To be honest, I'm still a little embarrassed about the code. Also, I've still have a few major pieces to add (such as the interface) and want to get the structure down a little better before inviting people to join in. I expect I'll move it to github in late April or early May. A beta will likely be in May and the first release in July (based on some time estimates/progress I've been making). Part of the design makes it easier to write speech rules (which partly uses xpath) than it is in MathPlayer and that is an area where I definitely hope to get help.

For those who don't know Rust, it is a lower level programming language that is very strongly typed and enforces memory management very strictly. In many ways, it is the opposite of Python and JavaScript. You either hate it (probably the majority of programmers) or love it. I've found very few bugs after I get the code to compile, but that first step takes MUCH longer than in Python and JavaScript.

[NSoiffer]

@XLTechie: thanks for your suggestion. I will post this question to the nvda-devel group.

[CyrilleB79]

Hi,
Are you aware of Access8Math add-on? If yes, could you highlight the similarities or the differences?
Thanks.

[CyrilleB79]

Also cc @tsengwoody the author of Access8Math

[Adriani90]

Mathcat replaced mathplayer so far, I am closing this as completed. If you still need any clarifications, please open a new discussion.