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

vedant agarwala vedant.kota at gmail.com
Thu Mar 19 07:34:19 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 made changes to this mainly based on the suggestions by Myriam. This
is the second draft.

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: Porting Amarok to Qt5/KDE Frameworks 5

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 Aleix 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/>)“

Personal motivation: This port will touch all modules of Amarok. I have
been working on Amarok for more than 2 years but still I don’t know about
all the modules Amarok uses. I would love to learn about them and this port
is a great method for me to learn.


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 Aleix’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, /doc, 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[3]
<http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/index.html>
framework in the beginning. Though all the modules are deprecated, it will
help me get to a point where everything is building. It is a good module to
aid any KF5 porting process. Then it will just be a matter of removing
deprecated dependencies one by one, which I will do after tests are
passing. Some modules that now belong to KDELibs4Support and are used by
Amarok: KUrl, KMimeType, KStandardDirs, KUniqueApplication, KLocale,
KMessageBox, Solid::Networking, KIO::NetAccess, KApplication, KDialog etc.
Most of these have been deprecated in favour of their Qt counterparts.

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 [4]
<https://community.kde.org/Frameworks/Porting_Notes> provides a lot of
information on the deprecated ones, and how to handle them. 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.

There have been a lot of changes to kdelibs in KF5. It is not a large
package anymore. It has been split up into smaller modules. We will need to
include only those that are relevant to Amarok. Though this is a great step
forward, it means a lot of code changes in the porting process. But the
good news is that, for the most part, it means including relevant modules
in the cmake files. ‘kdecore’ has been split up into a number of
independent libraries: libkarchive, libkauth, libkdbus, etc. Some specifics
that I have to handle: In cmake, in order to use the macros that were
earlier provided in kdelibs, I will have to include the
`extra-cmake-modules` package.

   -

   Amarok uses KStandardDirs heavily (172 class mentions) and its port is
   not trivial. I will follow its specific Porting Notes[5]
   <https://community.kde.org/Frameworks/Porting_Notes/KStandardDirs> for
   this.
   -

   There are 1397 occurrences of KUrl in /src; and the porting notes
   mentions that I will have to review and replace rather than running sed on
   it. This is going to very tedious. I will have to understand the usages to
   distinguish between relative and absolute paths so that I do make an
   incorrect use of QUrl.
   -

   KFile changes: libkfile is now called KIOFileWidgets, part of the KIO
   framework.
   -

   KWindowSystem: Amarok /src uses this 28 times. Build will just break as
   classes have been removed and method names have been changed. Easy to port
   using the breaking build method.
   -

   For some reason Amarok uses both KAction (235 times) and QAction (795
   times). KAction has been deprecated in favour of QAction. But I have a dev
   script[6] to help me out with this and automate the process.

I can perform each of these in a separate commit so that I clearly see the
changes made by any KF5 porting helper scripts found in kde-dev-scripts/kf5/
[6]
<http://quickgit.kde.org/?p=kde-dev-scripts.git&a=tree&h=78cc02dfa848697fb25443868181f8ee44743ad7&hb=4fd34664d4640ecd4194ccd74756a8b9bf3cce81&f=kf5>


Tentative Timeline:

May-

<--- GSoC commences--->

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

June-

week 1: Fix cmake errors.

week 2: Cmake errors should be fixed by now.

week 3: Begin working on make errors.

week 4: Finish fixing 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: Make sure unit test suite runs completely.

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]
http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/index.html

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

[5] https://community.kde.org/Frameworks/Porting_Notes/KStandardDirs

[6]
http://quickgit.kde.org/?p=kde-dev-scripts.git&a=tree&h=78cc02dfa848697fb25443868181f8ee44743ad7&hb=4fd34664d4640ecd4194ccd74756a8b9bf3cce81&f=kf5

[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/20150319/51c7135c/attachment-0001.html>


More information about the Amarok-devel mailing list