Planet KDE

The jury of this year’s KDE Akademy Awards, being by tradition representatives of last year’s winners, has selected the hex editor Okteta in the category “Best Application”. Thanks to them for this appreciation, even more for a niche application

Though, appreciation for what, as there are no details? The last new feature was added in 2019, with the 17th patch release since just done. So, for a reliable program with no need to relearn the UI every year and proudly close to zero open actual bug reports? Then the port to Qt6/KF6, while started in 2022, might be only completed in 2025… if ever. So rather, is this an end-of-life award for an aged 16 years old program?

Looking Back

Triggered by the event some reflection on the past development, if only for the author himself, to update the memories how one got here and what it brings for the future. Which turned into a longer text than anticipated

2003-2006: Years of Initial Need for a Widget

The Okteta project was born in 2003 , the known first code traces date back to May 13th, 2003. The first related code was imported into KDE’s code repository in August 15th, 2003, by the commit message:

Initial import of KHexEdit2, featuring a widget, a kpart and an app.
Most important is the widget...
Hopefully it will be usable enough ready for KDE 3.2...

The name “KHexEdit2” was chosen as the project was a re-implementation of KHexEdit, the hex editor part of KDE since KDE 1.1. Because those times I was trying to create a viewer for executables and libraries (project name Binspekt, stalled soon), for which I wanted a widget for displaying bytes. KHexEdit seemed to have no code that could be cleanly ripped out and be reused, so work started to code such a widget from scratch and respectively also consumers of it, to add more reason & motivation.

The formal request on September 29th that year to then move the project’s code from the “kdenonbeta” area into release-covered areas had this optimistic line in it:

Finally there will be an app, build around the ReadWritePart. In 2004.

Turned out, life did not agree to that plan, thus 2004 passed without any such app. And so did 2005.

Still, back in February 2004 as part of KDE 3.2 the first elements of the still named KHexEdit2 project made a first release. Though with a bit of complexity. ((Note that at this time KDE was still also the name of the released bundle product, composed of the so called modules kdelibs, kdebase, kdeutils, etc. Where kdelibs held all the public libraries, kdebase the basic desktop components, and so on.)) As adding a complete implementation of a hexeditor widget to the official kdelibs for just a few potential users was declared unbalanced, instead just some header files with KHE namespaced abstract interface classes were added, with an inline utility method to dynamically load any plugin implementing them. So not increasing the actual runtime and installation size of kdelibs. And the kdeutils module got to provide such a plugin by the name KBytesEdit. This then was implemented by the hex editor widget library from the KHexEdit2 project, also in the kdeutils module, whose own API and headers were kept private. To confuse everyone this library was yet named libkhexedit, even if the actual KHexEdit program did not use it. Because the spirit of the naming was on the level of widgets and classes, not program names, and there the 2 postfix made no sense. Consumers of this construct became at least the utility app for Palm Pilot handhelds KPilot and the debugger plugin of the IDE KDevelop.

In March 2005 KDE 3.4 then included the KHexEdit2 KPart (read-only) as well, also located in the kdeutils module and also implemented using the private libkhexedit library. Making some people unhappy as it registered (like its Okteta successor still does today) as handler for the MIME type application/octet-stream, so popping up as fallback KPart where no other handler was found,. And seeing raw bytes over nothing has been partially perceived as “broken”

2006-2008: Second Try on a Program, as Sample and with new Dedicated Name

2006 arrived, and with the author there was still some ever developing curiosity about the feasibility of writing viewer & editor programs using some higher-level reusable & exchangeable components. Now a byte array is a pretty simple data structure to use for a sample implementation of such a concept. And here we had a widget implementation for byte array viewing and editing fully under our control. And a certain level of skills with C++ acquired at the time. This was just too tempting to not give it an own try, for fun and experience. So a June blog post “Fun with KHexEdit” also mentioned a program again and introduced the name designed meanwhile:

I am tackling the construction of a successor to KHexEdit again, projectname “Okteta”.

Later that year a first visual snippet was shared, showing how KHexEdit’s UI served as initial template for Okteta, also to potentially help the transfer of existing users:

November 2006: first published screenshot of Okteta in some pre-Alpha state

To avoid duplicated efforts and to increase pressure to deliver, two weeks later on November 27th an optimistic email was sent to KDE’s great eternal to-newer-API porting worker Laurent Montel, as it was the time to port KDE software to Qt4/KDELibs4:

Hi Laurent,

please don't spend too much effort at the old program KHexEdit, I am quite far
on the way to write a successor, called Okteta. Concerning feature
compatibility, so far I implemented around 60 % of the features of KHexEdit,
and hope to do the last 40 % until at least January. Yes, no code yet in SVN
(besides the library), but that will change in three weeks, promised.
[...]

This time life agreed mainly to the plan. Though the promise on the code in SVN was delivered on only with almost a year delay. A first dump of the program code was committed into KDE’s code repository on October 23rd, 2007, by the commit message:

Uploading the Okteta program into KDE's playground, so the code isn't lost, after growing slowly only on my hdd for more than a year. Okteta is a planned successor to KHexEdit, yet misses all of it's functionality. With it's modular architecture, based on the co-developed lib kakao, it should soon offer more than would could be done with the monolithic KHexEdit. I hope.

As can be read, this first copy also was featuring a first draft for the own before mentioned higher-level component system, initially named “Kakao”, later in 2009 to be renamed to “Kasten”. That first name was made ad-hoc inspired by a drink on the table (in learned safe distance from the keyboard), to soon find it used similarly by some certain bigger IT company, even for a somehow related subject, thus a new name was by the time designed less ad-hoc.

And so some months later in April 2008 Okteta entered the “kdereview” phase, to proceed after two weeks into the kdeutils module. In time for KDE 4.1, so premiering its release as part of that in July 2008. Okteta here also took over to provide the KBytesEdit plugin for the kdelibs KHE interfaces as well as the KPart, which before had resided in subdirectories of the KHexEdit program sources. KHexEdit itself stayed unported to Qt4/KDELibs4, so Okteta as planned did not run into duplicated efforts and rivalry (or, it avoided competition, for good and bad).

July 2008: Okteta’s first release, as version 0.1, part of KDE 4.1 2008-2012: Years of Features Flow

With the foundations laid and releases established as part of KDE releases, the next years saw a number of features added, initially even each KDE version:

January 2009: new features in Okteta 0.2, part of KDE 4.2 August 2009: new features in Okteta 0.3, part of KDE 4.3 February 2010: new features in Okteta 0.4, part of KDE SC 4.4 July 2011: new features in Okteta 0.7, part of KDE Applications 4.7 August 2012: new features in Okteta 0.9, part of KDE Applications 4.9 2010-Present: Sharing Functionality in Rich Public Libraries

From the very begin of the project on the byte array viewing & editing feature was embeddable by 3rd-party software using the abstract KHE interfaces in kdelibs, or then the KPart at least for viewing, Though this allowed only little control & features due to a limited API.

Starting with Okteta 0.4 in February 2010, the two sets of underlying libraries, Kasten and Okteta ones, used to implement the Okteta program, the Okteta KPart and the KHE KBytesEdit plugin, are provided with stable public API.

The lower-Qt-level Okteta GUI library also started to be accompanied by a Qt Designer plugin, to allow easy use of the two provided classes of widgets also in Qt’s UI files.

February 2010: new Okteta widgets plugin for Qt Designer, part of Okteta 0.4

In February 2010 during a week-long Kate-KDevelop development meeting in Berlin the intended flexibility of the new public libraries proofed itself by enabling to create a plugin for KDevelop to integrate hex viewing & edting and all the Okteta tools in just those few days, for some nice satisfaction. The plugin was officially released first with KDevelop 4.1 in October 2010 and later also ported to the Qt5/KF5 version of KDevelop. For the current Qt6/KF6-based version of KDevelop the plugin is excluded from the build for now, given the current lack of a released Qt6/KF6-based version of the Okteta and Kasten libraries.

October 2010: Okteta plugin for KDevelop, first released with KDevelop 4.1 2012-Present: Switching from Features to Architecture, from Bundled to Stand-Alone

The port to Qt5/KF5 happened without any issues and was completed for version 0.15, released as part of KDE Applications 14.12. During the transformation of KDELibs4 to KDE Frameworks 5 the KHE interfaces also got dropped there, due to Okteta meanwhile directly providing public libraries. So this ported version of Okteta also no longer provided the KBytesEdit plugin, but otherwise as before the public libraries and the KPart, next to the program itself.

After KDE Applications 17.12, as for a while there was no feature development and only occasional work on the design of the Okteta & Kasten libraries happened, the Okteta project switched to a stand-alone release schedule. A 0.25 version branch was created and patch version releases only done when there were user-relevant changes like bug fixes or bigger translation improvements.

Then 2019 brought the first version and for now also latest to also provide at least one new feature to users, for which a 0.26 version branch was created. This version has meanwhile got 17 patch releases, with bug fixes, translation improvements and other adjustments. And after 5 years of such polishing is the one which now received the “Best Application” 2024 Akademy Award

March 2019: new features in Okteta 0.26, released on own schedule 2022-Present: Preparing for Qt6 & KF6

Okteta’s code base has been mostly quickly updated to any API deprecations, also as part of a “zero build warnings” strategy. So the approach taken for both Qt & KF libraries to strive for source-backward-compatible C++ API in their both new major version 6 made the initial port of Okteta to Qt6 & KF6(-Alpha) a matter of less than a day in May 2022. Now, only if one ignores one of the tools.

May 2022: preview of Okteta port to Qt6/KF6

The Structures tool, first developed by Alexander Richardson in 2010 for Okteta 0.4, was in 2011 for Okteta 0.7 extended by him to also support dynamic structure definitions, using JavaScript expressions. For this QtScript has been used as engine. Four years later, in July 2015 though Qt 5.5 declared QtScript as deprecated. The officially recommended substitute QJSEngine turned out to not allow the dynamic translation of JavaScript properties and methods as relied on by the Structures tool for the copy-avoiding mapping of the data blob interpretation into the JavaScript scene (beware, for what the author understands so far). So it could not be used as drop-in replacement.

As finding a suitable and more future-proof JavaScript engine or exploring a possible reimplementation using the QJSEngine is a complex task and also needs bigger chunks of time & focussing, it had been postponed. Year after year. And thus now nine years later in 2024 there is still not even a plan. And Qt6 no longer now provides QtScript.

Just dropping the Structures tool is not a real option. It is a great feature, which also got some users. So a plan is needed and work to be done by someone. As of now my own, surely radical idea is to rewrite the whole Structures tool from scratch, still for the Qt5/KF5 version of Okteta. This should lead to fully wrapping the brain around this complex feature, instead of seeing to indirectly explore it by trying to understand all the details of the current elaborated implementation with the risk to misinterpret some intentions. Starting from scratch might also allow to finally share all the code used for the data formats in the separate Decoding Table tool, and perhaps even to introduce a more generic approach on the data formats supported in the main mass display besides currently byte values and 8-bit charset mapping. Idea, Should, Trying, Starting, Might, Perhaps… any words of confidence, please?

For now the initial Qt6/KF6 port is maintained by a single commit containing the complete dump of the “it builds, starts and does not crash on simple usage” changes, in a work branch continuously rebased to the latest current Qt5/KF5-based development branch. This commit would then at the time of the real Qt6/KF6 port be properly split into the different aspects of porting. For now it serves to hold the door open while still on the other side.

Looking Forward, by Looking Back Some More

For sure the initial goal with the Okteta program to do something for fun and experience has been largely achieved The current challenge with the needed replacement of the used JavaScript engine promises more experience, though no fun initially to me at least.

And some feedback as well even a KDE Akademy Award now hint the created and publicly shared program also served other people for their serious and less serious needs. Possibly even some desperate Faust-like persons, “So that they may perceive the bytes which hold their doc[ument] together in its inmost fold.” (and even tweak them for better as needed, owning their world or document). Though no contracts done, and thus no souls here owned.

But as before, Okteta actually is just a sample implementation of the actual interest pursued here, exploring the feasibility of writing programs by higher-level reusable & exchangeable components, ideally also allowing random end users to mesh those components themselves into tailored solutions for certain needs. So if development has stalled as it has, both on the components concept but also the hex editing features, how to increase motivation again to set resources aside, and for which part?

Position in the Hex Editor Solution Space

When it comes to the Free Software solution space for hex editor needs, next to Okteta there is currently coverage starting from simple ones like GHex over wxHexEditor, which serves needs beyond Okteta by support for paged loading of big files and also the working memory, though sadly unmaintained currently, to the newer yet most impressive and very powerful ImHex (by what the web pages show, never tried).

So would people suffer if Okteta is gone for current platforms, at least for a while?

Open Component Systems vs. Closed Monolithic Blobs

Now the author, while being curious, never got around to actually study existing solutions for the concept of higher-level component system or even deploy them in projects, only ever saw some theoretic surfaces. And is fully aware of the own experiment turning into something serious rather being a pipe dream. Even more when after soon two decades the initially created TODO list is not even 10 % done, this won’t work out this single human’ life So the following is more like the wish-wash of a hobbyist bird watcher, while also having some chicken in the backyard to which things are compared. Or alike.

It seems composable systems with complex interfaces are not the dominating species in the Free Software ecosystems. The Linux kernel outpaced any microkernel systems, e.g. Gnu Hurd is yet to be spotted outside OS zoos. The Eclipse Rich Client Platform, whose concepts were one of the original by-headlines inspirations for this project, seems to have maxed out some time ago as well. at least in the mainstream through the author’s bubble space. StarOffice^WOpenOffice^WLibreOffice has the UNO component system, but how many Add-Ons flourish on it? Then GnuStep would have enabled to spread the component concepts of OpenStep, but little has be seen? The later GnuStep-related, indeed thriving for stars impressive project Étoilé seemed to be overloaded with related ideas, but sadly never lift off. Then the GNOME project even had a reference to component systems in its initial full name “GNU Network Object Model Environment”, but its respective Bonobo framework based on CORBA faded away rather soon.

Also KDE started initially with implementations around the idea of components. To quote the KDE 1.0 announcement:

In view of these circumstances the KDE Project has developed a first rate compound document application framework, implementing the latest advances in framework technology and thus positioning itself in direct competition to such popular development frameworks as for example Mircrosoft’s MFC/COM/ActiveX technology. KDE’s KOM/OpenParts compound document technology enables developers to quickly create first rate applications implementing cutting edge technology. KDE’s KOM/OpenParts technology is build upon the open industry standards such as the object request broker standard CORBA 2.0.

KOM/OpenParts was then in KDE 2.0 replaced by KParts. Actually the presence of such technology development was the deciding factor to go for KDE when the author those days got into “Linux” and had to choose between GnuStep, Enlightenment, GNOME and KDE. These days though KDE is run with claims like “All About Apps”. The generic KServices system got destructed for KF6. The possibly latest KPart (a Markdown Viewer) was written years ago by this author, and the once KDE-central KPart-driven program Konqueror is only a shadow of its former self. KOffice & Calligra as component-oriented office suites also died or stalled close to extinction. Generic plugins like the KParts are not even listed on apps.kde.org or elsewhere anymore, also no longer mentioned as concept in KDE Gear release announcements. Similar specific plugins like the Plasma applets, they are also not listed separately, but only as part of the respective, in the example, Plasma products.

Additionally packaging formats like Flatpak or Snap are discussion-less embraced and promoted, which push in the direction of isolated and frozen software programs. Even today does Flatpak’s metadata system appstream. also otherwise discussion-less embraced by KDE, not have a concept of generic plugins, so KParts cannot be described properly.

In such an environment a component system would be limited to predefined fixed component sets in libraries, from which applications would then provide a setup and offer that to users. A bit like being able to shop as consumer at the kitchen equipment store only preset exhibition rooms, instead of meshing up items from different providers into ones’ own tailored meal preparations “app”. Surely it is in the interest of the dominating providers who then will see to bundle only their items, and then add bloat as well as only making half the items good. As consumer I desire to have the choice over pre-made bundles vs. self-assembled ones. Like there are times for All-inclusive vacations and times for self-organized ones. So with current KDE but also the larger current Free Software “desktop” scene as real world development environment working on and thinking about component systems has the author feel at odds.

So maybe the experiment with Kasten as a higher-level component system could also stop here. Perhaps some research instead could be done why such systems failed in comparison. Like, was it due to the inflexibility presented by fixed published interfaces, where on new feature needs implementations cannot simply do temporary shortcuts and adaptions where needed to be quick back to the market? Could it be due to the possible need for more abstract and generic thinking with component systems, where the majority of developers working for the market might prefer to think more concrete and case-by-case? Then, might there still be a middle-ground, where any advantages of high-level component systems are the deciding factor in the competition?

Next Release Scheduled: October 10th, version 0.26.18

As described already for the early stages, there always have been ideas and plans.. and delays… and also doubts… and then things happened. Locally there are lots of notes with ideas, and a number of code drafts and sketches stacked by the years. And at least in the near future it seems there are still time windows, electricity, a laptop, and enough human capabilities to carry on and tinkering over this stack.

The Okteta (& Kasten) project for now is alive, just lurking around in front of the next evolution step to take. Which might find it new ground. Or extinction anyway. And while it is lurking, it gets a tad more feathers polished, by another bug fix release already scheduled for next month

Recap

In Part 1, we covered PCM audio and superimposing waveforms, and developed an algorithm to combine an arbitrary number of audio streams into one.

Now we need to use these ideas to finish a full implementation using Qt Multimedia.

Using Qt Multimedia for Audio Device Access

So what do we need? Well, we want to use a single QAudioOutput, which we pass an audio device and a supported audio format.

We can get those like this:

const QAudioDeviceInfo &device = QAudioDeviceInfo::defaultOutputDevice(); const QAudioFormat &format = device.preferredFormat();

Let’s construct our QAudioOutput object using the device and format:

static QAudioOutput audioOutput(device, format);

Now, to use it to write data, we have to call start on the audio output, passing in a QIODevice *.

Normally we would use the QIODevice subclass QBuffer for a single audio buffer. But in this case, we want our own subclass of QIODevice, so we can combine multiple buffers into one IO device.

We’ll call our subclass MixerStream. This is where we will do our bufferCombine, and keep our member list of streams mStreams.

We will also need another stream type for mStreams. For now let’s just call it DecoderStream, forward declare it, and worry about its implementation later.

One thing that’s good to know at this point is DecoderStream objects will get the data buffers we need by decoding audio data from a file. Because of this, we’ll need to keep our audio format from above to as a data member mFormat. Then we can pass it to decoders when they need it.

Implementing MixerStream

Since we are subclassing QIODevice, we need to provide reimplementations for these two protected virtual functions:

virtual qint64 QIODevice::readData(char *data, qint64 maxSize); virtual qint64 QIODevice::writeData(const char *data, qint64 maxSize);

We also want to provide a way to open new streams that we’ll add to mStreams, given a filename. We’ll call this function openStream. We can also allow looping a stream multiple times, so let’s add a parameter for that and give it a default value of 1.

Additionally, we’ll need a user-defined destructor to delete any pointers in the list that might remain if the MixerStream is abruptly destructed.

// mixerstream.h #pragma once #include <QAudioFormat> #include <QAudioOutput> #include <QIODevice> class DecodeStream; class MixerStream : public QIODevice { Q_OBJECT public: explicit MixerStream(const QAudioFormat &format); ~MixerStream(); void openStream(const QString &fileName, int loops = 1); protected: qint64 readData(char *data, qint64 maxSize) override; qint64 writeData(const char *data, qint64 maxSize) override; private: QAudioFormat mFormat; QList<DecodeStream *> mStreams; };

Notice that combineSamples isn’t in the header. It’s a pretty basic function that doesn’t require any members, so we can just implement it as a free function.

Let’s put it in a header mixer.h and wrap it in a namespace:

// mixer.h #pragma once #include <QtGlobal> #include <limits> namespace Mixer { inline qint16 combineSamples(qint32 samp1, qint32 samp2) { const auto sum = samp1 + samp2; if (std::numeric_limits<qint16>::max() < sum) return std::numeric_limits<qint16>::max(); if (std::numeric_limits<qint16>::min() > sum) return std::numeric_limits<qint16>::min(); return sum; } } // namespace Mixer

There are some very basic things we can get out of the way quickly in the MixerStream cpp file. Recall that we must implement these member functions:

explicit MixerStream(const QAudioFormat &format); ~MixerStream(); void openStream(const QString &fileName, int loops = 1); qint64 readData(char *data, qint64 maxSize) override; qint64 writeData(const char *data, qint64 maxSize) override;

The constructor is very simple:

MixerStream::MixerStream(const QAudioFormat &format) : mFormat(format) { setOpenMode(QIODevice::ReadOnly); }

Here we use setOpenMode to automatically open our device in read-only mode, so we don’t have to call open() directly from outside the class.

Also, since it’s going to be read-only, our reimplementation of QIODevice::writeData will do nothing:

qint64 MixerStream::writeData([[maybe_unused]] const char *data, [[maybe_unused]] qint64 maxSize) { Q_ASSERT_X(false, "writeData", "not implemented"); return 0; }

The custom destructor we need is also quite simple:

MixerStream::~MixerStream() { while (!mStreams.empty()) delete mStreams.takeLast(); }

readData will be almost exactly the same as the implementation we did earlier, but returning qint64. The return value is meant to be the amount of data written, which in our case is just the maxSize argument given to it, as we write fixed-size buffers.

Additionally, we should call qAsConst (or std::as_const) on mStreams in the range-for to avoid detaching the Qt container. For more on qAsConst and range-based for loops, see Jesper Pederson’s blog post on the topic.

qint64 MixerStream::readData(char *data, qint64 maxSize) { memset(data, 0, maxSize); constexpr qint16 bitDepth = sizeof(qint16); const qint16 numSamples = maxSize / bitDepth; for (auto *stream : qAsConst(mStreams)) { auto *cursor = reinterpret_cast<qint16 *>(data); qint16 sample; for (int i = 0; i < numSamples; ++i, ++cursor) if (stream->read(reinterpret_cast<char *>(&sample), bitDepth)) *cursor = Mixer::combineSamples(sample, *cursor); } return maxSize; }

That only leaves us with openStream. This one will require us to discuss DecodeStream and its interface.

The function should construct a new DecodeStream on the heap, which will need a file name and format. DecodeStream, as implied by its name, needs to decode audio files to PCM data. We’ll use a QAudioDecoder within DecodeStream to accomplish this, and for that, we need to pass mFormat to the constructor. We also need to pass loops to the constructor, as each stream can have a different number of loops.

Now our constructor call will look like this:

DecodeStream(fileName, mFormat, loops);

We can then use operator<< to add it to mStreams.

Finally, we need to remove it from the list when it’s done. We’ll give it a Qt signal, finished, and connect it to a lambda expression that will remove the stream from the list and delete the pointer.

Our completed openStream function now looks like this:

void MixerStream::openStream(const QString &fileName, int loops) { auto *decodeStream = new DecodeStream(fileName, mFormat, loops); mStreams << decodeStream; connect(decodeStream, &DecodeStream::finished, this, [this, decodeStream]() { mStreams.removeAll(decodeStream); decodeStream->deleteLater(); }); }

Recall from earlier that we call read on a stream, which takes a char * to which the read data will be copied and a qint64 representing the size of the data.

This is a QIODevice function, which will internally call readData. Thus, DecoderStream also needs to be a QIODevice.

Getting PCM Data for DecodeStream

In DecodeStream, we need readData to spit out PCM data, so we need to decode our audio file to get its contents in PCM format. In Qt Multimedia, we use a QAudioDecoder for this. We pass it an audio format to decode to, and a source device, in this case a QFile file handle for our audio file.

When a QAudioDecoder‘s start method is called, it will begin decoding the source file in a non-blocking manner, emitting a signal bufferReady when a full buffer of decoded PCM data is available.

On that signal, we can call the decoder’s read method, which gives us a QAudioBuffer. To store in a data member in DecodeStream, we use a QByteArray, which we can interact with using QBuffers to get a QIODevice interface for reading and writing. This is the ideal way to work with buffers of bytes to read or write in Qt.

We’ll make two QBuffers: one for writing data to the QByteArray (we’ll call it mInputBuffer), and one for reading from the QByteArray (we’ll call it mOutputBuffer). The reason for using two buffers rather than one read/write buffer is so the read and write positions can be independent. Otherwise, we will encounter more stuttering.

So when we get the bufferReady signal, we’ll want to do something like this:

const QAudioBuffer buffer = mDecoder.read(); mInputBuf.write(buffer.data<char>(), buffer.byteCount());

We’ll also need to have some sort of state enum. The reason for this is that when we are finished with the stream and emit finished(), we remove and delete the stream from a connected lambda expression, but read might still be called before that has completed. Thus, we want to only read from the buffer when the state is Playing.

Let’s update mixer.h to put the enum in namespace Mixer:

#pragma once #include <QtGlobal> #include <limits> namespace Mixer { enum State { Playing, Stopped }; inline qint16 combineSamples(qint32 samp1, qint32 samp2) { const auto sum = samp1 + samp2; if (std::numeric_limits<qint16>::max() < sum) return std::numeric_limits<qint16>::max(); if (std::numeric_limits<qint16>::min() > sum) return std::numeric_limits<qint16>::min(); return sum; } } // namespace Mixer Implementing DecodeStream

Now that we understand all the data members we need to use, let’s see what our header for DecodeStream looks like:

// decodestream.h #pragma once #include "mixer.h" #include <QAudioDecoder> #include <QBuffer> #include <QFile> class DecodeStream : public QIODevice { Q_OBJECT public: explicit DecodeStream(const QString &fileName, const QAudioFormat &format, int loops); protected: qint64 readData(char *data, qint64 maxSize) override; qint64 writeData(const char *data, qint64 maxSize) override; signals: void finished(); private: QFile mSourceFile; QByteArray mData; QBuffer mInputBuf; QBuffer mOutputBuf; QAudioDecoder mDecoder; QAudioFormat mFormat; Mixer::State mState; int mLoopsLeft; };

In the constructor, we’ll initialize our private members, open the DecodeStream in read-only (like we did earlier), make sure we open the QFile and QBuffers successfully, and finally set up our QAudioDecoder.

DecodeStream::DecodeStream(const QString &fileName, const QAudioFormat &format, int loops) : mSourceFile(fileName) , mInputBuf(&mData) , mOutputBuf(&mData) , mFormat(format) , mState(Mixer::Playing) , mLoopsLeft(loops) { setOpenMode(QIODevice::ReadOnly); const bool valid = mSourceFile.open(QIODevice::ReadOnly) && mOutputBuf.open(QIODevice::ReadOnly) && mInputBuf.open(QIODevice::WriteOnly); Q_ASSERT(valid); mDecoder.setAudioFormat(mFormat); mDecoder.setSourceDevice(&mSourceFile); mDecoder.start(); connect(&mDecoder, &QAudioDecoder::bufferReady, this, [this]() { const QAudioBuffer buffer = mDecoder.read(); mInputBuf.write(buffer.data<char>(), buffer.byteCount()); }); }

Once again, our QIODevice subclass is read-only, so our writeData method looks like this:

qint64 DecodeStream::writeData([[maybe_unused]] const char *data, [[maybe_unused]] qint64 maxSize) { Q_ASSERT_X(false, "writeData", "not implemented"); return 0; }

Which leaves us with the last part of the implementation, DecodeStream‘s readData function.

We zero out the char * with memset to avoid any noise if there are areas that are not overwritten. Then we simply read from the QByteArray into the char * if mState is Mixer::Playing.

We check to see if we finished reading the file with QBuffer::atEnd(), and if we are, we decrement the loops remaining. If it’s zero now, that was the last (or only) loop, so we set mState to stopped, and emit finished(). Either way we seek back to position 0. Now if there are loops left, it starts reading from the beginning again.

qint64 DecodeStream::readData(char *data, qint64 maxSize) { memset(data, 0, maxSize); if (mState == Mixer::Playing) { mOutputBuf.read(data, maxSize); if (mOutputBuf.size() && mOutputBuf.atEnd()) { if (--mLoopsLeft == 0) { mState = Mixer::Stopped; emit finished(); } mOutputBuf.seek(0); } } return maxSize; }

Now that we’ve implemented DecodeStream, we can actually use MixerStream to play two audio files at the same time!

Using MixerStream

Here’s an example snippet that shows how MixerStream can be used to route two simultaneous audio streams into one system mixer channel:

const auto &device = QAudioDeviceInfo::defaultOutputDevice(); const auto &format = device.preferredFormat(); auto mixerStream = std::make_unique<MixerStream>(format); auto *audioOutput = new QAudioOutput(device, format); audioOutput->setVolume(0.5); audioOutput->start(mixerStream.get()); mixerStream->openStream(QStringLiteral("/path/to/some/sound.wav")); mixerStream->openStream(QStringLiteral("/path/to/something/else.mp3"), 3); Final Remarks

The code in this series of posts is largely a reimplementation of Lova Widmark’s project QtMixer. Huge thanks to her for a great and lightweight implementation. Check the project out if you want to use something like this for a GPL-compliant project (and don’t mind that it uses qmake).

About KDAB

If you like this article and want to read similar material, consider subscribing via our RSS feed.

Subscribe to KDAB TV for similar informative short video content.

KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.

The post Implementing an Audio Mixer, Part 2 appeared first on KDAB.

Ruqola 2.3.0 is a feature and bugfix release of the Rocket.chat app.

New features:

• Implement Rocket.Chat Marketplace.
• Allow to clean room history.
• Allow to check new version.
• Implement moderation (administrator mode).
• Add welcome page.
• Implement pending users info (administrator mode).
• Use cmark-rc (https://github.com/dfaure/cmark-rc) for markdown support.
• Delete oldest files from some cache directories (file-upload and media) so it doesn't grow forever.

Fixed bugs:

• Clean market application model after 30 minutes (reduce memory footprint).
• Fix show discussion name in completion.
• Fix duplicated messages in search message dialog.
• Add delegate in search rooms in team dialog.

URL: https://download.kde.org/stable/ruqola/
Source: ruqola-2.3.0.tar.xz
SHA256: 051186793b7edc4fb2151c80ceab3bcfd65acb27d38305568fda54553660fdd0
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Riddell jr@jriddell.org
https://jriddell.org/jriddell.pgp

Qt for MCUs 2.8.1 LTS (Long-Term Support) has been released and is available for download.  This first patch release provides bug fixes and other improvements while maintaining source compatibility with Qt for MCUs 2.8. It does not add any new functionality.

This year was my first Akademy, and I was thrilled to be able to attend in person. Even better, some veterans said it was the best Akademy so far. It was great to see some people I had met in April and to meet new people. I arrived on Friday, 6th Sept and left the following Friday. I very much enjoyed staying in the lovely town of Würzburg and doing a day tour of Rothenberg. Now that I've caught up on sleep (the jet lag, it is real), it's time to write about it.

As described in the Akademy 2024 report, the focus this year was resetting priorities, refocusing goals and reorganizing projects. Since I had recently become a more active contributor to KDE, I was keen to learn about the direction things will take over the next year. It was also exciting to see the new design direction in Union and Plasma Next!

A Personal Note

Speaking of goals, a personal one I've striven toward in my career is to contribute to something that improves the world, even if indirectly. It's not something I've always been able to do. It feels good to be able to work with a project that is open source, and is working to make the computing world more sustainable.

I'd also like to recognize all the wonderful, welcoming folks that make Akademy such a great conference. I've been to a few other tech conferences and events, with varying atmospheres and attitudes. I can say that people at Akademy are so helpful, and so nice - it made being among a lot of new faces in a foreign country a truly great experience.

The Conference

The keynote had powerful information about the impacts of improper tech disposal and what we can do to improve the situation. This highlighted the importance of the KDE Eco project, which aims to help to reduce e-waste and make our projects more sustainable. Their new Opt Green initiative is going to take concrete steps toward this.

Some of the talks I attended:

• KDE Goals - one talk about the last 2 years of goals and another revealing the new goals.
• "Adapt or Die" - how containerized packaging affects KDE projects.
• Union and styling in KDE's future.
• Banana OS KDE Linux - why it's being developed and some technical planning.
• Getting Them Early: Teaching Pupils About The Environmental Benefits Of FOSS This strategy has been powerful for other projects (like Microsoft Windows, Google Chromebooks, Java), so I'm glad to see it for KDE.
  • Why and how to use KDE frameworks in non-KDE apps
  • KDE Apps Initiative
  • Cutting Gordian's "End-User Focus" vs. "Privacy" Knot - collecting useful user data while respecting privacy and security.
  • Plasma Next - Visual Design Evolution for Plasma
  • The Road to KDE Neon Core

BoF Sessions

Some of the BoF sessions I attended:

• Decentralizing KUserFeedback
• Streamlined Application Development Experience
• Organizing the Plasma team, Plasma goals
• Plasma "Next" initiative
• Union: The future of styling in KDE
• KWallet modern replacement
• Video tutorial for BoF best practice (Kieryn roped me into this one)
• Security Team BoF Notes

Thanks to everyone who made this year's Akademy such a wonderful experience. If anyone out there is thinking of attending next year, and can make it, I really recommend it. I'm hoping to be at Akademy 2025!

Contrary to popular belief, Akademy 2024 was not my first Akademy. KDE seems to keep tagged faces from Akademy group photos around, so I stumbled over some vintage pictures of me in 2006 (Glasgow) and 2007 (Dublin). At the time, I was an utter greenhorn with big dreams, vague plans, and a fair bit of social anxiety.

And then I disappeared for 15 years, but now it's time for a new shot. This time around, I'm a little less green (rather starting to grey a little) and had a surprising amount of stuff to discuss with various KDE collaborators. Boy, is there no end of interesting people and discussion topics to be had at Akademy.

"Oh, you're the PowerDevil guy"

You're not wrong, I've been contributing to that for the past year. As such, one highlight for me was to meet KDE's hardware integration contractor Natalie Clarius in person and sync up on all things power-related.

Natalie presented a short talk and hosted a BoF session ("Birds of a Feather", a.k.a. workshop) about power management topics. We had a good crowd of developers in attendance, clearing up the direction of several outstanding items.

Power management in Plasma desktops is in decent shape overall. One of the bigger remaining topics is (re)storing battery charge limits across reboots, for laptops whose firmware doesn't remember those settings. There is a way forward that involves making use of the cross-desktop UPower service and its new charge limit extensions. This will give us the restoring feature for free, but we have to add some extra functionality to make sure that charge threshold customization remains possible for Plasma users after switching over.

We also looked at ways to put systems back to sleep that weren't supposed to wake up yet. Unintended wake-ups can happen e.g. when the laptop in your backpack catches a key press from the screen when it's squeezed against the keyboard. Or when one of those (conceptually neat) "Modern Standby" implementations on recent laptops are buggy. This will need a little more investigation, but we've got some ideas.

I talked to Bhushan Shah about power saving optimizations in Plasma Mobile. He is investigating a Linux kernel feature designed for mobile devices that saves power more aggressively, but needs support from KDE's power management infrastructure to make sure the phone will indeed wake up when it's meant to. If this can be integrated with KDE's power management service, we could improve battery runtimes for mobile devices and perhaps even for some laptops.

The friendly people from Slimbook dropped by to show off their range of Linux laptops, and unveiled their new Slimbook VI with KDE neon right there at the conference. Compared to some of their older laptops, build quality is improved leaps and bounds. Natalie and I grilled their BIOS engineer on topics such as power profiles, power consumption, and how to get each of their function keys show the corresponding OSD popup.

"I'm excited that your input goal was chosen"

Every two years, the KDE community picks three "Goals" to rally around until the next vote happens. This time, contributors were asked to form teams of "goal champions" so that the work of educating and rallying people does not fall on the shoulders of a single poor soul per goal.

So now we have eight poor souls who pledge to advance a total of three focus areas over the next two years. Supported by KDE e.V.'s new Goals Coordinator, Farid. There's a common thread around attracting developers, with Nicolas Fella and Nate Graham pushing for a "Streamlined Application Development Experience" and the KDE Promo team with a systematic recruitment initiative titled "KDE Needs You". And then there's this other thing, with a strict end user focus, briefly introduced on stage by guess who?

Turns out a lot of people in KDE are passionate about support for input devices, virtual keyboards and input methods. Gernot Schiller (a.k.a. duha) realized this and assembled a team consisting of himself, Joshua Goins (a.k.a. redstrate) as well as Yours Truly to apply as champions. The goal proposed that "We care about your Input" and the community's response is Yes, Yes We Do.

As soon as the new goals were announced, Akademy 2024 turned into an Input Goal Akademy for me. In addition to presenting the new goal on stage briefly, we also gathered in a BoF session to discuss the current state, future plans and enthusiastic volunteering assignments related to all things input. I also sat down with a number of input experts to learn more about everything. There is still much more I need to learn.

It's a sprawling topic with numerous tasks that we want to get done, ranging from multi-month projects to fixing lots of low-hanging fruit. This calls for a series of dedicated blog posts, so I'll go into more detail later.

Join us at #kde-input:kde.org on Matrix or watch this space (and Planet KDE in general) for further posts on what's going on with input handling in KDE.

Look at the brightness side

KWin hacker extraordinaire Xaver Hugl (a.k.a. zamundaaa) demoed some of his color magic on a standard SDR laptop display. Future KWin can play bright HDR videos in front of regular SDR desktop content. Accurate color transformations for both parts without special HDR hardware, that's pretty impressive. I thought that HDR needs dedicated hardware support, turns out I'm wrong, although better contrast and more brightness can still improve the experience.

I also got to talk to Xaver about touchpad gestures, learned about stalled attempts to support DDC/CI in the Linux kernel directly, and pestered him for a review to improve Plasma's D-Bus API for the new per-monitor brightness features. Also the XDC conference in Montreal, is happening in less than a month, featuring more of Xaver as well as loads of low-level graphics topics. Perhaps even input-related stuff. It's only a train ride from Toronto, maybe I'll drop by. Maybe not. Here's a medieval German town selfie.

Thanks to the entire KWin gang for letting me crash their late-night hacking session and only throwing the last of us out at 2 AM after my D-Bus change got merged. Just in time for the Plasma 6.2 beta. I was dead tired on Thursday, totally worth it though.

Atomic KDE for users & developers

Plasma undoubtedly has some challenges ahead in order to bring all of its power and flexibility to an image-based, atomic OS with sandboxed apps (i.e. Flatpak/Snap). David Edmundson's talk emphasized that traditional plugins are not compatible with this new reality. We'll need to look into other ways of extending apps.

The good news is that lots of work is indeed happening to prepare KDE for this future. Baloo making use of thumbnailer binaries in addition to thumbnailer plugins. KRunner allowing D-Bus plugins in addition to shared libraries. Arjen Hiemstra's work-in-progress Union style being customizable through configuration rather than code. Heck, we even learned about a project called KDE Neon Core trying to make a Snap out of each and every piece of KDE software.

Going forward, it seems that there will be a more distinct line between Plasma as a desktop platform and KDE apps, communicating with each other through standardized extension points.

All of this infrastructure will come in handy if Harald Sitter's experimental atomic OS, KDE Linux (working title), is to become a success. Personally, I've long been hoping for a KDE-based system that I can recommend to my less technical family members. KDE Linux could eventually be that. Yes, Fedora Kinoite is also great.

What took me by surprise about Harald's presentation was that it could be great even as a development platform for contributing to the Plasma desktop itself.

As a desktop developer, I simply can't run my Plasma development build in a container. Many functions interact with actual hardware so it needs to run right on the metal. On my current Arch system, I use a secondary user account with Plasma installed into that user's home directory. That way the system packages aren't getting modified - one does not want to mess with system packages.

But KDE Linux images contain the same system-wide build that I would make for myself. I can build an exact replacement with standard KDE tooling, perhaps a slight bit newer, and temporarily use it as system-wide replacement using systemd-sysext. I can revert whenever. KDE Linux includes all the development header files too, making it possible to build and replace just a single system component without building all the rest of KDE.

Different editions make it suitable for users anywhere between tested/stable (for family members) and bleeding edge (for myself as Plasma developer). Heck, perhaps we'll even be able to switch back and forth between different editions with little effort.

Needless to say, I'm really excited about the potential of KDE Linux. Even without considering how much work it can save for distro maintainers that won't have to combine outdated Ubuntu LTS packages with the latest KDE desktop.

Conclusion

There's so much else I've barely even touched on, like NLnet funding opportunities, quizzing Neal Gompa about KDE for Enterprise, Rust and Python binding efforts, Nicolas Fella being literally everywhere, Qt Contributor Summit, finding myself in a hostel room together with fellow KDE devs Carl & Kåre. But this blog post is already long enough. Read some of the other KDE blogs for more Akademy reports.

Getting home took all day and jet lag isn't fun, but I've reasonably recovered to give another shot at bringing KDE software to the masses. You can too! Get involved, donate to KDE, or simply enjoy the ride and discuss this post on KDE Discuss.

Or don't. It's all good :)

From Fri, Sep 6th to Tue, Sep 10th I attended the 2024 edition of KDE Akademy in Würzburg, Germany. I booked a room in a hotel downtown the same place CoLa, a fellow KDE developer, stayed. Since parking is rather expensive in downtown areas, I left the car in front of the university building where the event was about to start on Saturday morning and took the bus into the city to the hotel. We all used the bus in coming days and one would always meet some KDE folks easy to spot wearing their lanyards.

On Friday night the KDE crowd gathered at a pub in the city and it was great to see old friends and also meet new people. At some point, I was talking to Carlos. It turned out that he already made some contributions to KMyMoney. The git log says it was in 2022. While more and more fellow KDE developers joined the place it became louder and louder and conversations were not easy anymore. Too bad that some of us got stranded at different places on their way out to Würzburg and did not make it until Saturday.

Conference

On Saturday, the conference program started with a keynote by Joanna Murzyn who took us on a journey from crucial mineral mining hubs to electronic waste dumpsters, uncovering the intricate connections between code, hardware, open source principles as well as social and environmental justice. We discovered how the KDE community’s work is shaping a more resilient, regenerative future, and explore ways to extend those principles to create positive impact beyond tech world.

On the first day, I took the opportunity to see the following talks

• Current Developments in KDE Hardware Integration
• KDE to Make Wines — Using KDE Software on Enterprise Desktops a Return on Experience
• KWin Effects: The Next Generation
• Adapt or Die: How new Linux packaging approaches affect wider KDE
• An Operating System of Our Own
• What’s a Maintainer anyway?

The last one for the day complemented the keynote in a nice way. In KDE newcomer Nicole Teale’s talk entitled “Getting Them Early: Teaching Pupils About The Environmental Benefits Of FOSS” she presented the work she is doing introducing KDE/FOSS to pupils, with a focus on its environmental benefits. She shared ideas on how to get schools involved in teaching pupils about reusing old hardware with FOSS. and presented some of the projects that have already been implemented in schools in Germany. This project is funded by the Umweltbundesamt (UBA) called “Sustainable Software For Sustainable Hardware”. The goal of this project is to reduce e-waste by promoting the adoption of KDE / Free & Open Source Software (FOSS) and raising awareness about the critical role software plays in the long-term, efficient use of hardware.

This becomes important in 2025 when Windows 10 runs out of support and Windows 11 requires new hardware, even though the existing one is still perfectly suited for the requirements of the majority of people. Linux and KDE to the rescue.

Saturday ended with Pizza and beer at the university as the booked beer garden canceled the reservation due to approaching thunderstorms.

On Sunday, I saw the following talks

• Openwashing – How do we handle (and enforce?) OSS policies in products?
• Opt In? Opt Out? Opt Green! KDE Eco’s New Sustainability Initiative
• KDE’s CI and CD infrastructure
• The Road to KDE Neon Core — Gosh! We’re surrounded by Snaps everywhere!

and of course the KDE Akademy award ceremony. In between those talks I had a chance to meet Julius Künzel and take a look at the problems we have in the KMyMoney project with the MacOS CD builds. He spotted a few things but I did not have the time to take care of them yet.

As a tradition, on Sunday is also the gathering to take the group picture. Here’s this years edition:

CC-BY-SA 4.0 by Andy Betts Birds of a feather sessions

On Monday and Tuesday I went to various BoF’s and took the opportunity to join the git/Gitlab presentation by Natalie Clarius. I learned a few subtleties of Gitlab that I didn’t know before, so it was worth it. In the meantime I talked with a lot of people and did a small bit of hacking (one bug fixed). The BoFs I joined:

• Opt Green / KDE Eco
• Tutorial: Using lager with Qt/QML
• KDE Goals – Streamlined Application Development Experience
• KDE Linux
• CI / CD

Good-bye Akademy 2024 / Thank you volunteers

Tuesday afternoon was the time to wave good-bye to the fellow KDE people and drive back home which I reached without delay (no traffic on the road) after an hour and a half. Hopefully, I will be able to join next time. Next stop will be the auditing of KDE accounting coming up in Berlin in a few weeks.

A big thank you goes out to the numerous volunteers who made this event happen. The team around seaLne just did a marvelous job.

Back from the fun of Akademy in Würzburg we can now get to the important task of testing Plasma 6.2 beta. It’s now in KDE neon testing edition which we build from the Git branches which will be used to make the 6.2 final release in 2.5 weeks time. Grab it now or if you don’t have a machine to install it on you can try the Docker images using the simple command `neondocker -p -e testing`.

We are happy to announce the release of Qt Tools for Android Studio 3.0. It can be downloaded from the JetBrains marketplace.  

Back from Akademy

Welcome to the first post in our "This Week in KDE Apps" series! You may have noticed that Nate's "This Week in KDE" blog posts no longer cover updates about KDE applications. KDE has grown significantly over the years, making it increasingly difficult for just one person to keep track of all the changes that happen each week in Plasma, and to cover the rest of KDE as well.

After discussing this at Akademy, we decided to create a parallel blog series specifically focused on KDE applications, supported by a small team of editors. This team is initially constituted by Tobias Fella, Joshua Goins and Carl Schwan.

Our goal is to cover as much as possible of what's happening in the KDE world, but we also encourage KDE app developers to collaborate with us to ensure we don't miss anything important. This collaboration will take place on Invent and on Matrix #this-week-kde-apps:kde.org.

We plan to publish a new blog post every Sunday, bringing you a summary of the previous week's developments.

This week we look at news regarding NeoChat, KDE's Matrix chat client; Itinerary, the travel assistant that lets you plan all your trips; the Gwenview image viewer; our sleek music player Elisa; KleverNotes, KDE's new note-taking application; the KStars astronomy software; and Konsole, the classic KDE terminal emulator loaded with features and utilities.

We also look at how Android support has been subtly improved, and the effort to clean up our software catalogue, retiring unmaintained programs and getting rid of cruft.

Let's get started!

NeoChat

Emojis in NeoChat are now all correctly detected by using ICU instead of a simple regex. (Claire, NeoChat 24.08.2, Link)

On mobile, NeoChat doesn't open any room by default any more, offering instead a list rooms and users. (Bart Ribbers, NeoChat 24.08.02, Link)

Filtering the list of users is back! (Tobias Fella, NeoChat 24.08.02, Link)

Itinerary

The seat information on public transport is now displayed in a more compact layout. (Carl Schwan, Itinerary 24.12.0, Link)

Gwenview

Rendering previews for RAW images is now much faster as long as KDcraw is installed and available (Fabian Vogt, Gwenview 24.12.0, Link)

Elisa

We fixed playing tracks without metadata (Pedro Nishiyama, Elisa 24.08.2, Link)

KleverNotes

The KleverNotes editor now comes with a powerful highlighter. (Louis Schul, KleverNotes 1.1.0, Link)

KStars

The scheduler will now show a small window popup graphing the altitude of the target for that night. (Hy Murveit, KStars 3.7.0, Link)

Konsole

You can set the cursor's color in Konsole using the OSC 12 escape sequence (e.g., printf '\e]12;red\a'). (Matan Ziv-Av, Konsole 24.12.0, Link)

Android Support

The status bars on Android apps now follow the colors of the Kirigami applications (Volker Krause, Craft backports, Link)

Cleaning Up

We have archived multiple old applications with no dedicated maintainers and no activity. This applies to Kuickshow, Kopete and Trojita, among others. Link

...And Everything Else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out Nate's blog and KDE's Planet, where you can find more news from other KDE contributors.

Get Involved

The KDE organization has become important in the world, and your time and contributions have helped achieve that status. As we grow, it’s going to be equally important that your support become sustainable.

We need you for this to happen. You can help KDE by becoming an active community member and getting involved. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to be a programmer, either. There are many things you can do: you can help hunt and confirm bugs, even maybe solve them; contribute designs for wallpapers, web pages, icons and app interfaces; translate messages and menu items into your own language; promote KDE in your local community; and a ton more things.

You can also help us by donating. Any monetary contribution, however small, will help us cover operational costs, salaries, travel expenses for contributors and in general help KDE continue bringing Free Software to the world.

Kdenlive 24.08.1 is out and we urge all to upgrade. This version fixes recent playback and render regressions while fixing a wide range of bugs.

Full changelog:

• Fix reassigning timecode to project clip. Commit. Fixes bug #492697.
• Fix possible crash on undo/redo single selection move. Commit.
• Fix dragging transitions to a clip cut to create a mix. Commit.
• Fix multiple selection broken. Commit.
• Fix clip offset not appearing on selection in timeline. Commit.
• Ensure bin clips with effects disabled keep their effects disabled when added to a new sequence. Commit.
• Fix keyframe at last frame prevents resizing clip on high zoom. Commit.
• Fix effects/compositions list size. Commit. Fixes bug #492586.
• Fix compositions cannot be easily selected in timeline. Commit.
• Replace : and ? chars in guides names for rendering. Commit. See bug #492595.
• Don’t trigger timeline scroll when mouse exits timeline on a clip drag, it caused incorrect droppings and ghost clips. Commit. See bug #492720.
• Fix scolling timeline with rubberband or when dragging from file manager can move last selected clip in timeline. Commit. Fixes bug #492635.
• Fix adding marker from project notes always adds it at 00:00. Commit. Fixes bug #492697.
• Fix blurry widgets on high DPI displays. Commit.
• Fix keyframe param not correctly enabled on first keyframe click. Commit.
• Fix curveeditor crash on empty track. Commit.
• Ensure rendering with separate file for each audio track keeps the correct audio tag in the file name. Commit.
• Fix render project folder sometimes lost, add proper enums instead of unreadable ints. Commit. See bug #492476.
• Fix MLT lumas not correctly recognized by archive feature. Commit. Fixes bug #492435.
• Fix configure toolbars messing UI layout. Commit.
• Effects List: ensure deprecated category is always listed last. Commit.
• Fix tabulations in Titler (requires latest MLT git). Commit.
• Titler: ensure only plain text can be pasted, prepare support for tabulations (needs MLT patch). Commit.
• Don’t accept empty whisper device. Commit.
• Fix ffmpeg path for Whisper on Mac. Commit.
• Fix archive doesn’t save the video assets when run multiple times. Commit.
• Fix document notes timecode links may be broken after project reload. Commit. See bug #443597.
• Fix broken qml font on AppImage. Commit.
• Remove incorrect taskmanager unlock. Commit.

The post Kdenlive 24.08.1 released appeared first on Kdenlive.

This year’s Akademy was a special one for me in many ways.

First of all, instead of me travelling to Akademy it took place in my hometown of Würzburg, Germany. While I did have a hand in organizing it, most of the credit for it goes to Tobias and David. I had a lot of fun introducing people to my area and the concept of drinking wine on a bridge.

Qt Contributor Summit

Right before Akademy there was the Qt Contributor Summit, also in Würzburg (what a coincidence!). It was great to meet old and new Qt faces and talk about topics that are relevant to KDE, like the upcoming migration of KDE API documentation to qdoc.

Akademy Talks

This Akademy I gave two talks: One long one where I looked back at the Qt6/KF6 transition, what went well, what didn’t, and looked towards the future of what’s next for our software platform. Then I also had a lightning talk where I talked about the role of maintainers in open-source projects, why KDE doesn’t have traditional maintainers, and why that’s a good thing.

Besides that there were also a lot of interesting talks from other people, too many to mention right now. Speaking as a member of the program committee we had some tough decisions to make about what to include.

Goals

During the conference we announced the new set of Goals that were recently elected. I’m excited that my own proposal “Streamlined Application Development Experience” got selected and I’m looking forward to working on it with you. Besides that I also want to see how I can help out with the other elected goals: “We care about your input” and “KDE needs you 🫵”.

Akademy Awards

Another way this Akademy was special for me is that I was awarded with an Akademy award for my work on KDE Frameworks and Plasma. It feels great to get recognition for all the work I’ve been doing for the last seven years.

BOFs

During the week we had lots of smaller meetings and workshops (a.k.a BOFs, world’s most terrible acronym). I was leading two of them, one about my newly-elected goal where I was presenting my proposal in more detail, and one about the ongoing work of mine to migrate our API documentation to qdoc. Thanks to our sysadmin Ben we now have a website where the current (still very much WIP) state of the new API documentation page can be seen.

Other Things

What’s great about Akademy isn’t just talks and BOFs, it’s meeting people you only see online all year, talking to them in person, getting your code reviewed while staring on a screen together, chatting over random visions, complaining about things, laughing and enjoying things together, and wrapping up the day with a nice beer in your hand.

I’m already looking forward to next year’s Akademy, wherever that will be. Maybe it will be your place, organizing it is a lot less scary than you’d think ;).

Alright… this is published a bit later than usual due to travels and lack of energy. Anyway, let’s go for my web review for the week 2024-37.

Fediverse Discovery Providers

Tags: tech, fediverse, search

Nice to see such a project be funded. Let’s see how far this will go.

https://www.fediscovery.org/

2024: 0.5% of the Global Top 200 Websites Use Valid HTML

Tags: tech, html, quality

This is clearly not a great outcome. The browser monoculture probably doesn’t help.

https://meiert.com/en/blog/html-conformance-2024/

Family poisoned after using AI-generated mushroom identification book

Tags: tech, ai, machine-learning, gpt, law

This is bad. There was no way to know the book was AI generated and clearly it contained errors and lies.

https://www.reddit.com/r/LegalAdviceUK/comments/1etko9h/family_poisoned_after_using_aigenerated_mushroom/

Baiting the bot

Tags: tech, gpt, security

Looks like an interesting venue to attack systems which use LLMs.

https://conspirator0.substack.com/p/baiting-the-bot

Building a browser using Servo as a web engine!

Tags: tech, web, browser, servo

It’s good to see servo getting closer to being usable in a browser. Makes me dream of Falkon or Konqueror being resurrected with Servo as the engine.

https://servo.org/blog/2024/09/11/building-browser/

Windows NT vs. Unix: A design comparison

Tags: tech, windows, unix, design, system, architecture

Interesting exploration of the NT design compared to Unix. There was less legacy to carry around which explains some of the choices which could be made. In practice similarities abound.

https://blogsystem5.substack.com/p/windows-nt-vs-unix-design

The Insecurity of Debian

Tags: tech, debian, redhat, security

Interesting comparison of the difference in approaches between RedHat and Debian about default system hardening.

https://unix.foo/posts/insecurity-of-debian/

Linux’s Bedtime Routine

Tags: tech, linux, kernel, power

Ever wondered what happens when you suspend or hibernate on Linux? Here is a very deep exploration of the process from the kernel perspective.

https://tookmund.com/2024/09/hibernation-preparation

Operating system threads are always going to be (more) expensive

Tags: tech, multithreading, system, kernel

Good reminder of what OS threads entails and why they can’t be optimized much further. There’s so much you can do properly in userland.

https://utcc.utoronto.ca/~cks/space/blog/tech/OSThreadsAlwaysExpensive

QUIC is not Quick Enough over Fast Internet

Tags: tech, networking, performance, quic

Looks like there is still some work required on QUIC. There is a path forward though.

https://dl.acm.org/doi/10.1145⁄3589334.3645323

JSON diff and patch

Tags: tech, json, tools

Looks like a very nice tool to deal with JSON files.

https://github.com/josephburnett/jd

proctrace - a high level profiler for process lifecycle events · Tinkering

Tags: tech, linux, profiling, tools, processes

Looks like an interesting little profiling tool. The article explains quite well how it’s been done. Can be a nice blueprint to make other such tools.

https://tinkering.xyz/proctrace/

Docker images using uv’s python

Tags: tech, python, packaging

It feels more and more that uv might turn out to be a game changer for the Python ecosystem.

https://mkennedy.codes/posts/python-docker-images-using-uv-s-new-python-features/

uv under discussion on Mastodon

Tags: tech, python, foss, community, business

There is a sane conversation going on around uv in the Python community. Here is a good summary.

https://simonwillison.net/2024/Sep/8/uv-under-discussion-on-mastodon/

What’s new in C++26 (part 1)

Tags: tech, c++

Clearly nice examples of better quality of life adjustments coming with C++26.

https://mariusbancila.ro/blog/2024/09/06/whats-new-in-c26-part-1/

Replace strings by views when you can

Tags: tech, c++, performance, memory

Good reminder that packing your data is generally the right move when squeezing for performances.

https://lemire.me/blog/2024/09/09/replace-stdstring-by-stdstring_view-when-you-can/

Why I Prefer Exceptions to Error Values

Tags: tech, failure, exceptions

A couple of flaws in this article I think. For instance, the benchmark part looks fishy to me. Also it’s a bit opinionated and goes too far in advocating exceptions at the expense of error values. Still, I think it shows quite well that we can’t do without exceptions at all, even in the case of error values being available. In my opinion, we’re still learning how both can be cleverly used in code base.

https://cedardb.com/blog/exceptions_vs_errors/

Why some of us like “interdiff” code review systems (not GitHub) · GitHub

Tags: tech, version-control, git

A bit too much of a rant for my taste (even though I agree with the GitHub flaws). That said it illustrates nicely a use of git range-diff which is often overlooked.

https://gist.github.com/thoughtpolice/9c45287550a56b2047c6311fbadebed2

Scope Management 101 - by Kent Beck

Tags: tech, quality, agile, project-management, product-management

He is spot on again. The scope is what will allow to create flexibility in a fixed price project. This is what leads to the necessity to work incrementally.

https://tidyfirst.substack.com/p/scope-management-101

The Impossibility of Making an Elite Engineer

Tags: tech, engineering, career, learning

Interesting musing about what it takes for engineers to grow. Clearly there are a few paradoxes in there… that gives ideas to manage your career though.

https://tidyfirst.substack.com/p/the-impossibility-of-making-an-elite

Bye for now!

This week I attended the 2024 edition of KDE Akademy in Würzburg, Germany.

Akademy CC-BY-SA 4.0 by Andy Betts

Akademy is the people. Just a bit over 100km away from Würzburg I attended my very first Akademy in 2004. Twenty years later I still meet some of the same people, as well as some I had never met in person before. Some people I had met in several countries this year alone already, some I hadn’t seen again since before the pandemic. It’s a week of hanging out with friends.

I got back physically exhausted but refreshed with many ideas and a huge motivational boost, and I can’t wait to see what will come out of all the things discussed and started there.

A big thank you to everyone who helped to make Akademy happen, and to those of you who enabled people to attend with your donations!

Topics

I’ll try to list some of the topics I ended up involved in discussing, in talks, BoFs or elsewhere, but that’s bound to only scratch the surface. Also check out Planet KDE for more reports.

CI/CD and Craft

• If/how could we give tooling the ability to create MRs (e.g. for release automation)?
• How can we get CI coverage for Craft and Craft Blueprint changes? At least for the latter there are some ideas.
• Possible branching strategies for Craft Blueprints, to address the problem of all changes hitting the stable package builds immediately.
• Ways to work around or remove assumptions in our CI/CD infrastructure about the amount of parallel branches. Usually we have a development and a release branch, but there are cases of multiple still active release branches (e.g. Plasma LTS, or overlaps during the Gear release cycle).
• Removing the strong version locking between the Android CI image and the target Qt version.
• Using Qt’s upcoming SBOM tooling to generate package manifests, to automate collecting and maintaining information about 3rd party dependencies we ship in application packages (for FOSS license compliance).

See also the CI/CD BoF notes and Ben’s, Hannah’s, Julius’ and my talk.

KWallet successor

How to evolve our password and credential store was also a topic, following previous discussions at GPN22 and FrOSCon.

There generally seem to be two different types of data that need their own handling and consumer-facing APIs:

• Usernames and passwords, passkeys or 2FA secrets that you might want to sync between different devices.
• Device-bound secrets that are not shareable, like OAuth tokens or XDG portal secrets.

Building blocks for parts of this exist, but even when putting everything together there’s still gaps.

Migration from the status quo will also be challenging, as many different things need to happen in the right order, not all of which are under our control.

Localization

• Qt 6.6 added QQmlEngine::markCurrentFunctionAsTranslationBinding() which should allow us to make our i18n QML functions automatically reevaluate on language changes. That would be an enormous step forward for making runtime language changes work in QML applications, but it still requires a creative solution for dependency issues its use would cause in KF::I18n.
• Debugged various cases of our Android apps mixing up translations from different languages. All of that seems to trace back to a wrong fallback handling of non-US English-language locales (we should prefer en_US as a fallback in that case, but end up using secondary languages first instead). And newer Android versions seem to have a separated region from the language settings, making it easier to hit this issue.

Static builds

Being able to build our libraries and applications statically has been on the wishlist since a long time. Work has happened into that direction, but we haven’t gotten to the point to put all this together yet.

There’s now a stronger need for this though, with the first bits of iOS support landing in Craft, and Qt on iOS can only be linked statically.

Emergency alerts

Thursday morning the Plasma Mobile BoF coincided with the yearly test of Germany’s emergency alert systems. And while we didn’t manage to capture the cell broadcast with ModemManager, the push notification based system worked.

Public emergency alert notification.

I also got a data feed for New Zealand earthquake warnings and we discussed ways to make push notifications work on Linux mobile devices even in power save mode, something that will benefit not just the emergency alerts.

Android

• There’s a new Qt JNI array API coming, similar to something we already have in the KAndroidExtras code. More of that in Qt should help reducing the dependencies on the Android platform calendar integration, making it easier to move that to KF::CalendarCore.
• All pieces of the window insets color API have been merged, so the Android status and navigation bars now follow the Breeze style color for KDE apps.

Android status bar matching application colors.

• There’s agreement on retiring the KDE Frameworks 5 Android CI coverage, which would remove quite some maintenance burden. We don’t use this anywhere anymore, and external users of KF5 on Android are exceedingly unlikely as Qt5 will likely not produce APKs anymore which are in line with Google Play store guidelines.
• We discussed ideas for a cross-platform alarm/wakeup API, to be added to KIdleTime. That is, timers that also work while the application isn’t running, or even when the device is in sleep mode.

Kongress

Kongress generally worked, and given the incoming wishes for additional features it seems it was actually used.

We did learn though that rolling out updates to event specific content for the map needs to be possible fairly quickly, this tended to need manual CDN flushes too often.

I also got a chance to try the indoor localization solution from the team we met at 37C3 in the Akademy venue. It’s unfortunately not Free Software, but it’s nevertheless interesting to see what performance/precision can be achieved without special infrastructure in the building, with just the existing radio beacons, inertial sensors and a building map. Still a bit out of reach for us, but if the past is any indication we’ll eventually get there as well I guess.

See also my talk on OSM indoor venue maps in Kongress.

Itinerary

Conference travel of course also results in work around KDE Itinerary:

• Nobody got lost on the way to Akademy due to Itinerary issues it seems. That’s a big relief.
• As this was my first chance of field testing the new two-level timeline view, a bunch of fixes and improvements followed from that.
• Identified why opening the bus stop map showed the full city map instead in Würzburg (it’s the fault of the “Ringpark”…).
• Improved stop point/quay display for large bus stations on the map.
• Andy Betts designed new public transport icons, replacing the current incoherent mix of different styles.
• As one attendee got Frankfurt Hahn’ed we are now looking into having Itinerary warn about airports with SEO names.

See you next time!

Looking forward to the next opportunity to meet all of you again! At least for some I don’t have to wait very long, considering the Nextcloud Community Conference 2024 today and the Matrix conference next week in Berlin.

Technically Akademy isn’t part of Plasma, but most of KDE’s movers and shakers were here in Würzburg for Akademy 2024 this week, so the list of technical work merged was understandably light; we were all busy with conference things! I’ve already blogged about my Akademy experience separately; check it out here if you’re interested.

Despite the pressures of Akademy, quite a few things happened anyway, including Plasma’s release manager Jonathan Riddell releasing a beta version of Plasma 6.2 while at the conference. I’m very happy with Plasma 6.2. It feels great already to me. I had no hesitation pulling down git master and compiling everything while at the airport waiting for my return flight, and indeed everything was fine. But please do test the beta and report bugs!

In addition some code work also got merged; check it out below! Expect the pace of work to pick up next week and beyond as we start implementing all the cool stuff we talked about during the conference.

Notable UI Improvements

Immutable tool view tabs (as opposed to tabs for documents) now have a fancy new style! We’ll be opting into it over the course of Plasma 6.3 and other following gear and Frameworks releases, and replacing other tab-like-but-not-actually-a-tab UI elements with the real one (Carl Schwan, Plasma 6.3.0. Link):

Pressing the Meta+B shortcut to switch power profiles now cycles through them as you continue to press the key, rather than showing an overlay from which you would choose an exact profile (Jakob Petsovits, Plasma 6.2.0. Link)

System Settings’ Login Screen (SDDM) page no longer shows blurry preview images, and the dialogs that contain them have been updated to use the new modern dialog style (me: Nate Graham, Plasma 6.2.0. Link):

The alternative actions in the context menus of Plasma’s “Peek at Desktop” and “Minimize All” widgets are now expressed comprehensibly rather than being static and showing a checkbox, which made them look like persistent settings (Christoph Wolk, Plasma 6.2.0. Link)

Pressing Shift+delete to force-quit a process using SIGKILL in System Monitor now tells you that this is what will happen, rather than leaving it a secret (me: Nate Graham, Plasma 6.2.0. Link)

Throughout System System Settings’ grid views, all elided text labels now appear in a tooltip on hover, rather than only some of them (Han Young, Frameworks 6.7. Link)

Notable Bug Fixes

Fixed a high-priority Plasma crash that could happen when certain apps did certain weird things with their windows in a way that the Task Manager didn’t approve of. This also fixed a similar bug whereby certain apps might be missing from the Task Manager (Demetrius Belai, Plasma 6.2.0. Link 1 and link 2)

Fixed an issue that could cause certain added keyboard layouts to not appear in all of Plasma’s various lists of keyboard layouts you can switch between (Ismael Asensio, Plasma 6.2.0. Link)

Custom shortcuts with commands that result in their .desktop files having the same file name as an app’s own .desktop file are no longer capable of shadowing the app in software that fails to respect the NoDisplay=True key in apps’ .desktop files (David Edmundson, Plasma 6.2.0. Link)

In Plasma’s wallpaper chooser view, image previews no longer sometimes have single-pixel lines gaps around some of the edges when using certain fractional scale factors (Méven Car, Frameworks 6.6. Link)

Special KDE-specific keywords of apps and System Settings pages are now translatable into German (Alexander Lohnau, right now! Link)

Other bug information of note:

• 1 Very high priority Plasma bug (same as last week). Current list of bugs
• 32 15-minute Plasma bugs (same as last week). Current list of bugs
• 73 KDE bugs of all kinds fixed over the last week. Full list of bugs

Notable in Performance & Technical

Fixed a performance bottleneck in KWin that caused it to sometimes unnecessarily copy textures across GPU devices on multi-GPU systems. This fix also happens to make Plasma Mobile work on the Librem 5 phone (Xaver Hugl, Plasma 6.2.0. Link)

How You Can Help

Plasma 6.2 just branched for the beta release, so please test it! We have focused a lot on stability for this release and want to make sure we haven’t missed anything big before the final release in about a month. Your bug reports do not go into a black hole; we triage every one! So enthusiastic testing and bug reporting is encouraged.

Otherwise, visit https://community.kde.org/Get_Involved to discover additional ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite! Or consider donating instead! That helps too.

I attended KDE’s Akademy and the Qt Contributor Summit that happened this year. I also completed my personal goal of giving a talk at a conference! These conferences were back-to-back and were located in Würzburg, Germany during the 5th-8th of September.

Somewhere inside Würzburg. Travel #

I stopped in IAD before flying into FRA, and the journey was fortunately uneventful compared to last year. My IAD->FRA flight was delayed by an hour due to (another plane’s) mechanical issues and the ATC was backed up. When they announced that they were “sequencing” departures, I was surprised to find them actually putting all of the departing planes in a physical line on the runway.

On the IAD->FRA flight, they were having some troubles with the satellite connection and tried restarting the in-flight entertainment. While that probably did not please many of the people enjoying their movies and shows, it did reveal the in-flight entertainment system for United flights were running Android. Boo, that’s no surprise.

The trains I were on weren’t too late and I quickly arrived in Würzburg after a transfer to Frankfurt Central Station. To save some money, I purchased a Deutschland-Ticket which covered most local transportation, including the buses in Würzburg proper. The ticket was only 50€, which if I had paid for the trains separately would mean at least 65€! I didn’t bother calculating how much bus fares would’ve cost. So the D-Ticket was definitely worth it during my stay.

At one of the stations outside the airport. Yes, I did take the S-Bahn in the wrong direction…

On my returning overseas flight, the plane was half-empty. So I had a row with window seat all to myself, it was pretty sweet! Is this how flying first-class feels?

A full row to myself! Hotel #

I stayed in Hotel Amberger, close to the central station. It’s a cute little hotel, housed in a building that was clearly repurposed (my guess is some kind of hospital.) The hotel rooms are dead simple, but I didn’t really care. The first few days were really hot and the lack of a central air conditioning was really noticeable. Once the weather cooled off, the room was much more hospitable.

My hotel room.

The hotel room had a TV, but mine did not work. No German TV for me this time! There was multiple bus stops near the hotel, so it was very easy to get to the Akademy venue. The QtCS venue was within walkable distance, so I walked there each day.

Qt Contributor Summit #

This being my first Qt event, I didn’t really know what to expect. The venue is hosted in this expensive-looking conference center ( Congress Centrum Würzburg) near the river. There was catered food, which included lunch and coffee breaks. Dinner was served on the first day. I noticed the wait staff and looked young so I wonder if they were local culinary students.

The talks were a mixed bag of topics, but I still found value going there. Most of the non-Qt people there were either KDE or KDE adjacent, of course. One of the cooler things for me was meeting a bunch of Qt people in person. Of whom I only knew by name, mentioned in e-mails and Gerrit, so on. Lots of people recognized me by my work on qmlformat, so that was neat.

The talk that interested me the most was Vladimir Minenko discussing “QML Next”, plans to use languages other than C++ with QML. Some languages discussed were Swift, and C#. Curiously Rust was absent, which he did duly note. They did mentioned they were hiring a developer to work on Rust support later this year. The talk itself the concept was a bit vague, but that’s because they’re still in the exploratory stage.

If you’re interested in the other talks in this conference, there are notes and slides available from the Qt Wiki.

An unrelated picture of a tram, because I didn’t have any pictures of QtCS. Akademy #

Akademy was hosted in Julius-Maximilians-Universität Würzburg, which was much farther than the venue for QtCS. That necessitated travel by bus, but that was also covered by the D-Ticket. The talks were hosted in two identical-looking lecture halls. On a bus heading towards Akademy one day, I noticed one of the screens didn’t work. Of course, I had to take a picture…

The bus screen in some sort of debug mode.

My talk was about integrating C++, Qt, Rust (and KDE Frameworks.) For proper disclosure, this talk is on behalf of my company for spreading the word of our cxx-qt library which eases integration of all of these technologies. I think was a bit too rough structurally but lots of people seem to enjoy it. One of my goals was to raise awareness of the usage of Rust you can find in KDE today, and that seemed to be successful! I want to express my gratitude to my fellow colleague Leon Matthes for helping review my slides. Also thanks to Darshan Phaldesai for his KDE work featured in the presentation.

A picture of me hastily giving my presentation.

The results of my talk I think were really cool! Within the KDE community, there seems to be some interest in picking up Rust. Lots of KDE developers were in varying stages of Rust interest. No one told me how stupid it was to glue the two together, so the general vibe I think is “it’s pretty neat, let’s see how well this works.” Unfortunately due to technical issues my talk was not recorded properly. A colleague recorded my talk on his phone, and will hand that over to the Akademy organizers soon. So please be patient, but the slides are available online while you wait.

Oh yeah, and the KDE goal I’m championing “We care about your Input” was selected! I’m pretty excited to keep hacking away on graphics tablets in KDE Plasma. Thanks to NLnet for sponsoring us to work on that, along with Wayland accessibility improvements.

One of my favorite talks was Xaver Hugl’s “What even is color?”. The work he’s doing in KWin is excellent, and I think he did a really great breakdown to understand what color management is.

Day Trip #

In the day trip we went to Rothenburg. It was rainy, cold and miserable most of the day but we still had fun. One of my favorite parts was climbing up the tower to get an excellent view of the town.

A picture of the tower. A view from the top of the tower.

That’s all I have to say about Akademy + QtCS, I had lots of fun this year! I’m happy that I was able to attend the talks this year, and meet a lot of people I missed last year. I hope everyone else were able to return home, and I’m excited to see what event I’ll attend next. See you!

Akademy is this yearly thing where bunch of KDE people go to talk about and work on KDE software. I had never been in one before, but this year I managed to make it there! This year Akademy was held at the city of Würzburg. This was also my first time in Germany, which is the furthest I've ever been from home.

I also had my wife Jenny with me, since if I had gone alone I would have gotten lost in some random mountain somewhere, or started a new life at the dark corners of Frankfurt airport, completely confused.

Friday, the day of flying (or so I thought)

On Friday the 6th, we left from Oulu to Helsinki first. Hop on plane at 14.30 and- Oh, a small delay.

Eh, it's fine, we hopped on the plane at 16.00 and-...

The flight was canceled.

So, we wait til like 19.30 or something to get to Helsinki. But of course, our flight from Helsinki to Germany had already left! No worries though, the next flight to Germany would leave soon.

Wait, what do you mean it leaves at 7.00?

Aaaaaaaaaahhhhggggggggggg....

Well, we got paid airport hotel room with paid dinner and breakfast. So we slept at Helsinki the first night. We were supposed to be at Würzburg at 23.55 or something, but of course not. Oh well, with some effort I might be able to make to the event, although I would miss the first few talks.

I had the most saddest (but still good) slab of lasagne at very sad and empty airport hotel restaurant. Very frustrated by everything. Sure it'll get better, right?

Saturday, the day of sleep deprivation

This time the airplane actually started to fly, instead of getting canceled for scandalous airplane activities, and we were on route to Frankfurt pretty soon. I spent some time in the airplane just working on my never-ending game project.

At Frankfurt, we got our luggage and went to the funny ICE train, which was a bit late. Apparently being late is some German train thing, I don't really understand it, but we have similar thing at Finland so it wasn't that shocking.

At the train, we were exhausted with our 4h of sleep due to stress not allowing us to sleep, so we just find some seats and sit down. Five minutes later some chap tells us to go away, so we stay up standing for the next 1h 30min next to the exit doors in some midcabin thing.

I wanted to watch some of the Akademy streams at this point, but I was mostly focusing on staying up.

Eventually, we finally reach the Burg of Würz. First impressions were that it looks really nice and.. What the hell is that? A.. mountain? Wow, they can be THAT tall??? (Authors note: Finland is very, VERY flat).

Also it was hellishly hot. The most I saw was 32 celsius. It was painful, I was sweating all the time and it was not fun.

We walk to our hotel room at Mercure hotel, which was really nice by the way. At this time, Akademy was having an incredible luncheon together, so me and Jenny decided to find something to eat. We found this place that was all about avocados, and I had something called powerbowl, which was brilliant.

After that, we began to study the incredibly complex thing that is the German bus system and started our trip towards the Akademy venue.

Aktually at Akademy

Me and my blurry sleep deprived brain walk to the venue and first off I meet familiar people. A lot of familiar people. Many hugs and "Oh you finally made it!"-s were shared. Jenny was with me there as well and it was fun to introduce her to my friends.

I honestly don't remember much about the day. It was quite a blur. But it was cool and I talked a lot.

I stole a lot of stickers and listened some talks, which I can barely remember... But I do remember which ones:

• Arjen's talk about Union KDE styling theme thing, that is super cool.
• Harald talked about of our own new possible shiny OS called KDE OS. Or 🍌 OS. I found this really exciting.
• A lot of lighting talks, where Nicole's talk about teaching lil kiddos how to install Linux with KDE software on old PC's to bring them back alive.
  • I think this talk was my favorite. It was very wholesome, motivating and I'd like to have similar kind of teaching event at home. No promises, but.. Maybe!

During this day I also began to give out salmiakki to people, since I had been well prepared. It was kinda fun to see peoples reactions, especially if they had never heard of it before.

Then it was back to sleep at the hotel.

Sunday, I managed to do things

On sunday I was at Akademy pretty much the whole day. Again, I listened bunch of talks, met more people and we had many good chats about LTS distros, KDE PIM, Kwin, Flatpak... And many other things I can't remember.

I listened Carl's KDE Apps Initiative talk which was very motivating for me, since I've wanted to make a KDE app for a while. A gaming related lil thing.

After the fun group photo and delicious lunch, I chatted more and wandered about the venue.

There was a talk about daily driving Plasma Mobile and I found it very cool, and we had a chat about the Plasma Mobile afterwards. Apparently my Fairphone 5 could run PostmarketOS with Plasma Mobile pretty well already, but I am not yet ready to commit to such a change with my mobile device.

Last I listened Xaver's talk about what color is in computers. I learned that sRGB is a lie and gasped audibly, then heard a lot of words related to color systems I didn't really always understand.. But I found the talk still quite interesting and informative.

The evening was then again a bit of a blur, with sponsors lightning talks and Akademy Awards (congrats to winners btw).

Very interesting day, but I've always been bad when it comes to learning from listening. I learn by doing.

Of course the day wasn't complete without me going to wait bus with my t-shirt and shorts (since it was hot again), and it started pouring like heck. I was soaked when I got to the bus, then at the last stop I had to walk 1km to the hotel in the rain. Ah well, it was warm so I didn't mind too much.

Monday, I skipped the class

On monday I was so exhausted by Everything:tm: I decided to just chill with my wife and we went around Würzburg, buying food and chocolate.

I spent that day just recharging my social batteries. And I ate some Flammenkuchen, which was delicious!

At some point when Jenny is done editing and uploading her video, I will make separate post for it. Then you can see what Würzburg is like, and hear what she did during the trip.

Tuesday, I flocked together with the birds

Like on monday, on tuesday as well Akademy had these events called "BoFs" which is abbreviation of Birds of a Feather. Because "Birds of a Feather Flock Together". I don't know why it's called that, but anyhow, I participated a few of them:

• New design system bof
  • Very interesting discussions and ideas even I know nothing about design
  • I was mostly hoping to help people there with my programmer side of knowhow, as someone who has touched the Breeze styles codebases
• Tiling in kwin bof
  • We mulled over what we could do to make tiling in kwin even better
  • I have this mini task for myself where I try to make tiles split automatically when a window is dragged on top of the other
• Fedora KDE bof
  • I was just mostly curious whats up with Fedora KDE at the moment
  • I also wanted to give my praise for Fedora KDE, it's been my daily driver for many months now and it's been really good
  • Couple of my friends use it too due to my recommendation and they're having good time gaming on it! :)

To wrap up the evening, I had a fancy dinner with my friends. What was quite a culture shock to me was that after 22.00 the streets were practically completely empty. It was eerily quiet. At home we would have had few drunks about making noise, but at Germany there was just.. Silence.

Wednesday, to home again

Due to having two lizards and them needing a petsitter, and said petsitter not being able to be there the whole week, we left a bit early so we missed the daytrip and the last bof day.

Bit early being our flight from Frankfurt was leaving around 7.00. So we woke up at 5.00.

And when I wake up I saw a message in my phone saying: "Hi your flight is canceled"

Ah. Fun. If all had gone to plan, we would've been at home around 17.00. But instead, we were home at ~2.00.

We had to live at Frankfurt airport for ~7 hours, saw a lot of police with weapons (it was really scary to me, I've never seen weaponry like.. that openly), there was some suspicious luggage that got a whole McDonalds covered in "dont go here" tape and more police.

Urghgfhklfg. Scary.

Eventually we luckily made it to Helsinki and then back to Oulu and I didn't need to type out this blogpost from some corner of the airport.

Conclusions

Akademy was really fun event. I can hardly describe how fun it was. It's been quite a blur due to traveling issues and thus me being completely stressed and exhausted, but I still had many fun chats with everyone.

It was really nice to finally see who the people behind the internet names are and have talks with them, be it just random topics or KDE topics. I met people who I had never met before and shared many chats, laughs and information with them.

I learned quite a lot about what's going on in our KDE ecosystem and even outside of it, how we all interact. But I think the biggest thing I learned was that events like Akademy are crucial for the motivation and wellbeing of the KDE community. It helps us stay together, keep our bonds strong, be it KDE folk itself or people working with us, and keep us being awesome at what we do: Making computers do cool things, for free, for productivity and for fun.

Sorry about no photos, I have basically nothing: I am very bad at taking photos because I simply don't remember.

I love KDE and if you love KDE too, and if it's at all possible, visiting Akademy is well worth it!

See you at the next one, and apologies for the all-over-the-place-rambly-travel-post. Hope you find it a good read anyway.

Thanks for reading!

This year I went to Würzburg, which is a nice small German city famous for its wine. But I didn’t only go there for the wine, but also to attend Qt Contributor Summit and Akademy.

Qt Contributor Summit

The travel to Würzburg didn’t go as planned as Deutsch Bahn had some technical issues with their train and couldn’t reboot our train. We still managed to get in Würzburg on time and even had the change to get a small touristic tour from some locals.

Würzburg Residence and the Wine briget

The event itself was great and was the first time I attended fully a Qt Contributor Summit. Last year, I only attended a few session since the event was 20 min away from home.

There was many breakout rooms focused on some spcial topics, for me the most interesting sessions were about Qt for Python, how to hate QML, qt-project.org, Vector Graphics in Qt.

It was great to see how the KDE community still plays a big role in Qt and the Qt developers really appreciated what KDE finally moved to Qt6. They reported that the flow of contributors and bug reports increased.

Qt Chief Maintainer Volker Hilsheimer even stressed out how important it was for some of their customers to see KDE ported to Qt6, as it shows what Qt6 is stable and mature enough. Qt6 is indeed a hugo improvement over Qt5 and I am very happy how good the transition was.

Qt Contributor Summit

I think it was a great idea to have Qt Contributor Summit just before Akademy. This allowed to have many KDE Contributor to the Qt Contributor Summit and many Qt developers to Akademy. It would be great next year to do the same next if possible and encourage more people from the Open Source Qt ecosystem to join too.

Akademy

Once the Qt Contributor Summit ended, we started a few hours later with the Akademy welcome event for some KDE beers. But before that, I had some bubble tea and spent some time with some friends exploring the city.

The weekend was full with a lot of great presentations. I presented a small report about the Accessibility Goal and the Fundraising working group. I also gave a bigger talk about the KDE Application Ecosystem, which I am really passionate about. The whole slides ware made with Calligra.

I was also very happy to see the new elected goals.

Sunday was also my birthday, thanks to everyone for congratulating me. I also received a super fancy special birthday sticker and some amazing cake.

Cake and stickers

Day Trip

We had our yearly day trip too, this time at Rothenburg ob der Tauber. A charming small town in south Germany.

Day trip Rothenburg ob der Tauber

BoFs

The next few days were filled with BoFs and many informal discussions. During the Promo BoF, we decided to create a “This Week in KDE Apps” blog posts. Paul volunteered Tobias, Joshua, and me as the initial team for this.

I also hosted a BoF about a future replacement of KWallet. There were some discussions about the scope of this effort. Should we just focus on storing OAuth2 tokens as a background service what the normal users should never interact with or do a full-blow password manager like macOS Keychain. I presented my work toward the latter around based on KeePassXC and the KeePass format (see my old blogpost) as it would allow to use a standardized file format that also work on other platforms. The KeePassXC developers are working on providing a reusable library, so we don’t need to fork their code. There will likely be more discussion about this in a separate gitlab issue. The lack of a good story around passwords is not unique to KDE but to the whole Linux ecosystem. If you have some opinions about this, feel free to reach out.

I discussed with Ben, Lydia and Aniqua the infrastructure for newsletters for our supporting members. Ben managed to get an instance of Listmonk in a matter of minutes and this seems to be the right way for us to manage a newsletters or at least way better than using a mailing list for this.

Kieryn hosted the best BoF: the Sticker BoF where we shared stickers and had a competition to see who had the best decorated laptop. I won!!! and received another special sticker. Thanks Kieryn for organizing this BoF and generally making Akademy this year such an awesome event!

Stickers

I also ended up finishing a lot of work. I finally ported the last Drupal 7 website to Hugo: dot.kde.org which was a quite massive website with more than 20 years of history. I migrated the Hugo version used by KDE from 0.110.0 (which was more than a year old) to 0.134.0 and I am happy to report that the Hugo folks care a lot about stability and there was only some very small breaking changes. If you are working on some KDE websites, don’t forget to download the latest version of Hugo and to run the following command to update the KDE Hugo theme.

hugo mod get invent.kde.org/websites/hugo-kde@master

With Volker, we finally merged the status bar integration for Android apps so that KDE apps running on Android and now use breeze colors in their status bar, which looks much more integrated and like on Plasma Mobile.

Itinerary on Android with the new statubar

I also got some improvements ideas during Akademy, and I already started implementing some of them: https://invent.kde.org/pim/itinerary/-/merge_requests/324

Finally I started rewritting the Calligra launcher to Kirigami based on the old Gemini UI. Still a bit far away from a being in a mergable state but it already looks quite good.

Calligra text document templates selection

Calligra new document

Conclusion

This was a great Akademy again. Thanks a lot for all the organizers for all their work. I hope to see some KDE contributors again soon at the Nextcloud Conference and Matrix Summit both in Berlin this month. And to the Linux Days in Dornbirn.

Calamares is a Linux system installer used by dozens of distro’s to get the bits from an ISO image onto a target computer. Development is nowadays purely on a volunteer basis, which makes it hard to keep up with all the changes in the Linux world. But steps are made, and code submissions are very welcome, and here’s a note on something relatively new and useful: Wayland keyboard layouts.

Some History

In an X11-based system, the X server is the one thing that knows how to interpret keystrokes (pressing the button on a bit of hardware, e.g. the button to the right of the one labeled CapsLock is labeled A and makes the letter “a” when pressed). The X server can be told how to interpret the buttons: one command is setxkbmap which can manipulate the keymap:

$ setxkbmap -query rules: evdev model: pc105 layout: us options: ctrl:swapcaps

Using setxkbmap you can change the layout from the command-line: setxkbmap -layout us changes it to US-English, setxkbmap -layout ua changes it to Ukranian, and there’s tons of other layouts.

In Ukranian, pressing the keys labeled WASD yields “ЦФІВ”.

Changing the keyboard layout is just a matter of being connected to the X server – any X11 terminal program can do it, or an application can do it programmatically by sending the right X11 protocol messages.

Wayland

There isn’t a standardized mechanism in Wayland to request a different keyboard layout. It’s up to the compositor how and what it wants to do.

Some compositors are willing to listen to systemd’s locale1 service. KWin does this, but only when started with suitable command-line flags. Many systems that start KWin as part of their live installation do not pass that flag. Some compositors just don’t implement this at all.

KWin (Wayland)

The way to tell KWin to change the keyboard layout is to rewrite the configuration file for keyboard layouts in KDE Plasma, then send a DBus signal to KWin.

You can see that happening here, at least as of the code in April 2024. I suppose the idea is that the only way to change the keyboard layout is to go through the KCM, click on the list of layouts, manipulate it, etc. and then click apply.

For those cases when I briefly want to type Ukranian, or Arabic, that’s really annoying. For Calamares, which tries to set the keyboard layout when you select one, that’s really annoying.

Calamares and KWin

In the upcoming Calamares 3.3.10 release, the installer can be configured to edit KDE Plasma’s keyboard configuration file. I imitated the code from the KCM, but without relying on KConfig because that would be yet-another dependency for Calamares. This is a total bodge job. But it works!

For distro’s that use Calamares, and use KDE Plasma, and come up with a live system that uses Wayland (e.g. Asahi Linux) this means that keyboard layout updates can now be applied consistently, and you can e.g. type your password in the keyboard layout you’re actually going to use.

It ain’t pretty. Frankly, I think there should be a standardized way to say “use these keyboard layouts”, but I also understand that that opens the whole can of worms of “who should be allowed to change the keyboard layout?”.

If you're using Plasma/KWin 6 i suggest you disable the Morphing Popups effect, it has been removed for Plasma 6.2 https://invent.kde.org/plasma/kwin/-/commit/d6360cc4ce4e0d85862a4bb077b8b3dc55cd74a7 and on X11 at least it causes severe redraw issues with tooltips in Okular (and i would guess elsewhere).