Draft proposal for GSoC Project: Porting to Qt5/KF5/Plasma 5

Wed Mar 18 14:07:12 UTC 2015

Hello everyone,

I am applying for the GSoC project: porting Amarok to Qt5/KF5. This project
is very vital for Amarok and I need your help with it.

I have appended my proposal as is, so that you can reply in-line. All
suggestions are welcome, so are appreciations ;-)
Regards.

*Name: *Vedant Agarwala

Email Address: vedant.kota at gmail.com

IRC Nick: vedu

IM Service and Username: xmpp-google: vedant.kota at gmail.com

Location: Kolkata, India GMT+5.30

Proposal Title: Lyric Support Improvements

Motivation for Proposal and Overview: Currently Amarok (2.8) is written in
Qt4 and depends on KDE Frameworks 4. Qt 5 was announced a while ago and
gradually all KDE libraries, applications. etc. are being ported to
Qt5/KF5. It is natural for Amarok to do so as well.

Qt5 has a lot of improvements and new features. Porting Amarok to it will
allow Amarok to take advantage of them. Also, for the future, as libraries
would probably be written in Qt5, Amarok will have will have to depend on
Qt5 as well or not be able to use such libraries, if Amarok is not ported.

Also, in general sticking with the times and using the latest frameworks
and libraries is beneficial for any project. Quoting Aliex Pol, “I
recommend people to do their porting, I think it’s a solid step forward for
the project and will help you clean up parts of it and start thinking
future.Qt 5 provides many interesting new concepts. I’m thinking of
QtWebSockets, QtWayland, QtWebEngine and I hear Qt3D is getting really
interesting. Additionally, it enables your project from letting the Qt code
integrate properly in the new C++11 concepts.Porting to KF5 will also help
your project become more portable and reach out to different platforms. (Like
android [1] <http://www.proli.net/2014/06/12/kde-software-on-android/>)“

Implementation Details:

I will follow a “breaking build” technique to make this port: First I will
change all CMakeLists.txt files to use Qt5/KF5 macros instead of Qt4/KF4
(like {KDE4_*}, etc.) ones. Then run cmake. I will fix these errors one by
one, until there are no more left.

I used Aliex’s script [2]
<http://quickgit.kde.org/?p=plasma-framework.git&a=blob&h=4d49e9ac199817dbf05398b89acf69791aedb530&hb=bc26ac13349a7a057621143d75e9c7b2518f5486&f=src%2Ftools%2Fport-cmake.sh>
(and some ‘find’ and ‘wc -l’ magic) to find out how much work this actually
entails:

   -

   In the src/ directory, 57 out of 81 cmake files need to be changed, 220
   lines in total. This is primary area of focus and should take up most of my
   three months of work.
   -

   In the tests/ directory: 30 out of 41 cmake files, 126  lines in total.
   Adapting tests to Qt4/KF5 is not going to be primary focus of this project
   but I will have to make sure that they actually run. From my initial
   analysis it seems that I will not have to change this directory to run the
   tests (Comment if this is not true). If I have time on my hands after the
   rest of the project is complete I will get back to this.
   -

   2 files in /imgaes have very trivial modifications i.e. changing
   kde4_install_icons to ecm_install_icons. This is not break my build.
   -

   9 remaining files in /utilities, /playground, etc. also have similar
   (trivial) changes and I will not need to spend much time on these.

For depending frameworks, I will start the port and use KDELibs4Support
framework in the beginning. It’s a framework with all the modules are
deprecated, because the functionality is moved to Qt5 mostly. It will help
me get to a point where everything is building.  Then it will just be a
matter of removing deprecated dependencies one by one, which I will do
after tests are passing.

I will focus on removing all the errors that will get when I run cmake,
followed by make. The make errors will probably be compile errors that will
have to inspect and fix. Qt has tried hard to maintain
backward-compatibility, except in the case of QML which was almost entirely
reworked. But luckily, Amarok does not use QML. Hence the code changes will
be minimal. Most of my errors I will get during the running of cmake. Lots
of changes here: using newer macros and more importantly using newer
libraries and frameworks.

Then, I will focus on making all the tests pass. I may require some code
changes here depending on how the tests are failing.

After this point, I will have a successful build, with cmake using Qt5 and
KF5. Now I will have to remove the deprecated modules. Porting Notes [3]
<https://community.kde.org/Frameworks/Porting_Notes> provides a lot of
information on the deprecated ones, and how to handle them. I know Amarok
uses a lot of them (like: KUrl, KMimeTyes). After my code builds
successfully I will grep for all such occurrences and change them one by
one. Going through the Porting Notes documentation, I can see most of them
are pretty straight-forward. Also, I will keep an eye out for warnings
issued by make to look for deprecation warnings.

Tentative Timeline:

May-

<--- GSoC commences--->

week 4: Change the AmarokLyricsScript API  and download script.

June-

week 1: Change CMakeLists.txt files for /src and start building.

week 2: Fix errors.

week 3: Cmake errors should be fixed by now.

week 4: Begin working on make errors.

<--- Mid term --->

July-

week 1: Run unit tests and make them pass.

week 2: If unit tests need to be changed, change and run them.

week 3: Work on running

week 4: If unit tests completed, start removing deprecated code

August-

week 1: Build, test and run Amarok without any Qt4/KF4 dependency.

<--- suggested “pens down” --->

week 2: Documentation. Mark deprecated packages in code (like those in
KDELibs4Support)

<--- firm “pens down” --->

week 3: Prepare and submit reports

Other Obligations: I have no other obligations. I can easily spent about 50
hours a week coding; since my college gets over in April end. I will be
free the entire duration of my summer vacation.

About Me: I am currently in my final undergraduate year in National
Institute of Technology, Durgapur, India, studying Computer Science and
Engineering. I have experience coding experience with C/C++, Java
(including Android and making GUI using Java swing), SQL and web services.
I have submitted patches to KDE (bug-fixes for Rekonq[7]
<https://git.reviewboard.kde.org/r/107662/>, Amarok[8]
<https://git.reviewboard.kde.org/r/110082/>[9]
<https://git.reviewboard.kde.org/r/109295/>[10]
<https://git.reviewboard.kde.org/r/111038/>[11]
<https://git.reviewboard.kde.org/r/109283/>, Akonadi[12]
<https://git.reviewboard.kde.org/r/110213/>) and Mixxx DJ software[13]
<https://bugs.launchpad.net/~vedu>. I took part in and ‘passed’ Season of
KDE 2013, completed GSoC 2014[14] and mentored in SoK 2014.

I love coding for open source.

After GSoC I will continue to be a developer for Amarok and look to mentor
students from next years’ programs like GSoC, SoK, Google Code-in etc.

External Links:

[1] http://www.proli.net/2014/06/12/kde-software-on-android/

[2]
http://quickgit.kde.org/?p=plasma-framework.git&a=blob&h=4d49e9ac199817dbf05398b89acf69791aedb530&hb=bc26ac13349a7a057621143d75e9c7b2518f5486&f=src%2Ftools%2Fport-cmake.sh

[3] https://community.kde.org/Frameworks/Porting_Notes

[7] https://git.reviewboard.kde.org/r/107662/

[8] https://git.reviewboard.kde.org/r/110082/

[9] https://git.reviewboard.kde.org/r/109295/

[10] https://git.reviewboard.kde.org/r/111038/

[11] https://git.reviewboard.kde.org/r/109283/

[12] https://git.reviewboard.kde.org/r/110213/

[13] https://bugs.launchpad.net/~vedu

[14]
https://www.google-melange.com/gsoc/project/details/google/gsoc2014/vedant/5639274879778816
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20150318/959a1e18/attachment-0001.html>