I have made some minor changes so adding them inline: On Thu, Mar 19, 2015 at 1:04 PM, vedant agarwala <vedant.k...@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.k...@gmail.com > > IRC Nick: vedu > > IM Service and Username: xmpp-google: vedant.k...@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
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
