Hello devs! Happy new year!<\/p>\n
It is common to use the new year date to start new projects or give new directions for old ones. The last one is the case for Cantor<\/a>.<\/p>\n Since when I got the maintainer status<\/a> for Cantor, I was working to improve the community around the software. Because the great plugins systems of Qt, it is easy to write new backends for Cantor, and in fact in last years Cantor reached the number of 11 backends.<\/p>\n If in a hand it is a nice thing because Cantor can run different mathematical engines, in other hand it is very common developers create backends, release them with Cantor upstream, and forget this piece of software after some months. The consequence of this is a lot of unsolved bugs in Bugzilla, unexpected behaviours of some backends, and more.<\/p>\n For instance, R backend is broken from some years right now (thanks Rishabh it was fixed<\/a> during his GSoC\/KDE Edu Sprint 2017 but not released yet). Sage backend breaks for each new release of Sage.<\/p>\n Different backends use different technologies. Scilab and Octave backends use QProcess + Standard Streams; Python 2 uses Python\/C API; Python 3, R, and Julia use D-Bus.<\/p>\n In addition to these, remember each programming language used as mathematical engine for Cantor has their respective release schedule and it is very common new versions break the way as backends are implemented.<\/p>\n So, yes, the mainternhip of Cantor is a hell.<\/p>\n In order to remedy it I invited developers to be co-maintainer<\/a> of these respective backends, but it does not have the effect I was suposed to. I implemented a way to present the versions<\/a> of programming languages supported in the backend but it does not work well too.<\/p>\n So, my main work in Cantor during these years was try to solve bugs of backends I don’t use and, sometimes, I don’t know how they work, while new features were impossible to be planned and implemented.<\/p>\n If we give a look to Jupyter<\/a>, the main software for notebook-based mathematical computation, it is possible to see this software supports several programming languages<\/a>. But, in fact, this support is provide by the community – Jupyter focus effort in Python support only (named the ipython<\/a> kernel) and in new features for Jupyter itself.<\/p>\n So, I would like to hear the KDE and Cantor community about the future of Cantor. My proposal is split the code of the others backends and put them as third-party plugins, maintained by their respective community. Only the Python 3 backend would be “officially” maintaned and delivered in KDE Applications bundle.<\/p>\n This way I could focus in provide new features and I could to say “well, this bug with X backend must be reported to the X backend community because they are accountable for this piece of software”.<\/p>\n So, what do you think about?<\/p>\n","protected":false},"excerpt":{"rendered":"