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