GSoC/2021/StatusReports/AnjaniKumar: Difference between revisions

From KDE Community Wiki
< GSoC‎ | 2021‎ | StatusReports
No edit summary
No edit summary
Line 143: Line 143:
https://anjani.live/posts/gsoc21-week-5/
https://anjani.live/posts/gsoc21-week-5/


==== Current Status ====
==== Week 6 ====


I am working on completing the porting of build system. To be specific, porting build system of libO2 and trying to also integrate KF5. It should be complete in a few days.
This week our goal was to port the build system in such a way that it can detect a Qt installation 5/6 and adjust accordingly. Our goal was to preserve the functionality of current Qt5 pipelines and tests. We used cmake variables and patched hardcoded Qt versions in the cmake with dynamically set variables enabling cmake configuration with both Qt5 and Qt6.
 
===== Related Patches =====
 
* [https://invent.kde.org/graphics/digikam/-/merge_requests/119 Port CMake files]
* [https://invent.kde.org/graphics/digikam/-/merge_requests/120 Link Core5Compat module]
* [https://invent.kde.org/graphics/digikam/-/commit/2b41dca829ec8976a7889b8c0beb7680772566b4 Port cmake include dirs in bqm/metadata]
 
===== Related Blog =====
 
https://anjani.live/posts/gsoc21-week-6/

Revision as of 16:24, 18 August 2021

digiKam: Port to Qt6 on Linux

digiKam is a professional photo management software. With the release of Qt6, digiKam needs to to adapt to many new improvements made possible with the new Qt6 framework such as code readability, better classes from Qt6 and new unit tests. Since digiKam's code-base is huge, a proper plan had to be agreed upon to achieve the goal in the GSoC timeline.

Mentors

  • Gilles Caulier
  • Maik Qualmann
  • Thanh Trung Dinh

Links

Goals

  • To build digiKam with current Qt6 stable release.
  • Prepare digiKam so that it can be built with later Qt6 releases as well.
  • Write new AppImage builder scripts

Status Report

Community Bonding (May 18 - June 6)

We discussed the proposal again and made some strategies on the first task and how to test the new patches.The first task was to Port digiKam to Qt 5.15. This is a sophisticated task and involves a lot of sub-steps like:

  • Identifying deprecated classes and class members/functions in Qt 5.15
  • Identifying their uses in digiKam code and organizing them based on which class has most uses.
  • Porting the identified code. Sometimes trivial, sometimes needs reviews from mentors.
  • Writing new unit test if needed.
  • Running tests and check the patched code at runtime with the digiKam stable release.

We planned a safe way to introduce patches safely in the code, otherwise regressions might be introduced. Here is a list that I made of deprecated code in digiKam and sorted it according to number of usages it had.

After identifying and listing the code that needed to be patched, I proposed two methods to approach the problem:

  • We pick a source file in digiKam and make patches to it resolving all Qt deprecation warnings.
  • We pick a Qt class from our list and identify it's use in all digiKam code and patch them.

The latter was safer as dealing with a lot of Qt classes in the same file might have led to regressions which were difficult to track down.

So I started early in this time only so that I don't get stuck in the coding period. I started picking Qt classes with few usages and started porting them. These were QMap, QPrinter. I faced some difficulty but my mentor's feedback helped me a lot and learnt quickly. More about this period in the blog post.

Related blog

https://anjani.live/posts/gsoc-community-bonding/

Coding Period (June 7 - July 12)

Week 1

I patched a lot of warnings mostly from Qt classes that had fewer warnings. I also wrote a new unit test for FilterAction class. This test was related to QHash warnings. The test checked if all keys are unique in a QHash in FilterAction class. In a nutshell, there were 6693 lines of build warnings on master.With the patches on my branch these warnings reduced to 1830 lines. That’s a reduction of about 73%.

Related Patches
Related Blog

https://anjani.live/posts/gsoc21-week-1/

Week 2

Continuation of work from previous week. We also discussed about introducing STL algorithms in digiKam. Though it is huge task in its own and not related to my project so we suppressed the cppcheck warnings in report and moved on.

Related Patches
Related Blog

https://anjani.live/posts/gsoc21-week-2/

Week 3

During this week I patched the very old random number generators and qsrand()/qrand() in digiKam. As a result we were able to drop Boost::Random dependency. I also ported Qt X11 Extras module code. A very detailed report is in the blog post.

Related patches
Related Blog

https://anjani.live/posts/gsoc21-week-3/

Week 4

In this week, digiKam was fully ported to Qt 5.15. We also started discussion on now introducing Qt6 this week. I tried building it for the first time with Qt6, it failed(no surprises here). We ran into a problem that digiKam depends on Qt WebEngine which would only be stable in Qt 6.2 in September. We discussed about possible solutions. I tried building the alpha Qt 6.2 but it doesn't build.

Related Patches

Week 5

I found the solution to problem from last week. Gilles also helped me to get started. This week I worked on porting the build system to Qt6. digiKam is huge and we have successfully branched the build process if no web module is found. A more detailed report is in the blog.

Related Patches
Related Blog

https://anjani.live/posts/gsoc21-week-5/

Week 6

This week our goal was to port the build system in such a way that it can detect a Qt installation 5/6 and adjust accordingly. Our goal was to preserve the functionality of current Qt5 pipelines and tests. We used cmake variables and patched hardcoded Qt versions in the cmake with dynamically set variables enabling cmake configuration with both Qt5 and Qt6.

Related Patches
Related Blog

https://anjani.live/posts/gsoc21-week-6/