Hello all,

Joao has notified me that QtSharp was not given a slot for Google Summer of 
Code this year as part of KDE. While I understand your position and would 
accept any final decision you make, I do believe it's going to be beneficial to 
the KDE community if you could reconsider.

I won't bore you about my ability to provide good work. It is self-evident from 
my work on Qyoto - 
https://quickgit.kde.org/?p=assemblygen.git&a=log&h=f39e148ac546c3f270487e27f39ff0351078d9ee&pg=1
 , as well as on QtSharp itself - 
https://gitlab.com/ddobrev/QtSharp/commits/master , 
https://github.com/mono/CppSharp/commits/master (part of the latter was done 
through my participation in GSoC last year - 
https://www.google-melange.com/gsoc/project/details/google/gsoc2015/ddobrev/5741031244955648
 ). The real point here is whether this work would benefit the KDE community. 
My personal answer is definitely yes. Please allow me to list a few arguments.

- QtSharp works in such a way that at least 90 % of the processing is done by 
CppSharp (mentioned above and open source itself). CppSharp, led by Joao, is an 
universal tool for wrapping C and C++ libraries. What QtSharp does is a few 
Qt-specific customisations, such as handling signals and Qt events. CppSharp 
used to be quite modest in its capabilities, much worse than alternatives such 
as SWIG except for ease of use. However, Qt, being a vast amount of various 
code, has been a priceless testing platform. As a consequence, with the fixes 
CppSharp would receive as part of the work on QtSharp during a Summer of Code, 
it's going to be able to wrap any C++ library, including those of KDE. It would 
be little effort to create a project to wrap them and as a result KDE 
developers would be able to use KDE Frameworks as well as Qt through C#. This 
way, Kimono, the dead KDE project with the same purpose, can be revived the 
same way Qyoto was;

- Language bindings attract the whole community of developers in the language 
in question. C# is a highly popular language and though it's to a large degree 
so among commercial programmers, numbers do matter. Qt, on the other hand, is a 
highly desired programming framework because of its technical and 
cross-platform capabilities. The major reason that even more programmers do not 
use Qt is C++ which, despite the enormous and successful efforts of the 
creators of Qt to create a smooth API, still remains C++ from both technical 
and psychological points of view. QtSharp, being a bridge between the two 
sides, provides a service to both. KDE is on one of those sides because, at 
least to me, KDE is Qt;

- The Qyoto project was officially part of KDE while providing the exact same 
service as QtSharp. The only differences are that Qyoto is much inferior to 
Qt#, and is hosted at KDE. I am sure that you won't consider any project 
beneficial to the KDE community only because it's hosted at the KDE servers. 
Besides, QtSharp is not hosted at the closed GitHub (which I dislike myself) 
but at the fully open source GitLab ( https://gitlab.com/groups/gitlab-org );

- Just in case anyone has a concern about the particular programming language 
of C#, I would like to remind you that for almost a year now not just Mono but 
Microsoft's implementation of .NET has been open sourced too ( 
https://github.com/Microsoft/dotnet ). Of course, this doesn't mean Microsoft 
has now suddenly become trustworthy but this is the beauty of open source - 
they can't take it back. Furthermore, Xamarin, the company behind Mono, 
re-licensed it under the most liberal license possible, MIT - 
https://www.xamarin.com/licensing . It's going to open all of its remaining 
tools and SDK-s in a few months ( https://blog.xamarin.com/xamarin-for-all/ ). 
I would like to clarify that Xamarin's business has been making C# run on iOS 
and Android which means that now C#, along with its entire platform, is a 
completely open on all platforms. This is guaranteed to increase its popularity 
among programmers, including Linux developers. They would only need a way to 
use their favourite libraries with this language, and one of the most favourite 
is without a doubt Qt.

Thank you for taking the time to read and consider my points.



Dimitar Dobrev,
https://gitlab.com/ddobrev/QtSharp

Reply via email to