KDE Edu Sprint 2017

My first KDE sprint. I am glad that It finally happened!

A day before I left for Berlin, I did not even have my VISA. Well, everything from getting the VISA to booking the flight tickets and finally packing the bags happened a day before I left for Berlin

We all landed in Berlin on 6th, a day before the sprint started. I think we all took a lot of rest that day because most of us were tired with all the traveling. We all met on 7th Morning at the reception of the hotel we were staying in where I finally got to meet people I only knew through IRC nick names. From there we headed to have some breakfast and finally to Endocode where our sprint took place.

Before we started working on our tasks, we had discussions regarding how to make the KDE Edu website better, making applications easily accessible to Universities/schools etc. We prepared a list of tasks that could be done during the sprint and finally started working on them.

I mostly worked on Cantor,completing some part of what I could not complete during GSoC. After a few discussions and help from my mentor Filipe, I merged some of my to work  to qprocess_port branch   and started working on polishing the R backend of Cantor. Filipe plans to release a new version in December, for which he plans to merge my work for R backend to master and for that to happen I need to make the syntax highlighter and tab completion of R backend work. I completed some part of it during the sprint.

I also had discussion with Timothee regarding GCompris-Server , showed him my work and discussed what should be the next step for it

Well, that’s all I did. I had a great time throughout the sprint and It was a pleasure meeting fellow KDE developers and specially my mentors Filipe and  Timothee

Here’s a picture we took(without Aleix and David)  just outside of where Qt world summit happened. Aleix was finding a new place to stay(If i remember correctly) and David had some other work. 20171008_210244


Big Thank you to KDE e.V. board for sponsoring my trip and Endocode for providing us a office and access to unlimited drinks and a weird bottle opener 🙂


GSoC – Port of R to QProcess

Hello, this post will be about what all targets I completed , what’s left and what I did during the last month.

During the first two months I had ported 2 back ends to QProcess, which includes Lua and Qalculate. For the last month I was left with 2 more backends , which were  R and Python .  Due to time constraint I decided that I will be working on just one of the two. Python’s code base was a bit large because of the two versions of Python(2.7 and 3), hence I decided to work on R.

Cantor’s R backend was broken, so my job to was to get it in a working state and make use of QProcess for all the communication.

R’s backend architecture was a bit different from the rest of the backends. It was divided into 2 parts

1.  RServer:
This is a separate application, that uses the R-API to run commands,
and exposes it’s functionality over DBUS

2. R backend
This implements the Cantor interfaces, and starts the RServer. It delivers
the commands to the server over DBUS, and connects to it’s signals to get
the result.

Due to such an architecture the code of R backend was quite complicated. To remove such complications we used R’s command line interface and made use of QProcess to connect to it. Instead of the multi step communication(rbackend->rserver->R API), we now have a simple one step communication(Rbackend->QProcess).

Previously R back end supported:
* Plotting graphs
* Tab completion
* Syntax completion(incomplete state)

Current Status:
* User can still plot graphs but the graphs are not integrated in the worksheet

* Tab completion- Not working. This used to make use of Rserver for getting the completions, but since we have disabled the Rserver tab completion is not working.

* Syntax higlighter – Same state as before. It just highlights the keywords(if,else etc) and not the built-in functions/variables of R

Overall, R back end is in a better state than before. We have more or less most of the functionalities working. The only thing that’s not working is tab completion. Hopefully in future we will able to make use of  R’s command line interface for tab completion. R back end also does not have support for variable management but it should ideally support this since R(language)  supports it.

With this most of what I planned to do during GSoC has been completed and the only back end left to be ported is Python’s.

The last 3 months have been great and a bit hectic for me, but nonetheless I enjoyed working on the  project. I plan to keep working on my project, complete what’s left and continue contributing to KDE.

I want to thank my mentor Filipe Saraiva  for being such a cool mentor that he is and for all the support he provided during the last three months

Lastly I want to thank KDE for giving me and others this opportunity.

Thanks and Happy Hacking 🙂


GSoC- Port of Lua to QProcess

Hi, it has been a bit long since I last wrote a blog about the status of my GSoC project. This has been majorly because I got a job and it has kept me busy ever since. Anyway, I managed to complete my second month target , mostly by working on weekends. Here’s a quick update on what I did during the 2nd month

I worked on porting Lua backend to QProcess. Lua backend was dependent on Lua’s C api for all the communication. By default Lua had spport for:
* Syntax highlighting
* Tab completion

Lua backend now makes use of Lua’s command line interface, which we connect to using QProcess. Most of the mathematical functionalities of Lua are offered through the math library. Here are some screen shots showing the output to different commands

Usage of math library



String manipulation/Os functionalities/arrays  lua_string


Current Design of Lua

* we make use of Lua’s command line interface for all the mathematical calculations or any other functionality offered by Lua’s  CLI

* Tab completion is still dependent on Lua’s C API. This should eventually be ported to make use of the command line interface as well.

All of the functionalities offered by Lua have been ported safely and nothing has been broken. As of now Lua does not have support for Variable management. I would love to work on it in future.

That’s it for this blog.

Happy hacking


GSoC: Weekly Blog


There’s a lot I did in the last 2 weeks and since I did not update the blog last week, this post is going to include last 2 week’s progress.

Before I begin with what I did, here’s a quick review of what I was working on and what had been done.

I started porting Cantor’s Qalculate backend to QProcess and during the first week I worked on establishing connection with Qalculate, for which we use qalc and some amount of time was spent parsing the output returned by qalc


Qalculate backend as of now uses libqalcuate API for computing the result. To successfully eliminate the direct use of API all the commands should make use qalc, but since qalc does not support all the functions of Qalculate, I had to segerate the parts depending on API from qalc. For instance, qalc does not support plotting graphs.

The version of qalc that we are using supports almost all the major functionalities of Qalculate but there are a few things for which we still depend on the API directly

I will quickly describe what depends on what

* help command
* plotting
* syntax highlighter
* tab completion

* basic calculations: addition, subtraction etc
* all the math functions provided by Qalculate: sqrt(), binomial(), integrate() etc
* saving variables

Segregating part was easy. The other important thing I did was to form a queue based system for the commands that are required to be processed by qalc


Queue based system

The two important components of this system are:

1. Expression Queue :- contains the expressions to be processed
2. Command Queue:- contains commands of the expression being processed.

* The basic idea behind this system is , we compute only one expression at a time, mean while if we get more expressions from user, we store them in the queue and process them once the current expression being processed is complete.

* Another important point is , since an expression can contain multiple commands, we store all the commands for an expression in command queue and just like we process one expression at a time, we are going to process one command at a time. i.e we are going to give QProcess only one command at a time, this makes the output returned by QProcess less messy and hence it’s easier to parse

* Example: Expression1 = (10+12, sqrt(12)) : this expression has multiple commands. The command queue for the same will have two commands.

expression queue                                               command queue

[ expression 1 ] ——————————————-> [ 10+12 ], [ sqrt(12) ]

[ expression 2] ——————————————-> [ help plot ]


We solve all the commands of expression1 , parse the output and then move on to expression2 and this goes on till the time expression queue is empty


Apart from this I worked on Variable model of Qalculate. Qalc provides a lot of variations of save command. Different commands available are:

Not every command mentioned below has been implemented but the important ones have been.

1. save(value, variable, category, title): Implemented

This function is available through the qalc interface and allows the user to define new variables or override the existing variables with the given value.

2. save/store variable : Implemented
This command allows the user to save the current result in a variable with the specified name.

Current result is the last computed result. Using qalc we can access the last result using ‘ans’, ‘answer’ and a few more variables.

3.save definitions : Not implemented

Definitions include the user defined variables, functions, units .

4. save mode: Not implemented
mode is the configuration of the user which include things like ‘angle unit’, ‘multiplication sign’ etc.


With this most of the important functionalities have been ported to qalc but there are still a few things for which we depend on the API directly. Hopefully, in the future with the newer version of qalc we will be able to remove the direct use of API from Cantor

Thanks and Happy hacking

GSoC – Weekly Blog

Hi, this is going to be a quick review of what I did last week

Just a little about how cantor works

Cantor is divided in two main parts:

Worksheets –  An interface that allows user to interact with available back ends. Each worksheet is associated with one back end

Back ends –  Back ends are implemented as plugins

The whole back end architecture is divided in several parts. I am going to discuss the ones on which I worked last week

* Back end – Stores static information about back ends, like name, version , what all features(syntax highlighting, tab completion etc) a back end supports

* Session – This is where a connection to back end is established and destroyed. To be specific, the method login() is used for initiating a connection  and logout() is used for ending the connection with back end

* Expression – Every command sent by the user is treated as an Expression . The class is also responsible for storing the result of the expression

Last week I successfully completed:
* Establishing connection with Qalculate back end
* Using streams for I/O
* Parsing the output returned by Qalculate


That’s it for this blog. If you have any questions/suggestions, please get in touch.


QProcess Or KProcess ?

1 month of GSoC is already over and the coding period has officially begun. Here’s a highlight of what I did and what I plan to do for this week

Most of the time of community bonding period was spent giving college exams. By the time my exams got over,  I only had a week left to make something useful of the community bonding period time.

The last week started with a discussion with my mentor , where we decided which API to use to port the back ends.  We had to  decide between QProcess and KProcess. Just a brief of what these APIs do:

QProcess is used to start external programs and to communicate with them. The communication between QProcess and the external program happens through channels. The three standard channels used for communication are
Standard output(stdout): supplies regular console output
Standard error(stderr): supplies the errors that are printed by the process
Standard input(stdin): provides input to the process

KProcess is no different from QProcess. It inherits QProcess and extends it by by some extra and useful functionality

Since a few of the back ends of cantor were already using KProcess, we had to decide whether we actually need KProcess or whether QProcess will suffice our needs. The best  way to  decide this  was to port a back end which makes use of KProcess to QProcess.

Port of Scilab to QProcess

The port process was pretty simple and did not take more than an hour to port and test. The test was performed  on various inputs including plot commands.
You can have a look at the commit that actually does the port
Since Everything worked fine, we decided to move forward with QProcess and use it for other back ends

Plan for this week

The very first back end I have decided to work on is Qalculate. Qalculate at the moment uses libqalculate library for all the calculations.
To get rid of libcalulate, we will be making use of qalc which is the command line interface for Qalculate
This week  I’ll be concentrating on setting up basic communication  between Cantor and  Qalculate using  qalc

Let the hacking begin!

GSoC 2017 with KDE


Hi! I am Rishabh. This post is going to be about what project I will be working on and how happy and excited I am about  spending the summers with KDE

First things first, I would like to thank the entire KDE community and especially my mentor  Filipe Saraiva for accepting my proposal and being kind and generous to me whenever I needed any help. I can’t stress on this enough but KDE is really a  very helpful community, especially to beginners who struggle at very basic steps.

So, this is the first time my proposal for GSoC got accepted . I am really happy and would like to make the most of this opportunity.

Project Details:

I will be working on  Cantor and will be mentored by Filipe Saraiva,  who is the maintainer of Cantor

Cantor is a KDE Application aimed to provide a nice Interface for doing Mathematics and Scientific Computing. It doesn’t implement its own Computation Logic, but instead is built around different Back ends.

The main aim of this project is to port all the back ends to make use of  standard streams for communication.

At the  moment, Cantor use different methods to communicate with the back ends. Some of them use C Api, some use D-Bus protocol and some have already been making use of Q/K process.

This project is important since this way Cantor will make use of a standard technology to implement back end and it will enable the use of Cantor in different operational systems.

If you want to know more about the project, kindly have a look at my  proposal . It lists out the current status and the implementation details.

That’s all for this post. I will keep posting the progress of my project from time to time.

Looking forward to have great summers