If you had been following my earlier blog posts, you would know that I rarely include any code in them. My focus has primarily been on explaining how things work rather than delving into the specifics of how I implemented them. But this time I will be taking a deeper dive into the code, so in case you want to skip code today, you better not start reading this. ;)
This blog post has been a bit of a learning exercise for me as I pushed myself to learn UML diagrams and study a few design patterns in Qt. Learning Qt itself has been a challenge, though I doubt I can barely say that I have learnt it - I think it’s safe to say that I have just got more comfortable not understanding most things in Qt and trying to understand the parts that concern me. Now that I’m a teeny tiny bit wiser, I feel learning Object-Oriented Programming with C++, and a few design patterns prior to learning Qt would have been a better idea. Things (read classes) make a lot more sense once you understand the core design patterns.
The plan was to split the bundle creator into four main components, each having a single responsibility (Single Responsibility Principle!). DlgCreateBundle is the main class for the Bundle Creator. Notice how it has all functions related to putting the resources, tags and metadata in the bundle.
Similarly, all the code regarding resource choosing is present in PageResourceChooser(well not all, some of it in WdgResourcePreview), PageTagChooser(and WdgTagPreview) deals with the bundle’s tags, and all the metadata logic is present in PageMetaDataInfo. These wizard pages are completely independent of each other. There is, however, a message passing between PageBundleSaver and the other wizard pages which I will discuss later.
The Bundle Creator’s Resource Item Viewer now shares the same user interface as the one used by the Resource Manager in Krita. However, in order to not upset existing users of Krita, a new View Mode Button has been added so that users can switch between grid view and list view as per their preference.
The WdgResourcePreview class only deals with the left half of the Bundle Creator and the Resource Manager. That said, it loads the resources from the Resource Database onto the viewer, and displays resources as filtered by text or tag. However, all the code related to what happens when a resource item is clicked is dealt within the PageResourceChooser class for the Bundle Creator and the DlgResourceManager for the Resource Manager.
To manipulate the working of the right half of the Resource Chooser Page, one would need to make modifications to PageResourceChooser. And even though the left and right halves of the Resource Chooser page look fairly identical, it is important to note that the left half is built upon a QListView (KisResourceItemListView) and the right one on a QListWidget (KisResourceItemListWidget). This is because the left half loads the data directly from the Resource Database, using KisResourceModel. And the right half provides a view of the resource items selected by the user. It does use KisResourceModel for fetching the icon and name of the relevant item, but it doesn’t use the model directly.
This is really how each class mentioned above looks like.
Similarly to MVC, Qt’s Model/view design pattern is essentially separated into three components: Model, View and Delegate.
Instead of utilizing controller classes, Qt’s view handles data updating through delegates. It serves two primary objectives: firstly, aiding the view in rendering each value, and secondly, facilitating user-initiated changes. As a result, the controller’s responsibilities have merged with the view, as the view now assumes some of the tasks traditionally assigned to the controller through Qt’s delegate mechanism.
The KisResourceModel, KisTagModel, KisStorageModel act as the models for the QComboBox-es in the Bundle Creator(and Resource Manager). The KisTagFilterResourceProxyModel is built on top of the KisResourceModel and KisTagModel, and serves as a model for the KisResourceItemView which displays the list of available resources. And the KisResourceItemDelegate renders the items of data. When an item is edited, the delegate communicates with the model directly using model indexes.
| Model | View |
|---|---|
| KisResourceModel | QComboBox |
| KisTagModel | QComboBox |
| KisStorageModel | QComboBox |
| KisTagFilterResourceProxyModel | KisResourceItemView |
Very classic, but just a rough sketch showing how the wizard pages communicate with one another. This connection helps to update the summary in PageBundleSaver whenever the selected list of resources or tags changes.
This is something I have been working on last week. The Tag Chooser page is updated to look similar to the Resource Manager’s tag section. The available tags are displayed using KisTagLabel and the selected ones are displayed(and selected) using KisTagSelectionWidget. In both the cases, the KisTagModel serves as the underlying model.
My merge request can be viewed here.
Post midterm, I would be working on adding the feature of editing bundles in Krita, which will allow artists to add and delete components from existing bundles, so that they won’t have to go through the process of creating a bundle from scratch whenever they want to make some changes. I’ve created a post on Krita Artists Forum to better understand the preferences of artists regarding bundle editing. Feel free to drop a comment if you want to talk about it! :D
This time a drawing on paper art since I have exhausted my collection of art I made using Krita - serves as a reminder that I should do this more often. :)
I recently stumbled upon this excellent 2014 article about patch review by Sage Sharp: The Gentle Art of Patch Review.
I highly recommend reading the whole article, but my main takeaway is that when reviewing code, one should follow three phases:
I do quite a lot of reviews at work. Sage article made me realize I am often guilty of jumping directly to #3. I have been reflecting on why that happens, and I concluded that it's because it's the path of least resistance.
When I receive a 10,000 line patchset, with 23 commits stepping on each other and no description, the temptation is high to skip phase 1 and 2 and instead say to myself: "I am just going to review the whole patch one line at a time, suggesting new names and micro-optimizations so that it does not look like I clicked on Approve while looking elsewhere".
Since jumping directly to phase 3 is the path of least resistance, when preparing code for review, you should make what you can to reduce the resistance of phase 1 and 2.
For this phase, the place to make review easier is in the description of your patchset: that is the pull request description on GitHub or the body of the mail presenting the patchset in a mail-based workflow.
It does not have to be extra long, just explain in one or two sentences the problem fixed by the patchset, or the new feature it adds... If the changes are significant, then hopefully you discussed them before diving full in: maybe there is an opened issue in the bug tracker, or it was discussed by chat or on a mailing-list. If so, add a link to it to your description.
For this phase, there are 3 places to make review easier: patchset description, high-level comments and commit history.
The patchset description should not paraphrase the patchset, but it should give a high-level overview of the changes.
Let's say as part of your patchset, you moved class Foo from file A to file B. If a reviewer goes directly through the changes (as in, jumps directly to Phase 3), they will have to infer that given that class Foo was removed from A, and a very similar (but maybe not identical!) class Foo was added to B, then it means the patchset moved class Foo from A to B. By listing this move in your description, not only do you save the reviewer the pain of having to infer the move, but you also get the chance to explain why you moved this class.
This can be hard. Maybe you do not like writing so this is chore. Well, being able to write prose is a very useful skill, even for the developers! Stepping out of your comfort zone is difficult, but the more you practice, the better your writing will be, the less it will become a shore.
Another reason this can be hard is because you need to write this in English and you think your English is not good enough. As a friend once told me: "The language of Open-Source is broken English", so don't be afraid of this. A broken English description is much more helpful than no description at all, and if someone criticizes your English, well... shame on them! You did the work! And again, practice will improve your English writing too.
Some coding guidelines require every function, every constant, every class, every module to have documentation. I think those are misguided and often lead to Captain Obvious comments like that:
@herzenschein:kde.org
GSoC
def activate_rear_engine():
"""Activate the rear engine"""
...
Thank you, Captain Obvious
On the other hand, having a comment attached to a new class or a module is very helpful, especially if it explains how the class works with other classes. Again, keep it high-level.
Ideally changes should be small, but it's not always possible. If the changes are large, chances are they can be split in multiple smaller changes. It is a lot easier to review a large patchset if one can go through it commit by commit.
Except... this is a double-edged sword! It is only easier to review if each commit makes sense in isolation and if the set of commits "tell a story". If a commit adds a method to a class and the next commit renames or removes it with a "Oups, that was not a good idea" commit message, then it actually takes longer and is more painful to review commits individually than just reviewing the final state.
This is easier said than done, though: when you are working on your changes, it's common to hit road blocks, change directions, or make unrelated changes. The commit story usually won't be straight and easy to read on your first try.
You know what? That's fine! Just like the first draft of a novel writer is not perfect, so is your commit story. And just like the novel writer, you can edit your story to make it easier to read. Assuming you work with a VCS which lets you rewrite history like Git, once you are done with your first draft, it's time to warm up git rebase!
Again, this takes practice to get right, but here are a few tips to get started:
git add -p or git gui.git branch backup. This serves two purposes:git reset --hard backup (you can also use git reflog to do that, but I find this approach simpler).git diff backup to check if the end result is similar enough.This part depends on the policy of the project. Some projects prefer if you force-push the fixed patchset as you address issues spotted during review, so that the commit history always looks like what will be committed. Other projects have a no-force-push policy, they will ask you to push fixup commits. This often happens on forges which lack the ability to compare patch-sets (Unfortunately, GitHub is one of them, GitLab is much better in that regard).
If you get asked to do fixup commits, please make sure the history is squashed into a readable and coherent history before the patchset is merged. This greatly simplifies the lives of future developers if they have to revisit the past.
To wrap up, to make the life of your reviewer easier (and thus make the review faster and/or more insightful):
You may also find out during this preparation process that some of your changes are not optimal, or a bug slipped in. When this happens, take the time to fix these issues before posting your patchset for review. In a sense, this process makes you the first reviewer of your code. And the cleaner your patchset, the faster the review!
Not actually the first attempt, but the first attempt using the version of the operating system that users actually use. There were pre-release versions of the Steam Deck’s operating system that had different partition setups.
Do not assume that it will be easy to use system libraries for development. By default, system libraries do not come with headers on the Steam Deck, unlike Arch Linux. You can get the headers and other things related to setting up a traditional KDE development environment by running sudo steamos-devmode enable. However, you may not even have enough space in your rootfs partition to install all the libraries and headers you need. The rootfs only has 5GiB of space, even on the 512GB Steam Deck model (my model).
To be fair to Valve, that makes sense for a device that is mainly for gaming, but usable for other things. They also tell you in a very noticeable warning message to use Flatpak or the SteamOS Docker image for building packages, although package building isn’t particularly relevant for Plasma and KF6 development. Maybe the Docker part is, but I could also use a Docker image of a traditional Linux distro if I’m going to use Docker for KDE development.
Could you expand the rootfs? Maybe, but SteamOS isn’t a typical Linux distro. It has A and B system partitions that it switches between so that the system can be recovered in case of a bad update. I’m not much of an IT/sysadmin guy, so I’m not comfortable with making major modifications to SteamOS. I got my Steam Deck for free from Valve to test SteamOS as users would see it and I actually play some games on it, so it’s not in my interest or Valve’s interest for me to modify the system so significantly.
Unless you’re willing to risk breaking your system, keep your development environment entirely contained within your home partition and/or external storage devices. Time to restore my SteamOS back to the way it was. The recovery instructions are here: https://help.steampowered.com/en/faqs/view/1B71-EDF2-EB6D-2BB3
I'm excited to announce the release of version 0.8 of libQuotient, the Qt library for building software using Matrix.
Available at the release page on GitHub :)
End of next week, Akademy, KDE's annual conference is starting in Thessaloniki, Greece and online. Alexey, Carl, and I will be there talking about our work on and with Matrix and ActivityPub. The talk will be live-streamed, so don't miss it!
There's always more things to do in libQuotient. Come talk to us in #quotient:matrix.org.
Tellico 3.5.1 is available, with a few new features.
It’s time for a new Kirigami Addons release. This new release contains the work of Joshua Goins, Laurent Montel, Thiago Sueto, Volker Krause, Shubham Arora, James Graham, Rishi Kumar and myself. Thanks for contributing!
FormGridContainer makes it possible to make the information exposed with MobileForm more compact by putting multiple small cards in the same row. The number of columns by default is 3 on desktop unless the total number of cards makes it more sensible only to use 2 columns (e.g when there are only 2 or 4 elements).
On mobile the number of columns is reduced to only 2.
This new component was initially made by Rishi Kumar for the info grid that Tokodon, with some further improvement from myself. Here is how this looks with Tokodon.
And the current API:
noahdvs
CarlSchwanimport org.kde.kirigamiaddons.labs.mobileform 0.1 as MobileForm
MobileForm.FormGridContainer {
infoCards: [
MobileForm.FormGridContainer.InfoCard {
title: "42"
subtitle: i18nc("@info:Number of Posts", "Posts")
},
MobileForm.FormGridContainer.InfoCard {
title: "42"
},
MobileForm.FormGridContainer.InfoCard {
// Clickable card
title: "Details"
action: Kirigami.Action {
onClicked: pageStack.push("Details.qml")
}
}
]
}
Applications can now extend the AboutPage to add extra content to it. This
was driven by the need of Itinerary which need to expose the license
information about the open data it uses.
Application can now add a Validor to their textfield. This was driven by the need of Keysmith rewrite to use MobileForm.
The BasicTreeItem component now uses correct spacing between items. This was caused by a regression when adding right to left support to the KirigamiAddons TreeView.
The native Android date/time pickers now works correctly even if multiple instance of it are loaded at the same time.
Shubham and James fixed various bugs with the maximized image and video component which is displayed in NeoChat and Tokodon when viewing media files.
It is the first day of July… time for me to have a large chunk of vacations it didn’t really happen for a while and I feel I need it.
During those vacations I’ll try to stay away from the news as much as possible. I guess the fashionable way to put it is: I will have a three weeks “news detox”. 😊
So, don’t expect web reviews during that time.
My plan is of course to read books, visit places and spend as much quality time with family as possible. And still… it won’t be all play. There are a few software and writing projects I’ve been postponing for far too long and I’ll try to at least get them to progress a bit.
I’ll also take a few days away from my family to attend Akademy!
I’m of course excited to reconnect and chat with everyone. See you there!
Last but not least, I won’t stay at Akademy for long in order to run back to my family, but… I’ll be holding an online workshop about the KDE Stack during the training day.
Since it’ll be in the online room it should be easy for anyone interested in the topic to attend. 😉
See you there!
Let’s go for my web review for the week 2023-26.
Tags: tech, france, law, foss, surveillance, criticism, cryptography
A reminder of what’s going on in France… and it’s bleak. Lots of things can turn you into a suspect at this point.
You encrypt your communications or data? You try to avoid surveillance from the GAFAM? You use Tor or a VPN?
If anything bad happens around you, then you’ll turn into a suspect, this is due to the “clandestine behavior” you entertain… so for sure you are part of some “conspiracy”.
This is very worrying.
https://www.laquadrature.net/en/2023/06/05/criminalization-of-encryption-the-8-december-case/
Tags: tech, gafam, facebook, fediverse, xmpp, standard, community
Facebook getting interested in the fediverse indeed looks like XMPP or OOXML all over again. Beware of those old tactics, they are very efficient against communities.
https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html
Tags: tech, ai, machine-learning, art
Excellent piece from an excellent artist. I really thought this through and I think he’s going in the right direction.
Tags: tech, ai, machine-learning, gpt, google
It smells a bit like hypocrisy isn’t it? On one hand they claim it can make developers more productive on the other they think they shouldn’t use it.
https://www.theregister.com/2023/06/19/even_google_warns_its_own/
Tags: tech, github, copyright, copilot
Basically the wording allows them to feed whatever system they want with your code… even in private repositories.
https://docs.github.com/en/get-started/privacy-on-github/about-githubs-use-of-your-data
Tags: tech, ai, machine-learning, research
Very comprehensive (didn’t read it all yet) guide about self-supervised learning. It’ll likely become good reference material.
https://arxiv.org/abs/2304.12210
Tags: tech, tests
Especially important in the context of tests indeed. As soon as you depend on some form of elapsed time you get into the territory of flaky tests.
https://xeiaso.net/blog/nosleep
Tags: tech, programming, distributed
Nice set of advises when dealing with concurrency. Don’t fall into some of the anti-patterns which are pointed out.
https://catern.com/concur.html
Tags: tech, programming, compiler, safety
This is a neat example of what programming languages could check at compile time. This clearly brings way more safety when you get such contract validation at build time.
https://whileydave.com/2023/06/27/programming-languages-going-above-and-beyond/
Tags: tech, static-analyzer, c++, memory, safety
Long but fascinating article on a blend of guidelines which could be statically checked to enforce a memory-safe subset of C++.
https://verdagon.dev/blog/vale-memory-safe-cpp
Tags: tech, programming, rust
Interesting to see what gets confirmed (slow compiler, nice compiler error messages, code quality) or debunked (steep learning curve, interoperability).
Tags: tech, java
This would be an interesting extension to the Java Stream API. Maybe one day it’ll make its way to the standard…
https://cr.openjdk.org/~vklang/Gatherers.html
Tags: tech, architecture, design, programming, craftsmanship
I always felt uneasy around this “law” as well. It’s a good deconstruction of it and proposes proper alternatives. It’s all about dependencies really.
https://www.tedinski.com/2018/12/18/the-law-of-demeter.html
Tags: tech, hype, complexity, technical-debt
Good piece about the hype cycles our industry constantly fall into. So much undue complexity for nothing in some projects… and then we’ll complain about technical debt. It would have been much easier to pick the right tool instead of wanting to use whatever new got released by some big tech company.
https://www.bitecode.dev/p/hype-cycles
Tags: tech, programming, logic, engineering, craftsmanship
Interesting way to look at our profession… I wonder if this is the core reason of why we have a hard time to turn into a proper engineering discipline, is it even possible at all then?
https://danielbmarkham.com/twilight-of-the-programmers/
Tags: management, productivity, burnout
Good tips on how to create some slack and prevent burnout.
https://hbr.org/2023/06/to-build-a-top-performing-team-ask-for-85-effort
Bye for now!
We’re about halfway through year! This update is a bit smaller than usual, and more focused on applications than Plasma. This isn’t for lack of time or trying, but I tried to deliberately clear out my backlog. That goal didn’t really pan out, but I’ll be trying again next month.
The Android build for Tokodon (and consequently it’s CI) was broken because I replaced the video player with libmpv, so I spent a good chunk of this month making sure it’s working again. This was a little difficult to fix, but I feel much more confident with Craft now.
If you’re not familiar with Craft, it’s a meta-build system created by KDE. Craft and it’s blueprints are written in Python. Blueprints describe how to build the application or library, and has easy utilities for working with existing build systems (AutoTools, CMake, Meson, etc). It may be a little daunting, but these blueprints easy to write and maintain. More importantly, Craft enables easy cross-compilation since it contains blueprints for the underlying libraries for KDE applications: OpenSSL, zlib, and so on.
Tokodon is (to my knowledge) the first KDE application to use libmpv on Android, so I needed to break a lot of new ground to make this happen. What’s exciting though is that any KDE application that uses libmpv (PlasmaTube?) doesn’t have to jump through hoops to make it build on Android.
Sorry, this section will be mostly text because I can’t exactly visualize build files!
zlib is already included in the Android NDK, but for some reason they don’t ship pkgconfig files for it (or anything, really). For example, Freetype declares a dependency on zlib in it’s pkgconfig, and then pkgconfig (the program) starts complain that it can’t “find zlib” although the library itself exists. That’s because pkgconfig is searching for zlib’s config, and doesn’t care if the .so or .a file exists on disk anyway.
For now, I propose enabling zlib on Android anyway. It’s odd that we have to build it again, but I don’t see an easier solution right now.
This is a really simple fix, QtMultimedia was missing as a dependency for this library. The new fullscreen image viewer uses QtMultimedia under the hood to display video, but it wasn’t declared in the blueprint yet.
See the merge request adding it as a dependency.
The versions of libarchive currently in Craft had an Android-breaking header inclusion bug, preventing compilation if you use any of it’s headers.
Now it’s bumped to 3.6.2 (the latest version as of writing), see the merge request. Support for the last version is also being dropped, let’s see if that breaks anything!
Tokodon uses libmpv to display videos from Mastodon and other services, which are served over HTTPS. libmpv uses ffmpeg to fetch video data, but the Craft blueprint for ffmpeg didn’t enable the TLS backend.
See the merge request which enables the OpenSSL backend for all platforms, which could benefit other KDE applications!
When deploying to Android, we use a tool called androiddeplyqt to package the libraries required by an application. One of the checks it deploys is checking the version of the .so before putting it inside of the APK. If your application links to, say libmpv.so.1 then androiddeployqt will stop in it’s tracks. Fribidi and mpv felt the need to set versions, without a way to tell them to stop.
See this merge request which now builds these two libraries statically completely side-stepping the issue. I think this is an okay solution for now, as a shared library doesn’t make much of a difference on Android. If someone knows a better way to force them to stop putting out versioned shared libraries, let me know.
Some dependencies of mpv (Such as fribidi) used Meson as it’s only build system, which didn’t have cross compilation support in Craft yet. Meson is nice and all, but it’s cross compilation system is really obtuse, as I need to write a file! This is fed into the meson command, but I don’t understand why we can’t pass these as arguments or environment variables.
See the merge request for enabling cross compilation for Meson projects under Craft. There’s still a bit of work left to do for me, like figuring out how to handle switching between toolchains.
I’ve been using PlasmaTube more lately, so that means more and more fixes to it! First, non-video results are no longer displayed. That’s these blank little fellows in the video grid:
The two player modes (minimized and maximized) are now stored as a binary flag, instead of guessing it. In simpler terms this means that when you maximize the window, it doesn’t enter a weird state where half of the player is open.
I improved the video loading experience a bit. Now when you explicitly stop a video it doesn’t momentarily reappear too soon when you click on another one. This doesn’t affect clicking between videos while it’s still playing or paused though.
The videos on a channel page load now! It’s not categorized or anything yet, but it’s a good start.
And of course, add an “About KDE” page to the settings!
I completed some important tasks for Tokodon this week! It may seem boring, but this includes important groundwork (including the Android stuff above) so we can focus on implementing more useful features.
I’m starting to remove the manual authentication code step which means it’s now even easier to login to Tokodon. Once you complete the login flow in your browser, it will return you to Tokodon magically. How to get this working in a Qt/KDE application is a mystery apparently (and on Android) so that might be future blog material.
I have some local changes enabling support for this on Android, and I’m hopeful this will appear in the next release. As a bonus, it lets you log into Pixelfed! For some reason, they don’t support copying the authcode and only support URI callbacks to return to the application. Once this lands, Tokodon can work as a Pixelfed client!
Now the notifications coming from Tokodon is a little bit better. I merged a change that fixes the notification identity so it’s coming from who actually did the action. On top of that, the avatar is rounded which matches what we do inside of Tokodon as well:
I merged a bunch of small fixes which makes the Android experience a little bit better.
I landed the much needed config overhaul which fixes two major pain points: configuration location and security. We used KConfig but only for the main configuration options, not for the account information. This meant there was this odd ~/.config/KDE/tokodon.conf and contained secret information to boot. Now everything is handled by KConfig, and the volatile account information is stored separately from the main configuration options in ~/.local/share/Tokodon/tokodonstaterc (possibly moving to ~/.local/state in KDE Frameworks 6).
The account token and client secrets are now stored in your system keychain (like KWallet or GNOME Secrets)! When you start Tokodon 23.08, it will automatically migrate your config files, so there’s nothing you need to do.
Now you can share posts, images, and profiles directly from Tokodon! I think this is useful for quickly sharing between devices.
I’m also working on sharing through Tokodon! It still needs some work. My current plan is to have it open the composer if already running, or open in a standalone composer window if it isn’t.
See you next month!