A new Craft cache has just been published. The update is already available for KDE's CD, CI will follow in the next hours or days.

Please note that this only applies to the Qt6 cache. The Qt5 cache is in LTS mode since April 2024 and does not recieve major updates anymore.

Changes (highlights)

• Qt 6.7.2
• FFmpeg 7.0.1
• llvm 18.1.8
• boost 1.86.0
• OpenSSL 3.3.1 (for Android too, which was still on 1.1.1v until recently)
• CMake 3.30.0
• Ninja 1.12.1
• Removed qt-installer-framework (Windows)

About KDE Craft

KDE Craft is an open source meta-build system and package manager. It manages dependencies and builds libraries and applications from source on Windows, macOS, Linux, FreeBSD and Android.

Learn more on https://community.kde.org/Craft or join the Matrix room #kde-craft:kde.org

It's been more than three weeks since the midterm summary, and the project is now nearing completion.

Currently, all the original features of Blinken have been fully implemented in the QML version. The remaining tasks involve UI adjustments, testing, and fixing potential bugs.

Over the past few weeks, I’ve been working on the following:

Integrating Blinken's Logic

The game logic of Blinken is handled by the BlinkenGame class from the original Blinken. The original code design is quite good, with most of the game logic encapsulated in this one class. The separation between the logic and the UI rendering is well done, so all I needed to do was connect the signals from this class in QML.

As for the audio playback in Blinken, the original code used the Phonon library, which is also open-source but does not support Android. Therefore, I replaced it with the QtMultimedia library, which provides cross-platform audio playback functionality.

Android Build for KF6 Applications

Some features of Blinken rely on libraries provided by the KF6 framework, such as KF6I18n and KF6Config. When cross-compiling to the Android platform, it's necessary to use the aarch64-linux versions of these libraries. If these libraries are not available on your system, you will encounter the following errors during compilation:

ld.lld: error: /usr/lib64/libKF6XmlGui.so.6.4.0 is incompatible with aarch64linux ld.lld: error: /usr/lib64/libKF6ConfigWidgets.so.6.4.0 is incompatible with aarch64linux 
……

However, the package manager on my Fedora distribution does not provide these versions. Compiling and installing them one by one from source is too cumbersome. On the advice of the community, I used Craft to handle cross-compilation.

For reference, here is the Craft tutorial: Craft - KDE Community Wiki

Important note: If you encounter installation failures, make sure to clear all contents under craft-kde-android before trying again, as leftover files may cause the installation to fail.

When installing, choose the Arm64 target architecture. If there are remnants from a previous failed installation, it may prevent the option to select the ARM64 architecture.

If you encounter issues like "Permission denied," you’ll need to disable SELinux:

sudo apt-get install selinux-utils 
sudo setenforce 0

Additionally, note that in the virtual machine invent-registry.kde.org/sysadmin/ci-images/android-qt67 provided by the community, the Java version is outdated, preventing the use of Gradle 8.6. You can either manually update the Java version in the docker or use an older version of Gradle.

To use Craft for building applications, you need to write a script called a Blueprint, which describes the libraries your application depends on. These scripts are relatively easy to write, and you can quickly get started by following the community documentation: Craft/Blueprints - KDE Community Wiki.

Using KF6 Framework Libraries

Some of the libraries originally used by Blinken are compatible with the Android platform, while others are not. By referring to the API Documentation, you can check which libraries are supported on Android. In Blinken, the following libraries are Android-compatible:

• CoreAddons
• GuiAddons
• I18n
• XmlGui

I needed to use these libraries in the QML version of Blinken.

The KF6 framework provides a convenient internationalization API, and the usage in QML is almost the same as in QWidget, which allowed me to directly reuse Blinken’s original multi-language support, saving a lot of time.

KConfig is used in Blinken to store high score information and settings. For the high scores, I needed to extract the HighScoreManager class from the original HighScoreDialog file, make some modifications, and then create a new high score interface in QML that connects the signals and slots of HighScoreManager. For the settings functionality, it’s as simple as registering a KConfig singleton in QML :

`qmlRegisterSingletonInstance<blinkenSettings>("org.kde.blinken", 1, 0, "BlinkenSettings", blinkenSettings::self());

KF6XmlGui was used in the original Blinken to create the About Blinken Page, About KDE Page, and Handbook Page. Although this library is Android-compatible, it is based on QWidget, while the main interface of Blinken is built with QML. Bringing in QWidget just for these pages didn't seem like a good idea. Luckily, for the Android platform, kirigami-addons provides this functionality. By incorporating it, I also brought in Kirigami, which helps optimize the UI.

After adding new dependencies, it’s important to modify the .kde-ci.yml file to support CI/CD. For more information: Infrastructure/Continuous Integration System - KDE Community Wiki.

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

Why We Picked AGPL - ParadeDB

Tags: tech, foss, business

I wish more product companies would pick this license. Going for AGPL with a support and/or double license offering is a strong model in my opinion.

https://blog.paradedb.com/pages/agpl

Fellowship for Maintainers | Sovereign Tech Fund

Tags: tech, foss, economics

Interesting initiative. I’m looking forward to the results of this first pilot.

https://www.sovereigntechfund.de/programs/fellowship

Breaking Up Google

Tags: tech, google, monopoly, law, economics

Of course it sounds complicated to break Google up… but that’s not the point. It’s about avoiding its monopolistic position, the fact that it’s complicated is just another symptom.

https://micro.webology.dev/2024/08/14/breaking-up-google.html

The Dying Web

Tags: tech, google, browser, web, standard

Yes, please let’s increase the market share of non-Chromium based browsers.

https://endler.dev/2024/the-dying-web/

Hacking the Scammers

Tags: tech, security, hacking

Someone was about to get revenge, this gives an interesting exploration.

https://blog.smithsecurity.biz/hacking-the-scammers

‘Sinkclose’ Flaw in Hundreds of Millions of AMD Chips Allows Deep, Virtually Unfixable Infections | WIRED

Tags: tech, cpu, amd, security

Luckily this kind of very low level vulnerabilities are not too common and difficult to exploit. But when they get exploited all things break loose and you can’t trust your hardware anymore.

https://www.wired.com/story/amd-chip-sinkclose-flaw/

Why exploits prefer memory corruption

Tags: tech, security, memory

Interesting take, those bugs are more convenient to exploit. Logic bugs are too specific to easily exploit at scale.

https://pacibsp.github.io/2024/why-exploits-prefer-memory-corruption.html

Some thoughts on OpenSSH 9.8’s PerSourcePenalties feature

Tags: tech, security, ssh

Clearly a new OpenSSH feature to keep an eye on. This should improved security of the server by default. That said, it needs to be a bit more in the wild before knowing how to best tune it.

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/OpenSSHPerSourcePenaltiesThings

slow TCP connect on Windows

Tags: tech, windows, networking

This is indeed surprising behavior and specific to Windows. If you wonder why TCP connect is slow and you got IPv6 support active this might be why.

https://daniel.haxx.se/blog/2024/08/14/slow-tcp-connect-on-windows/

Recent Performance Improvements in Function Calls in CPython

Tags: tech, python, performance

Interesting dive into some of the performance improvements introduced into recent CPython releases.

https://blog.codingconfessions.com/p/are-function-calls-still-slow-in-python

Approximating sum types in Python with Pydantic

Tags: tech, python, type-systems

Here is an interesting use of Pydantic to properly model inputs.

https://blog.yossarian.net/2024/08/12/Approximating-sum-types-in-Python-with-Pydantic

Reflection-based JSON in C++ at Gigabytes per Second – Daniel Lemire’s blog

Tags: tech, c++, reflection, type-systems, performance

Compile time reflection in C++ will indeed be a big deal.

https://lemire.me/blog/2024/08/13/reflection-based-json-in-c-at-gigabytes-per-second/

High-precision date/time in SQLite

Tags: tech, time, databases, sqlite

Looks like a neat extension which can come in handy.

https://antonz.org/sqlean-time/

PostgreSQL masking and obfuscation tool

Tags: tech, databases, postgresql, tools

Looks like an interesting tool for creating anonymized pre-production environments.

https://greenmask.io/latest/

The fastest way to copy data between Postgres tables

Tags: tech, databases, postgresql

Need to duplicate data in Postgres? Several options are on the table.

https://ongres.com/blog/fastest_way_copy_data_between_postgres_tables/

blocking=render: Why would you do that?!

Tags: tech, web, browser, frontend, html

A new HTML attribute to keep an eye on. I can expect people to abuse it with hard to debug problems in the frontend if you don’t know it is there.

https://csswizardry.com/2024/08/blocking-render-why-whould-you-do-that/

Garbage Collection and Metastability - Marc’s Blog

Tags: tech, garbage-collector, performance, safety, memory

Interesting, it confirms garbage collectors can be the source of unrecoverable performance degradation in request based systems.

https://brooker.co.za/blog/2024/08/14/gc-metastable.html

Good Retry, Bad Retry: An Incident Story

Tags: tech, distributed, failure, recovery

Retries are becoming common place to deal with transient errors. That said, they can be a problem with recovery of longer failures due to amplification. There are options on the table to solve this though.

https://medium.com/yandex/good-retry-bad-retry-an-incident-story-648072d3cee6

The Perils of Future-Coding

Tags: tech, design, complexity, performance

Or why anticipating too much is merely a gamble. You can be lucky, but how often will you be? Also I agree that in such cases the performance will be impacted longer term leading to a death by thousands of paper cuts.

https://www.sebastiansylvan.com/post/the-perils-of-future-coding/

How we deleted 4195 code files in 9 hours - by Anton Zaides

Tags: tech, technical-debt, organization, leadership, funny

I’m not sure the incentives are right… it’s better to clean up as you go. Still some places would benefit from such an event from time to time and even if you clean up as you go missed opportunities happen.

https://zaidesanton.substack.com/p/organizing-the-best-cleanathon-your

Stop Team Topologies. Reevaluating Team Topologies

Tags: tech, organization

Surprisingly, I bumped into this article as I’m wrapping up reading the Team Topologies book. This highlight fairly well some of the concerns I have with it and where it shines. I think it’s right to turn to the principles it’s built on rather than use the model it proposes as a blueprint.

https://martyoo.medium.com/stop-team-topologies-fd954ea26eca

How to build a strategy

Tags: business, organization, management, strategy

It’s bloody hard to build a strategy. This article is full of good wisdom to make one. This won’t make it really easier, but at least you won’t start in the wrong direction and will be able to know if what you produce is any good.

https://www.cultivatedmanagement.com/how-to-build-a-strategy/

Anime girl breaking the fourth wall

Tags: tech, blender, 3d, funny

Funny short video, I guess it has also some tutorial value to know what you can do with Blender? (and no, you can’t break the fourth wall with it)

https://www.youtube.com/watch?v=gTi_-HGtsDY

Bye for now!

Can you believe it’s already been almost half a year since Plasma 6.0 came out? Time really flies! The other day I went through some of my 50+ open merge requests on KDE’s GitLab and took another stab at them. Some are four years old at this point but it definitely helped to let them sit for a while and finish them with a fresh new perspective and clear mind.

Places panel tooltip

What really grinds my gears is elided labels with no tooltip or other means to see the full text. The Places panel in Dolphin and the file dialogs is one prime example of this. While the default locations have concise names, particularly removable media can have rather long descriptions. Additionally, while you can roughly tell how full the device is by looking at the thin line underneath, there’s no way to know precisely. You either have to browse the device or access the properties dialog through the context menu. I also added the bookmark’s destination and mount points. In case of loop devices, such as ISO images, the path to its backing file is shown instead.

The main reason I haven’t merged this feature sooner is that under Wayland the tooltips didn’t follow the item as you moved the mouse. You see, Qt reuses that window and just updates its position and text for different controls. Under Wayland, however, windows cannot just position themselves on absolute coordinates. Popup windows, such as menus and tooltips, instead provide a semantic description of where they would like to be placed using an XDG Positioner (part of the XDG Shell protocol that contains many interfaces for desktop-like use cases).

It tells the compositor, among other things, where to anchor to (e.g. a button or menu item) and what to do if it ends up outside the visible area: slide the window to fit or flip it to the other side, and so on. While Qt already used XDG Positioner for the longest time, before Qt 6.8 it did not support the reposition request. Hence the tooltip was placed correctly the first time but subsequently never moved. Since I didn’t want the patch to bitrot any further, I merged it with a check for Qt Wayland >= 6.8, so please don’t be alarmed if you cannot enjoy the feature just set. I figured, we haven’t had tooltips in there for the longest time, hence not having them for another few months is better than a distracting user experience with an influx of bug reports.

Audible feedback when (un)plugging displays

Plasma 6.0 introducted support for the XDG sound theme spec which lets applications play sound effects using a semantic name. Among those are device-added and device-removed events which are played when plugging in and out a USB device. However, there’s more things you can plug into a computer. One logical candidate is output devices: is the cable even plugged in, the projector turned on, or did it just not configure the resolution correctly?

Originally, I planned to implement it as part of the devicenotifications daemon which monitors USB devices. However, once faced with the prospect of having to monitor multiple GPUs using libdrm (note that QScreen is only enabled outputs), I realized: who knows your output devices best? The compositor, of course! Therefore, I started adding output notifications to KWin. The key difference to its normal output management is that I want to be notified of an output device whenever it is present, regardless of whether it is enabled or configured. However, it turns out there’s a KDE-proprietary Wayland protocol for managing output devices for use by our display settings module. As a result I didn’t have to change KWin and could merge this functionality with the devicenotifications daemon after all!

Import VPN configuration on click

A feature both Nico and I worked on independently from each other was the ability to import a new VPN configuration by just clicking on the file. While mine was implemented as a small helper application in Plasma Network Management, Nico put the functionality into the settings module itself by launching it with a special command-line argument. The latter approach has the advantage that it doesn’t duplicate any code dealing with VPN import (it’s all plugin-based and more complicated than you think). Therefore I abandoned my merge request and will let Nico finish his instead.

Currently it only supports OpenVPN and Cisco VPN configuration files as those are the only ones to actually have a registered MIME type in shared-mime-info and can therefore participate in file type associations. If you use any other VPN provider that Plasma supports, please get in touch so we can figure out a way to support them, too.

In just three weeks a bunch of KDE developers, designers, users, stakeholders, and many others, including myself, will meet up in Würzburg, Germany, for this year’s Akademy. Come join us, it’s always great fun and attendance is free!

This will be a guide on how to generate Python bindings for your C++ library using Shiboken. Shiboken is a tool specifically created to build PySide, so it supports Qt code perfectly fine.

The steps described here require at least KDE Frameworks 6.8. I’ll use KUnitConversion as example, because it’s a small library.

We’ll start adding the building instructions. This part is mostly boilerplate code as it’s the same for any library (except for the obvious thing of changing the library name):

 1set(bindings_library "KUnitConversion")
 2
 3set(wrapped_header ${CMAKE_SOURCE_DIR}/python/bindings.h)
 4set(typesystem_file ${CMAKE_SOURCE_DIR}/python/bindings.xml)
 5
 6set(generated_sources
 7    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_module_wrapper.cpp
 8    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_wrapper.cpp
 9    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_converter_wrapper.cpp
10    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_unit_wrapper.cpp
11    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_unitcategory_wrapper.cpp
12    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_updatejob_wrapper.cpp
13    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_value_wrapper.cpp)
14
15ecm_generate_python_bindings(
16    PACKAGE_NAME ${bindings_library}
17    VERSION ${KF_VERSION}
18    WRAPPED_HEADER ${wrapped_header}
19    TYPESYSTEM ${typesystem_file}
20    GENERATED_SOURCES ${generated_sources}
21    DEPENDENCIES KF6::UnitConversion
22    QT_VERSION ${REQUIRED_QT_VERSION}
23    HOMEPAGE_URL "https://invent.kde.org/frameworks/kunitconversion"
24    ISSUES_URL "https://bugs.kde.org/describecomponents.cgi?product=frameworks-kunitconversion"
25    AUTHOR "The KDE Community"
26    README ../README.md
27)
28
29target_link_libraries(${bindings_library} PRIVATE KF6UnitConversion)
30install(TARGETS ${bindings_library} LIBRARY DESTINATION "${KDE_INSTALL_LIBDIR}/python-kf6")

Let’s see what each part does.

 1set(bindings_library "KUnitConversion")
 2
 3set(wrapped_header ${CMAKE_SOURCE_DIR}/python/bindings.h)
 4set(typesystem_file ${CMAKE_SOURCE_DIR}/python/bindings.xml)
 5
 6set(generated_sources
 7    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_module_wrapper.cpp
 8    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_wrapper.cpp
 9    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_converter_wrapper.cpp
10    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_unit_wrapper.cpp
11    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_unitcategory_wrapper.cpp
12    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_updatejob_wrapper.cpp
13    ${CMAKE_CURRENT_BINARY_DIR}/KUnitConversion/kunitconversion_value_wrapper.cpp)

The first line just defines the name of the Python library we’ll build later. Then we set the header file that includes all the necessary headers of the library. We’ll see that file later. The generated sources list is a bit more complicated, as you need to guess the names of the files generated by Shiboken. Fortunately, you can probably guess the pattern from the example above: the first two files are always the same (the name of the library + _module_wrapper or _wrapper) and the rest is the list of classes defined in your XML file (more about it later). The qt_libs variable just contains a list of the Qt modules that our library requires. You should list all of them, even if one depends on another, because otherwise Shiboken won’t be able to find the include directories.

15ecm_generate_python_bindings(
16    PACKAGE_NAME ${bindings_library}
17    VERSION ${KF_VERSION}
18    WRAPPED_HEADER ${wrapped_header}
19    TYPESYSTEM ${typesystem_file}
20    GENERATED_SOURCES ${generated_sources}
21    DEPENDENCIES KF6::UnitConversion
22    QT_VERSION ${REQUIRED_QT_VERSION}
23    HOMEPAGE_URL "https://invent.kde.org/frameworks/kunitconversion"
24    ISSUES_URL "https://bugs.kde.org/describecomponents.cgi?product=frameworks-kunitconversion"
25    AUTHOR "The KDE Community"
26    README ../README.md
27)

This is the magic part. The ecm_generate_python_bindings function takes care of running Shiboken with all the required arguments, building the Python library and a wheel file to publish it on the Python Package Index (pypi.org). It has the following arguments:

• PACKAGE_NAME: Name of the Python library.
• VERSION: Version of the resulting library.
• WRAPPED_HEADER: The header file we talked about above.
• TYPESYSTEM: XML file with the type system information.
• GENERATED_SOURCES: The list of files that Shiboken will generate.
• DEPENDENCIES: A list of libraries that the bindings require, typically the library we’re building the bindings of.
• QT_VERSION: The minimum required Qt version.
• HOMEPAGE_URL: A URL to the homepage of the project.
• ISSUES_URL: A URL where users can report bugs.
• AUTHOR: The author of the library.
• README: The README file for the Python library.

29target_link_libraries(${bindings_library} PRIVATE KF6UnitConversion)
30install(TARGETS ${bindings_library} LIBRARY DESTINATION "${KDE_INSTALL_LIBDIR}/python-kf6")

The last part links the C++ library with the Python bindings and installs it. Now let’s take a look at the header file:

1#pragma once
2
3// Make "signals:", "slots:" visible as access specifiers
4#define QT_ANNOTATE_ACCESS_SPECIFIER(a) __attribute__((annotate(#a)))
5
6#include <KUnitConversion/Converter>
7#include <KUnitConversion/Unit>
8#include <KUnitConversion/UnitCategory>
9#include <KUnitConversion/Value>

Nothing exciting there, just the list of includes (and some Qt thing that I don’t understand).

The last file you need is the typesystem definition, where you tell Shiboken which things (classes, structs, enums, namespaces…) you want to include in your bindings and how it should interpret them. You can delete or rename functions, change the return type, modify the input parameters and many other things. You may want to take a look at the documentation because the list of posible options is very large.

 1<?xml version="1.0"?>
 2<typesystem package="KUnitConversion">
 3    <load-typesystem name="typesystem_core.xml" generate="no" />
 4
 5    <namespace-type name="KUnitConversion">
 6        <enum-type name="CategoryId" />
 7        <object-type name="Converter" />
 8        <object-type name="Unit" />
 9        <object-type name="UnitCategory" />
10        <enum-type name="UnitId" />
11        <object-type name="UpdateJob" />
12        <object-type name="Value" />
13    </namespace-type>
14</typesystem>

You need to load the typesystems of the Qt libraries that you are using so Shiboken can understand what your code is referring to. They come included with PySide.

That’s all you need to generate the Python bindings for your library. The last step is building the project as you usually do.

After a long wait, Plasma Dialer 24.08 is finally out. This released is based on Qt6 and contains 17 months of bug fixing as well as small improvements all other the place.

Packager Section

You can find the package on download.kde.org and it has been signed with my Carl's GPG key.

This post is written on behalf of the LabPlot team. It’s different compared to what we usually publish on our homepage but we feel we need to share this story with our community.

Introduction

You might already know this, but finalizing a release for a project with the complexity and scope like that of LabPlot can be hard and exhausting. After our latest recent 2.11 release, we decided to take a short break and distance ourselves from coding and take care of other non-coding related tasks, like discussions around the NLnet grant for LabPlot, our ongoing GSoC projects, the roadmap for the next release, improving our documentation, the gallery on the homepage and the article about LabPlot on Wikipedia. Don’t worry, we’re already back to coding and working on new features for the next release

The article about LabPlot on Wikipedia (we are talking about the ‘EN’ version here, but the situation is similar for other languages) was completely outdated and still containing the information about LabPlot1 from Qt3/KDE3 times. The article became largely wrong with the introduction of LabPlot2 and with further developments in recent years. Among other things, the feature set described on Wikipedia was very far from being correct and complete in comparison to the description for other applications of its type.

The current situation was clear for us and it was also evident what needed to be done. Let’s go ahead and improve the article, we thought. Hey! Being able to contribute and to share your knowledge with everybody is the advantage of Wikipedia, right? Easier said than done…

Key Takeaways

But before we begin:

• Wikipedia itself points out that the purpose of Wikipedia is to benefit readers by acting as a comprehensive compendium that contains information on all branches of knowledge. For this purpose, as it is clearly stated on Wikipedia, “Wikipedia has many policies or what many consider “rules”. Instead of following every rule, it is acceptable to use common sense as you go about editing. Being too wrapped up in rules can cause a loss of perspective, so there are times when it is better to ignore a rule. Even if a contribution “violates” the precise wording of a rule, it might still be a good contribution.” Link: Use common sense.
• According to Wikipedia there is no need to read any policy or guideline pages to start editing. The five pillars of Wikipedia are a popular summary of the most important principles. And the three of the pillars are formulated as follows: 1. Wikipedia is free content that anyone can use, edit, and distribute. 2. Wikipedia’s editors should treat each other with respect and civility. 3. Wikipedia has no firm rules. And If a rule prevents you from improving or maintaining Wikipedia, ignore it.
• In this Wikipedia’s article on https://en.wikipedia.org/wiki/Wikipedia:Dispute_resolution it is stated that once sustained discussion begins, productively participating in it is a priority. Editors should focus on article content during discussions; comment on content, not the contributor. And when an editor finds a passage in an article that is biased, inaccurate, or unsourced the best practice is to improve it rather than deleting salvageable text.
• I fully acknowledge these common-sense principles. I accept the fact that some phrases of the original version of the new content added by Dariusz, another core member of the LabPlot team, might have possibly infringed a less general rule on Wikipedia, and that’s why he asked for a constructive assistance, to no effect.
• I can also accept the reality and the existence of different users with the various amount of expertise, goodwill and power. The worst case are people contributing in a subversive manner over long time to such an open project to achieve more power and authority and completely different and evil goals later, and this can also be related to users with granted power. See the recent XZ Utils backdoor. I also accept the fact that the amount of work behind the scenes on Wikipedia requires the usage of automated mechanisms and bots (“Meet the ‘bots’ that edit Wikipedia”).
• However, I cannot accept the fact that the quality of knowledge on Wikipedia can be seriously undermined by power users heavily using algorithms and blindly enforcing some subjectively selected, narrow rules against the general principles outlined above, and at the same time not being open to any constructive discussion. The fact that complete content and comments are censored and removed by users with granted power or by their (semi-)automated tools, which deceives the reader and distorts the history of the discussion, is definitely not acceptable. And this is apparently not an exception, see the links here, here and here and many other similar discussions on the internet.

Keep the above in mind while you read what happened.

The incident I want to share with you is certainly not about LabPlot and its team. It’s about the negative impact of blindly invoking algorithms or quoting a single rule by Wikipedia’s users with granted power on the overall quality of the information stored on Wikipedia. As Dariusz noticed, in economics there is the observation that “bad money” drives out the “good money” from the market (Gresham’s Law “bad money drives out good”). We wonder whether the actions of the entities like MrOllie, some of which are described in the next parts of the article, are enough to justify the introduction of a new law for Wikipedia “bad information drives out good”?

Chain of events

In order to make the content correct and to provide an up-to-date description of the project, similar to the articles for other projects mentioned e.g. on https://en.wikipedia.org/wiki/List_of_information_graphics_software, Dariusz did multiple edits of the article over the course of two days using his Wikipedia account ‘Dlaska’. Very soon after that, the entity MrOllie became aware of his changes and reverted them completely with the suggestion that it was a promotional rewrite. Then, a “user talk” with Dariusz was initiated by MrOllie:

We are all volunteers, having no benefit other than satisfaction from developing LabPlot. But sticking to the principle of intellectual honesty, Dariusz himself fully disclosed to MrOllie that he is a LabPlot team member that felt obliged to step in to correct misleading information in the article and to make the content more complete and up-to-date, because no one has done it for a long time. Unable to get any suggestions from MrOllie despite Dariusz’ requests, Dariusz removed any phrases that could even potentially have promotional qualities (e.g. rename “strongly support” to “support”). Unfortunately, even this had no effect on the actions of MrOllie, resulting in the revert of the new content.

In parallel, I joined these activities and reverted the revert done by MrOllie and provided some explanations for this step. Another “user talk” with me (I don’t have any account, you see my IP address here) was initiated by MrOllie:

After multiple back-and-forth reverts, my IP was blocked and a “Conflict of Interest on the Noticeboard” was raised by MrOllie where he quickly got the support from his peers on Wikipedia. Dariusz’ comment didn’t change anything in the overall situation:

In parallel, more seasoned Wikipedia users jumped on the bandwagon and started ‘editing’ the article by first blindly reverting the article to the version containing potentially promotional content and then removing even more and more content and references with arguments that, in our perception, didn’t make sense arguing with anymore. Any discussion seemed completely ineffective. After most of the content had been removed from the article, to the point that the new version was more deprived of content than the old version, the user Smartse added a notability tag which was later turned into a notification box to the article stating this article “may not meet Wikipedia’s general notability guideline.”. Notability is a test used by editors to decide whether a given topic warrants its own article. So in our perception this could be interpreted as a threat of removing the article completely. The size and severity of the problem we were confronted with was already obvious at this point.

After my IP was unblocked (or maybe because I just got a new IP from my ISP), I was able to reply on this noticeboard. Since I was already foreseeing it’s going to be deleted, I took a screenshot (this is also the reason why I did screenshots for all other events):

Practically immediately my reply, red-highlighted above, was deleted without any comment or note and this is how this thread looks like afterwards:

Fortunately, Dariusz, who has an account in Wikipedia, got the notification about my added reply via email:

and after clicking within seconds on the link in the email he was informed that the comment might have been deleted, and it sure was, right after it had been added.

Immediately after this, another notification box with “A major contributor to this article appears to have a close connection with its subject.” was added to the article:

and my new IP was blocked for “abusing multiple accounts” and using them for “illegitimate reasons”:

After all these deletions, see the full history of changes

This is how the article looks like in its “final version”:

In retrospect

What seems to have happened here looks like a well coordinated or even (semi-) automated chain of events with a pre-defined replies, arguments and actions. MrOllie stands out for the incredible diligence and regularity of his activity. The chart below shows the number of edits he has made by day of the week and hour (in local time), from 2008 to the present (source of the chart: https://xtools.wmcloud.org):

Also, over 75% of MrOllie’s edits are done in a semi-automated way with the help of tools on Wikipedia like Twinkle. So, this account functions like a programmed algorithm or somebody who is heavily relying on them.

Seeing no reasonable chance of correcting this situation in the context of being deprived of the right to effectively discuss the matters with entities like MrOllie, we gave up on our initial idea to improve the article.

What’s next?

After reading more on this subject we realized that this problem is not new, but apparently it is not common knowledge either. Completely independent of who or what censored us – AI bots (is AI already winning over us?), good or bad editors etc. – trusting Wikipedia now is much harder than before. Still, the question remains about what to do next.

We can completely give up the idea of contributing to this platform and rather focus on other channels like our homepage and other online resources in the KDE and free world (Mastodon, etc) and provide more and more useful information.

Alternatively, we can ask for support from other people with more experience in editing and maybe even with more authority on Wikipedia to help us to get a reasonable description of the project on Wikipedia to the benefit of Wikipedia’s readers and LabPlot’s users.

Thoughts?

Links

For the sake of completeness and of easier usage, here are the links mentioned in my reply that were deleted:

• https://www.reddit.com/r/WikipediaVandalism/comments/154e6zn/please_investigate_mrollie_farm/
• https://www.reddit.com/r/wikipedia/comments/hqiekq/who_is_mrollie/
• https://thomashgreco.medium.com/artificial-intelligence-bots-and-censorship-why-wikipedia-can-no-longer-be-trusted-ded395123ba9
• https://x.com/LifeBeyondD/status/1763935505987629323

Note, for the first two links above, the original posts in the Wikipedia related channels on Reddit about the same MrOllie account on Wikipedia were deleted, shame on those who think evil of this. The comments are still available, though, and the reader can get at least an idea about the original content of those posts.

Edit

We added a short post about the article to r/wikipedia on Reddit, but it was removed by the moderators just 2 hours later, without any comment.

If, after reading this article, you think MrOllie and his counterparts are capable of correcting their own actions, take a look at the exchange below. It’s also an indication of what the future may hold for the LabPlot article on Wikipedia… Source: https://en.wikipedia.org/w/index.php?title=User_talk:MrOllie&oldid=1240636433

Update (20.08.2024)

We’ve been informed that a Wikipedia’s editor (Smartse) has today nominated the article about LabPlot for deletion, so before making any hasty, not to say retaliative, decisions, we encourage Wikipedia editors to reach a sensible “consensus” in the context of information published on these websites:

• https://labplot.kde.org/references
• https://en.wikipedia.org/wiki/List_of_statistical_software
• https://en.wikipedia.org/wiki/List_of_information_graphics_software
• https://en.wikipedia.org/wiki/Comparison_of_numerical-analysis_software

The last three links refer to Wikipedia’s articles about other applications similar to LabPlot. As far as we know, none of them have been nominated for deletion. In the meantime the article has been given a “protected” status.

Update (21.08.2024)

So far we have provided a list of nearly 50 research papers from various scientific fields that show that LabPlot has been used for research and teaching purposes. It would be unreasonable to expect researchers dealing with domain problems to devote a significant part of their research papers to describing LabPlot. In contrast, the following article is devoted entirely to LabPlot. The professors Williams Morales González and Jesús Eleuterio Hernández-Ruíz described the program’s functionality and usage in detail [1]. This fits into the Wikipedia’s General notability guideline:

• “A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject.”
• “Sources do not have to be written in English” and “there is no fixed number of sources required.”
• “Notability is based on the existence of suitable sources, not on the state of sourcing in an article.”

Below is a (semi-)automatic translation of the authors’ conclusions:

The experiences of the professors of the Experimental Physics group of the UCLV Physics program in the use of LabPlot as a tool for the analytical and graphical processing of experimental data were presented.

LabPlot is a free, open source, multiplatform software with KDE desktop design and similar characteristics to Origin. It is intended for interactive analysis of experimental data and includes a wide variety of operations for analytical and graphical data processing, including linear and nonlinear fitting and data extraction from external plots, without the need for licensed software.

LabPlot can be used as a tool for experimental data processing, not only in Experimental Physics, but also in the scientific work developed by students from the second year of the course and culminating with the diploma work.

Does this information have any real relevance to Wikipedia editors? Time will tell.

[1] Williams Morales González. Jesús Eleuterio Hernández-Ruíz. 2022. Experiencias en el uso del software LabPlot en el procesamiento analítico y gráfico de datos experimentales. Conference: VII Taller de Enseñanza de la Física At: Universidad de Oriente, Santiago de Cuba. https://www.researchgate.net/publication/361586279_Experiencias_en_el_uso_del_software_LabPlot_en_el_procesamiento_analitico_y_grafico_de_datos_experimentales.

I want to thank you Dariusz for his contributions to this article.

I’ve realized that it’s been nearly a month since the last update about my GSoC project, so it’s time to publish a new one.

I’ve been upstreaming the Python bindings to their corresponding repositories and addressing the comments. Many thanks to Nico, Christophe, Volker, Ben and Carl (my mentor) for their comments! The CMake part has improved a lot and it’s almost ready to be merged. CI support should be ready for FreeBSD and Linux. We can add support for Windows if people are interested.

I’ll probably write a tutorial on how to add Python bindings to a library next week.

Most of the time programmers do not write new code. Instead, they read, try to understand,  extend, and fix bugs in existing code. While some parts of KDE are pretty new and follow modern standards, many parts are more then two decades old -- following obsolete coding principles, using outdated ways of solving problems, and having additions from several persons with different styles. Often when we read code, we immediately spot things we could improve.

Kent Beck's approach is applying a series of small tidyings that leads to structural change and an overall better software design. In his new book Tidy First? he describes his idea in three parts: Tidyings, how to manage tidyings, and software design theory.

In the first part the author introduces generic tidyings like dead code removal, moving declaration and initialization together, introducing new interfaces, or explicit parameters. Most proposals are not new, but it is a good reminder to follow them and fix these things wherever you come across them in code you are working with. After reading the first part, I felt motivated to create some tidying commits right away. For KDE more specific tidying could be added: Fix deprecation warnings from Qt and KF, replace C-style code by C++, use modern C++ (range-base for loop, initialization lists), fix compiler warnings.

The second part gives hints on how to organize and commit tidyings. Separate tidyings from new features or behavioral changes. Find a balance between asking for review of your tidyings too often or with too extensive reviews.

In the third part Kent Beck offers some basic ideas from software design, especially future options and code coupling.

The book is worth reading for both commercial and open-source developers. Both are facing similar issues. Open-source developers are not worrying about costs, but precious spare time dedicated to coding for their pet project. Every projects has bit rot and profits from regular tidyings by their developers.

People interested in software design will recognize the ideas from classic books like Structured Design or Refactoring: Improving the Design of Existing Code. Nevertheless, Tidy First? makes the knowledge easily accessible. Most chapters are only one to three pages long and the book stays below a hundred pages.

This is the first book of a planned series of small books. Kent Beck develops his ideas in his blog (partially pay-walled) and discusses his views with his readers. Some blog post make it into Kevin's weekly web reviews.