A few weeks ago (Time flies!) I attended the KDE Goals Sprint in Berlin. I didn't have concrete plans, but I intended to look into accessibility. Quite some time ago I had improved the accessibility of Kleopatra and at Akademy 2023 in Thessaloniki I gave a talk about it. Back then I had taken the easy route fixing everything directly in Kleopatra and working around several issues in Qt instead of fixing the issues in Qt itself so that all apps could profit. Time to do something about it.

(In-)Accessible icon-only buttons

A common problem for accessibility is icon-only buttons. If a button doesn't have text then screen readers can only tell their user that there's a button. That's not very helpful. Sometimes the developers have at least assigned a tool tip to the button. This can be read out by the screen readers (Qt provides the tool tip as accessible description of the button.), but it's often too verbose. To make a button without text accessible the developer has to set the accessible name property of the widget or, in case of a Qt Quick app, the name property of the Accessible QML Type. Unfortunately, that's often forgotten if the UI isn't designed with accessibility in mind.

At the sprint I discussed several ideas with other participants to help developers remember to set the accessible name:

• A helper class to instantiate in your app which inspects the app's windows and prints a report at the end with all inaccessible icon-only buttons it has found. A bit like Qt's QAbstractItemModelTester or the different compiler sanitizers. I implemented a prototype of such a class, but didn't pursue this further. The downside of this approach is that the developer needs to open each window of the app to find all inaccessible buttons. If they are already aware of the problem then it's probably easier to search the code.
• Instead of using a helper class to inspect the widget tree from the inside one could inspect the accessibility tree of the app from the outside. This could be built into our Appium-driven UI test framework so that developers don't have to do anything special. Except that they need to write UI tests that open each and every window of their app. I think it's still worth to look into this.
• Last but not least, we pondered writing a clazy test. Thinking about the many different ways a text can be set on a button (e.g. with KGuiItem::assign) we doubted that it would be feasible to write such a test.

In the end the easiest approach could be education. If the developers are aware of the problem then there's a good chance that they remember to set an accessible name the next time they add an icon-only button to their app.

Accessible date/time inputs

Volker, Carl, David, Harald and me discussed and explored some ideas to make the date and time inputs in Qt Quick apps like Itinerary accessible. In Kleopatra I resorted to allow the user to enter the date in a simple text input instead of trying to make the complex UI of KDE's date picker accessible. Read Volker's blog and David's blog to find out which solutions they found for Qt Quick apps.

A small automation interlude

One advantage of sitting with other people in the same room is that you may overhear them talking about a mistake (e.g. a faulty commit) and you know exactly how to prevent this kind of mistake in the future. In this case the problem was a missing quote character in some YAML file. And the preventive measure was adding a YAML linter CI job. While I was at it I removed some unnecessary code from the CI job and added the job to a second repository.

List views with underlying multi-column model

In several widgets that show or use a simple list of items Qt allows using a model with multiple columns, e.g. QListView, QComboBox, QCompleter. In general this works well except that Qt has a long-standing bug: When navigating through the list screen readers read the entries of the underlying model column by column instead of reading only the entries in the selected model column (QTBUG-33786). In Kleopatra I worked around this bug with a proxy model which pretended that the model only had one column.

During the sprint I finally sat down and prepared a fix for Qt. For better readability I split my changes in five separate commits which resulted in five separate patches for Qt: 556857, 556858, 556859, 556860, 556861. Being used to multi-commit MRs in GitLab I wondered if I had done something wrong when I submitted my changes, but apparently that's Gerrit's way of handling patch reviews. The first two commits are code clean-ups, the third commit changes one aspect of the accessibility test for list views, the fourth commit is the actual fix, and the fifth commit adds a few more unit tests I find useful. The first three commits have been merged, but the actual fix is still waiting for a review.

After that I looked into the problem that QListView emitted an accessibility focus event when the current item changed even if the list view didn't have focus. I found out that this had been fixed recently by a fellow Qt contributor who ran into the same problem independently of me. This meant that I could remove the workaround in Kleopatra for new enough Qt.

Thanks to MBition for hosting us and to Aleix for making sure we don't starve. And many thanks to those donating to KDE which makes these sprints possible.

This is a brief overview of the project that I will be doing this summer as part of Google Summer of Code.

As the title of this post says, I will create Python bindings for KDE Frameworks. There are more than 70 libraries, so the aim is to add support for three of them: KWidgetsAddons, KCoreAddons and KI18n. As predicting how much time we’ll need for each one is a little bit complex, I might end adding support to other libraries if the time allows.

To create the library we’ll use Shiboken, a tool originally created to generate the Python bindings of Qt (PySide6), but it can also be used with non-Qt code. The plan is to have the library be built automatically by the CI on invent.kde.org. I will also add documentation and examples on how to use it.

I still need to figure out a name for the Python library that we hope to upload to PyPI once it becomes usable.

The project is mentored by Carl Schwan, who also proposed the idea.

The MarkNote team is happy to announce the 1.2 release of MarkNote, KDE’s WYSIWYG note-taking application. Marknote lets you create rich text notes and easily organise them into notebooks. You can personalise your notebooks by choosing an icon and accent color for each one, making it easy to distinguish between them and keep your notes at your fingertips. Your notes are saved as Markdown files in your Documents folder, making it easy to use your notes outside of Marknote as well as inside the app.

Notes management

This releases brings highly wanted features like the ability to choose a custom folder where to store your notes. Mathis Brüchert also added the ability to change the sorting of notes from alphabetically to by date.

Mathis made the sidebar collapsable and added a focus mode where everything but the editing page is displayed.

Finally if you prefer to just use Marknote as a Markdown editor, we made it possible to just open any markdown files directly from the file browser or the console. Additionally Marknote supports markdown files with a so called front matter, which is a common way to inject metadata to markdown in static website generators like Hugo and Jekyll.

Editing

In term of edition support, the subset of markdown supported increased again. Now it is possible to add and edit tables.

Additionally we started transforming inline markdown directly to rich text as you type. Support is limited to a few markdown constructs but is likely to grow over time.

You can now customize the font used by editor.

Aside from being able to edit text, it’s now possible to also create sketches directly from MarkNote.

Mobile Support

Mathis took care of ensuring MarkNote was fully usable when used with Plasma Mobile.

Windows and macOS support

Marknote now provides nightly builds for Windows and macOS. While the Windows builds should be fully usable, the macOS build still has an issue where most icons are not displayed. This should be fixed as soon as we can make use of the new KIconTheme version.

As part of the work to improve the macOS support, Marknote also gained global menu support for Linux.

Others

• The command bar will show translated shortcuts. (Laurent Montel)
• Unify spelling of MarkNote and fix typos in the README.md (Jonah Brüchert)

Get Involved

Mathis created a Matrix channel for MarkNote: #marknote:kde.org. There is also still a lot of small improvements that can be done everywhere and which don’t require a lot of programming experience. Take a look at these two tasks !31 and !27 for some inspiration on what you could work on.

Let’s go for my web review for the week 2024-20.

Password cracking: past, present, future

Tags: tech, security

Ever wondered about the state of the art in password cracking? This is not an easy read but a good reference.

https://www.openwall.com/presentations/OffensiveCon2024-Password-Cracking/

Beyond public key encryption – A Few Thoughts on Cryptographic Engineering

Tags: tech, cryptography

There are other cryptography schemes out there with interesting properties. Too bad they’re not very much used.

https://blog.cryptographyengineering.com/2017/07/02/beyond-public-key-encryption/

SSD death, tricky read-only filesystems, and systemd magic?

Tags: tech, system, hardware, failure

Strange things do happen when the hardware fails… indeed the systemd open question at the end is mysterious.

https://rachelbythebay.com/w/2024/05/15/ro/

The new APT 3.0 solver | Blog of Julian Andres Klode

Tags: tech, debian, packaging

Interesting work. This is nice to see improvements and experiments in dependency solvers for package managers.

https://blog.jak-linux.org/2024/05/14/solver3/

Extensions for GNU Make

Tags: tech, tools, make

Looks like nice extensions to use GNU Make to run simple tasks.

https://github.com/mitjafelicijan/makext

Which filepath-join behavior is implemented for relative and absolute paths as arguments?

Tags: tech, system, filesystem

You expect joining file paths to be a simple operation? Think again, it’s definitely error prone and can change between stacks.

https://lukas-prokop.at/articles/2024-05-03-filepath-join-behavior

What even is a pidfd anyway?

Tags: tech, processes, system, linux

Definitely a recent and lesser known to interact with other processes. Could be useful in some cases.

https://www.corsix.org/content/what-is-a-pidfd

An informal comparison of the three major implementations of std::string - The Old New Thing

Tags: tech, c++, performance, memory

Interesting quick comparison, this shows the design tradeoffs quite well.

https://devblogs.microsoft.com/oldnewthing/20240510-00/?p=109742

GPUs Go Brrr · Hazy Research

Tags: tech, gpu, hardware, ai, machine-learning, neural-networks, performance

Interesting how much extra performance you can shave off the GPU by going back to how the hardware works.

https://hazyresearch.stanford.edu/blog/2024-05-12-tk

Sir, there’s a cat in your mirror dimension

Tags: tech, graphics, mathematics, funny

Funny experiment playing with the frequency domain and the spatial domain of an image. This gives unintuitive results for sure.

https://lcamtuf.substack.com/p/sir-theres-a-cat-in-your-mirror-dimension

Snapshot Testing For the Masses

Tags: tech, tests, snapshots

This is a technique which is definitely underestimated. There are plenty of libraries out there allowing to use them.

https://tigerbeetle.com/blog/2024-05-14-snapshot-testing-for-the-masses

Laurence Tratt: What Factors Explain the Nature of Software?

Tags: tech, programming, software, craftsmanship, engineering

Good food for thought. Explains quite well the factors which impact software development.

https://tratt.net/laurie/blog/2024/what_factors_explain_the_nature_of_software.html

Bye for now!

So, recently, I shifted some of my workload to kde. And I started my KDE journey with KDE Neon. Even with a 2 year old base and packages, snaps and ppas saved me. Now, one of the important part of my work was to clone the repo using ssh. And here comes the problem.

In gnome, the gnome-keyring and the seahorse would automatically manage my ssh and gpg key passphrases. But, in KDE, that didn’t happen. On the starting I was getting frustrated with the ssh always asking me the passphrase. Then after a lot of reading manuals and internet searching, I found out about ksshaskpass. This can be used to write my passphrase and there I can set it to remember my passphrase, which it would essentially save in kwallet. So, How did I set this up?

Edit 2024-05-21: applications for this position are closed.

KDE e.V., the non-profit organisation supporting the KDE community, is looking for a graphic designer to implement materials (print design, logo design, infographics, etc.) for a new environmental sustainability campaign within KDE Eco. Please see the job ad for more details about this employment opportunity.

We are looking forward to your application.

So this is not quite an introduction since the plugin has been around for almost a year now, having been released in the 23.04 release but since I never got around to writing a blog about it, here I am.

In simple words, the formatting plugin allows one to format code easily and quickly. Well the "quickness" depends on the underlying code formatter but we try to be as quick as possible. So far if you wanted to do code formatting from within Kate, the only way to do that was to configure a tool in the External Tools plugin and then invoke it whenever you wanted to format the code. While this works it wasn't great for a few reasons. Firstly, you would loose undo history. Secondly, the buffer would jump and you would most likely loose your current position in the document. Thirdly, for every language you get a different tool and you need to remember the right tool to invoke on the right document type.

To simplify this, I decided to write a plugin that would expose a minimal UI but still provide a lot of features.

There are basically two ways to use this plugin:

• Manually using the "Format Document" action.
• Automatically on save

The correct formatter is invoked based on the document type in all cases. Additionally the plugin will preserve the document's undo history and user's cursor position when formatting the code so that the formatting of code doesn't disrupt user's workflow. This is especially important for automatic formatting on save.

Supported languages:

The current list of supported languages and formatters are as follows:

• C/C++/ObjectiveC/ObjectiveC++/Protobuf
  • clang-format
• Javascript/Typescript/JSX/TSX
  • Prettier
• Json
  • clang-format
  • Prettier
  • jq
• Dart
  • dartfmt
• Rust
  • rustfmt
• XML
  • xmllint
• Go
  • gofmt
• Zig
  • zigfmt
• CMake
  • cmake-format
• Pythong
  • autopep8
  • ruff

Configuring

The plugin can be configured in two ways:

• Globally, from the Configure dialog
• On a per project basis using the .kateproject file

When reading the config, the plugin will first try to read the config from .kateproject file and then read the global config.

Example:

{
 "formatOnSave": true,
 "formatterForJson": "jq",
 "cmake-format": {
 "formatOnSave": false
 },
 "autopep8": {
 "formatOnSave": false
 }
}

The above

• enables "format on save" globally
• specifies "jq" as the formatter for JSON
• disables "format on save" for cmake-format and autopep8

To configure formatting for a project, first create a .kateproject file and then add a "formatting" object to it. In the "formatting" object you can specify your settings as shown in the previous example. Example:

{
 "name": "My Cool Project",
 "files": [
 {
 "git": 1
 }
 ],
 "formatting": {
 "formatterForJson": "clang-format",
 "autopep8": {
 "formatOnSave": false
 }
 }
}

A few weeks ago I attended the KDE Goals April 2024 sprint

I was there as part of the Automation & Systematization sprint given my involvement in the release process, the "not very automatized" weekly emails about the status of CI about KDE Gear and KDE Frameworks, etc. but I think that maybe I was there more as "person that has been around a long time, ask me if you have questions about things that are documented through oral tradition"

I didn't end up doing lots of work on sprint topics themselves (though I participated in various discussions, did a bit of pair-programming with Aleix on QML accessibility issues, inspired DavidR to do the QML-text-missing-i18n check that he describes in his blog); instead I cheated a bit and used the sprint to focus on some of the KDE stuff I had a bit on my backlog, creating the KDE Gear release/24.05 branches and lots of MR reviewing and more!

Thanks KDE e.V. for sponsoring the trip, if you would like such events to continue please we need your continued donations

And remember Akademy talk submission period ends in 10 days, send your talk now!

A new revision of digiKam Recipes is available for your reading pleasure. The new version covers the auto tagging feature introduced in digiKam 8.3 and explains how to run digiKam in a container.

If you bought the book through Gumroad, you’ll find the new revision in the Library section. The book purchased through Google Play should be updated automatically to the latest version. If you have problems getting the latest revision of the book, contact the author at dmpop@cameracode.coffee

The Kubuntu Team are thrilled to announce significant updates to KubuQA, our streamlined ISO testing tool that has now expanded its capabilities beyond Kubuntu to support Ubuntu and all its other flavors. With these enhancements, KubuQA becomes a versatile resource that ensures a smoother, more intuitive testing process for upcoming releases, including the 24.04 Noble Numbat and the 24.10 Oracular Oriole.

What is KubuQA?

KubuQA is a specialized tool developed by the Kubuntu Team to simplify the process of ISO testing. Utilizing the power of Kdialog for user-friendly graphical interfaces and VirtualBox for creating and managing virtual environments, KubuQA allows testers to efficiently evaluate ISO images. Its design focuses on accessibility, making it easy for testers of all skill levels to participate in the development process by providing clear, guided steps for testing ISOs.

New Features and Extensions

The latest update to KubuQA marks a significant expansion in its utility:

• Broader Coverage: Initially tailored for Kubuntu, KubuQA now supports testing ISO images for Ubuntu and all other Ubuntu flavors. This broadened coverage ensures that any Ubuntu-based community can benefit from the robust testing framework that KubuQA offers.
• Support for Latest Releases: KubuQA has been updated to include support for the newest Ubuntu release cycles, including the 24.04 Noble Numbat and the upcoming 24.10 Oracular Oriole. This ensures that communities can start testing early and often, leading to more stable and polished releases.
• Enhanced User Experience: With improvements to the Kdialog interactions, testers will find the interface more intuitive and responsive, which enhances the overall testing experience.

Call to Action for Ubuntu Flavor Leads

The Kubuntu Team is keen to collaborate closely with leaders and testers from all Ubuntu flavors to adopt and adapt KubuQA for their testing needs. We believe that by sharing this tool, we can foster a stronger, more cohesive testing community across the Ubuntu ecosystem.

We encourage flavor leads to try out KubuQA, integrate it into their testing processes, and share feedback with us. This collaboration will not only improve the tool but also ensure that all Ubuntu flavors can achieve higher quality and stability in their releases.

Getting Involved

For those interested in getting involved with ISO testing using KubuQA:

• Download the Tool: You can find KubuQA on the Kubuntu Team Github.
• Join the Community: Engage with the Kubuntu community for support and to connect with other testers. Your contributions and feedback are invaluable to the continuous improvement of KubuQA.

Conclusion

The enhancements to KubuQA signify our commitment to improving the quality and reliability of Ubuntu and its derivatives. By extending its coverage and simplifying the testing process, we aim to empower more contributors to participate in the development cycle. Whether you’re a seasoned tester or new to the community, your efforts are crucial to the success of Ubuntu.

We look forward to seeing how different communities will utilise KubuQA to enhance their testing practices. And by the way, have you thought about becoming a member of the Kubuntu Community? Join us today to make a difference in the world of open-source software!