For my contribution, I picked Krita because it’s an app I use a lot for handwriting and illustrations on my engineering homework. I considered implementing a feature I want (PDF import and export useful for note-taking), but the maintainers intentionally dropped support for pdf export in the past.

Krita passed the Commarch considerations with flying colors. The only points of concern was the very large amount of source code and the primary branch’s name being “master”. It was also well recommended by one of the commarch presentations we did in class. Krita’s community type is Federation.

Finding the bug to fix

After that consideration, I searched and browsed the bug tracker.

searching for krita issues in the bug tracker

After browsing the bugs, I found one I liked.

image (3).png

I picked bug 453572, that I felt would be easy and valuable to solve.

The bug 453572, titled “JPEG-XL advanced export options confusing” complains about vocabulary being too technical so that it’s difficult to understand and localize.

screenshot of bug report

Building Krita

Reading the instructions at Building Krita from Source, I noticed that building on Linux requires Docker (which I dislike Docker and Podman because of its low level system access), so I tried running the Windows build instructions under WINE. I made some progress entering the WINE environment with a comfortable terminal using powershell-wrapper for wine, but ultimately I aborted the process because of deeper incompatibilities.

I ended up following the instructions Building Krita with Docker on Linux except with podman on a fedora computer, which required a few workarounds:

  • call export DBUS_SESSION_BUS_ADDRESS= in the shell immediately before most podman calls, probably because I was using dbus for something else.

  • If an error related to pulseaudio appears, Adrian gave these instructions which worked to fix that error:

    before ./bin/build_image, modify ./bin/find_default_container_file.inc, change line DOCKER_BINARY=docker to DOCKER_BINARY=podman near the front

    before running ./bin/run_container, modify that run container script remove the lines –volume /tmp/pulseaudio-docker.socket:/tmp/pulseaudio-docker.socket \ –volume /tmp/pulseaudio.client.conf:/etc/pulse/client.conf \ towards the end and comment out tryCreatePulseaudioSocket a dozen or so lines above it

  • to run Krita on the host, you kind of have to use the appimage, which takes more than 10 minutes to package the libraries at every build.

Finding the file to blame

I got lucky with the issue, the feature of concern “JPEG-XL” has a matching file name in the source, krita/plugins/impex/jxl/kis_wdg_options_jpegxl.ui, so all I had to do was search the filenames in the source code for “jpegxl”.

Fixing the issue

It’s a Qt5 Designer UI file, which is a UI designer app and it stores UI source code in xml format in .ui files.

I downloaded and ran the Qt5 Designer app (very easy), and it was trivial to navigate and open the source code with this app.

I am familiar with web design through a GUI designer, so I used my experience from high school APCSA and from an internship using Ignition to adjust the UI design.

I ended up adding many tooltips to the UI, cross-referencing with the JPEG-XL standards’ glossary ISO/IEC 18181-1:2024 (free preview).

A bug in Qt5 Designer

I was unable to delete the tooltip for one of the background panels after I realized I added it to the wrong element. The tooltip is now empty but it still displays an empty tooltip rectangle when hovered.

My merge request won’t be accepted until I fix the empty tooltip.

The Merge Request

There were two conflicting templates in the merge request process. “Create the merge request” on the KDE community wiki said to tag a specific team and add screenshots:

Tag any of the following teams in the description text based on what kind of review you would like:

[…]

Visual and UI review: @teams/vdg (please add before-and-after screenshots)

Meanwhile, when creating the merge request on gitlab (invent.kde.org), the template was different and you can see how I filled it out in the merge request:

I used Qt5 Designer to edit the JPEG XL export menu to make it easier for users to understand the Advanced options with some verbose tooltips. This should improve translatability as reported in Bug 453572.

Test Plan

I compiled this change to an appimage and ran it on my Fedora computer. I personally like the improved UI.

Formalities Checklist

  • [Y] I confirmed this builds.
  • [Y] I confirmed Krita ran and the relevant functions work.
  • [?] I might have tested the relevant unit tests and can neither confirm nor deny they are not broken. (I don’t know what this means.)
  • [Y] I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • [N/A] I made sure my code conforms to the standards set in the HACKING file. (I did not write any code.)
  • [Y] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy. (I did not write any code, it’s all changes in English).
  • [?] Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository? (no because this change simply copies some text from Krita documentation over to the Krita UI, it does not add any additional features worth documenting.)

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Clearly this template is biased towards coding-related concerns, but since my change was in the UI (rather than the primary programming language of the project, C++), many of the checks were irrelevant.

In a comment on the merge request, I added before&after screenshots and I tagged @teams/vdg (Visual and UI review).

Conclusion

I picked a bug in Krita that was complaining about untranslatable documentation.

I downloaded and built Krita source code. I found the site of the bug in the source code, and I added tooltips explaining what the vocabulary means.

The merge request for this bug fix is currently under review.

What I liked

I think the source code is nicely organized which made it easy to find the relevant source code that affects my bug.

What was the experience

Building krita to test changes involved a lot of waiting. I waited several hours, especially after clearing the build cache.

Effort

I feel like this was a high effort contribution. It took more valuable time out of my schedule compared to the commarch presentations and compared to the lit review.