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

Sun Mar 22 12:21:19 UTC 2015

I have made some minor changes so adding them inline:

On Thu, Mar 19, 2015 at 1:04 PM, vedant agarwala <vedant.kota at gmail.com>
wrote:

> 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.
>
Plasma Applets, especially “Current Track” (and Lyrics, Wikipedia, etc.),
need some porting as well. Firstly, I will use libplasma2 that had been
deprecated in favour of libplasma. Plasma::Corona is used in
‘src/context/ContextView’ and Plasma::Applet is used in the applets. Both
their porting is covered extensively in Plasma’s porting Notes[4]
<https://community.kde.org/Plasma/PortingTolibplasma2#Corona>. I will refer
to them as ‘make’ will throw no such function name type errors for
functions that were being used in libplasma but not in libplasma2.

> 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/Plasma/PortingTolibplasma2

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

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

[7] https://git.reviewboard.kde.org/users/vedanta/

[8] https://bugs.launchpad.net/~vedu
[9]
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/20150322/dd1cc62a/attachment-0001.html>