Planet KDE

The core Plasma team has entered full-on bug-fixing mode until Plasma 6.2.1, and what a week of bug-fixes it was! We’re nailing regressions reported in the beta release as they appear, as well as older bugs we didn’t manage to get to yet. I’m incredibly impressed with the team and their tremendous work this week!

In addition, a few features and UI changes postponed from Plasma 6.2 have started to land in 6.3.

Notable New Features

Plasma’s Widget Explorer sidebar now gives you the opportunity to remove all instances of a widget, which can help when you have a stuck widget hidden somewhere (Niccolò Venerandi, Plasma 6.3.0. Link):

Notable UI Improvements

With multiple screens showing wallpaper slideshows, the transition times for each screen’s slideshow are now synced so they happen at the same moment (Sebastian Meyer, Plasma 6.3.0. Link)

Loosened the criteria for mouse button re-binding, so for example you can now swap the “Back” and “Middle Click” buttons (Paul Dann, Plasma 6.3.0. Link)

The Emoji Selector window now remembers its window position (on X11) and size (me: Nate Graham, Plasma 6.3.0. Link)

For notifications that you can pause, the “Pause” button now becomes a “Resume” button after you press it, instead of being checkable (me: Nate Graham, Plasma 6.3.0. Link)

In Plasma’s Networks widget, networks you’re not connected to no longer have Configure buttons, because clicking on them didn’t actually do anything useful anyway (me: Nate Graham, Plasma 6.3.0. Link)

The checkboxes on System Settings’ Bluetooth page have been replaced with switches, because they’re for instant-apply settings (Christoph Wolk, Plasma 6.3.0. Link)

Notable Bug Fixes

Fixed a bug that could cause System Settings to crash when leaving its Wallpaper page (Méven Car, Plasma 6.2.0. Link)

Fixed a bug that could cause Plasma to crash under certain circumstances when applying certain global themes (Nicolas Fella, Plasma 6.2.0. Link)

Fixed a case where plasma-browser-integration-host (the process that communicates with web browsers that have Plasma Browser Integration installed) could crash when windows were closed (Méven Car, Plasma 6.2.0. Link)

Closing a Plasma widget while a tooltip for one of its UI elements is open no longer causes the tooltip to remain visible and awkwardly jump to the panel itself; now the tooltip also disappears as you would expect. This also fixes a related crash (Niccolò Venerandi, Plasma 6.2.0. Link 1 and link 2)

Fixed a bug that could cause the logout process to get stuck on a black screen on X11 (David Edmundson, Plasma 6.2.0. Link)

Moving a window to another virtual desktop using a method that does not switch to that desktop no longer leaves no window focused on the current desktop (David Edmundson, Plasma 6.2.0. Link)

Fixed a bug that caused real-fake-session-restore to not work properly on Wayland (David Edmundson, Plasma 6.2.0. Link)

The footer on Discover’s updates page no longer sometimes gets visually broken (Harald Sitter, Plasma 6.2.0. Link)

When configuring Plasma’s Digital Clock widget to show seconds and using 24-hour time, the time display no longer gets cut off on narrow vertical panels (Akseli Lahtinen, Plasma 6.2.0. Link)

Fixed an issue that could cause Plasma’s edit mode to misbehave in strange ways when there are widgets on the desktop and auto-hide panels (Marco Martin, Plasma 6.2.0. Link)

Plasma’s “Minimize All Windows” widget no longer sometimes fails to restore them on Wayland; now this always works (Christoph Wolk, Plasma 6.2.0. Link)

System Settings once again remembers its window size, position (on X11), and maximization state as expected (Akseli Lahtinen, Plasma 6.2.0. Link)

On X11, you can now open the color scheme editor on System Settings’ Colors page more than once (Albert Astals Cid, Plasma 6.2.0. Link)

Fixed the “two clicks to rename” feature on the Plasma desktop when using systemwide double-click mode so that it works properly (Christoph Wolk, Plasma 6.2.0. Link)

Fixed a bug that caused it to be impossible to change power profiles in the Plasma widget under certain circumstances. There may be other such bugs too BTW; this only fixed one of them (Jakob Petsovits, Plasma 6.2.0. Link)

KWin’s global “Move Mouse to Focus” shortcut now does something more sensible on Wayland by moving the pointer to the focused window instead of the top-left corner of the screen (Xaver Hugl, Plasma 6.2.0. Link)

The Audio Volume widget can once again display its complex view (rather than a dumb giant icon) when placed in an extremely thick panel (Christoph Wolk, Plasma 6.2.0. Link)

Made it possible to translate four labels on System Settings’ Touchpad page which were previously untranslatable and hence always shown in English (Victor Ryzhykh, Plasma 6.2.0. Link)

Plasma’s feature to sync your keyboard’s LED color with the system’s accent color (where supported) can now be permanently disabled if you don’t use it or like it (Natalie Clarius, Plasma 6.2.0. Link)

When using an auto-hide Plasma panel, it can no longer be accidentally opened invisibly while in KWin’s Overview effect, which would also cause it to briefly get stuck open after leaving Overview (Xaver Hugl, Plasma 6.2.0. Link)

Plasma’s Power and Battery widget no longer sometimes mis-labels batteries on systems with removable batteries or multiple batteries (Oliver Beard, Plasma 6.2.0. Link)

Fixed a bug that caused some Plasma widgets’ pop-ups to not have their top corners rounded as intended (Niccolò Venerandi, Plasma 6.2.0. Link)

Throughout QtQuick-based KDE software, pressing a keyboard’s “Show Menu” key now opens the menu under the focused item if there is one, rather than always opening it under the cursor (Evgeny Chesnokov, Frameworks 6.7. Link)

Throughout KDE software, the “Upload to Imgur” sharing plugin now only lets you try to upload file types that Imgur actually supports (Nicolas Fella, Frameworks 6.7. Link)

The informational tooltips seen all over the place in System Settings that you can access by clicking on a little button with the info symbol on it no longer flickers between visible and invisible if it opens right under the cursor (Ismael Asensio, Frameworks 6.7. Link)

Global shortcuts for activating Kickoff no longer break if you restart Plasma with plasmashell --replace (David Edmundson, Frameworks 6.7. Link). Also, friendly reminder that if you’re using Plasma’s systemd startup integration — which you probably are since it’s on by default for distros that ship systemd — the correct way to restart Plasma is systemctl restart --user plasma-plasmashell.service.

Other bug information of note:

• 1 Very high priority Plasma bug (same as last week). Current list of bugs
• 36 15-minute Plasma bugs (up from 33 last week). Current list of bugs
• 181 (!) KDE bugs of all kinds fixed over the last week. Full list of bugs

Notable in Performance & Technical

In Discover, moved the processing of app ratings to another thread so it can’t block the UI thread and make the app feel slow and laggy when the network is slow (Aleix Pol Gonzalez, Plasma 6.2.0. Link)

Launching an app that lacks a .desktop file (e.g. an app packaged as an AppImage) no longer causes a brief screen freeze whose length is proportional to the size of the app’s executable (Vlad Zahorodnii, Plasma 6.2.0. Link)

Optimized how KDE software in general finds mountpoints, which can result in a significant speed-up for various apps’ file-based use cases — up to 80% for one of them! (Kai Uwe Broulik, Frameworks 6.7. Link)

How You Can Help

Please test the Plasma 6.2 beta release! We’ve 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. I’ve noticed fewer bug reports for this beta than previous ones, and I don’t believe for an instant that it’s because the release is already perfect! Go out there and file those bug reports!

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.

This blog post provides the heads-up about planned tablet input changes that are brewing for Plasma 6.3. KWin provides support for the tablet input protocol, but things are different on the client side. Some apps support it, some do not. If an application supports the tablet input protocol, great, it will receive tablet input events as is. On the other hand, if the application does not support the tablet input protocol, then KWin will fake tablet input as pointer input. In Plasma 6.3, KWin will stop doing that and I think that we should briefly talk what led us to such a decision and what impact it will have.

Originally, when the tablet input protocol support had landed in KWin, there were still pretty few applications and toolkits that supported it. Emulating tablet input was a fairly reasonable decision, otherwise you would have likely not been able to use tablet in the Plasma Wayland session at all. As time went by, more and more clients gained native support for the tablet protocol. Unfortunately, in meanwhile, we had also started noticing various issues with tablet emulation.

So, what’s the reasonable thing to do about it? Fix the bugs of course. And we did. But there is still a set of issues that cannot be addressed without bringing more complexity in already too complex code that we are struggling to keep afloat. Enough is enough.

Q: What’s new in 6.3?

A: Starting since 6.3, tablet input emulation will be deprecated and disabled by default. Note that you can enable it back by setting the KWIN_WAYLAND_EMULATE_TABLET=1 environment variable.

Q: When will tablet input emulation be dropped?

A: There is no concrete milestone at the moment.

Q: What does it mean to you? (as a user)

A: Hopefully, nothing. The major toolkits such as GTK, Qt, and SDL already provide support for the tablet protocol, so does Xwayland. So, you should be able to use tablet without any issues in X11 applications or Wayland native applications that use the aforementioned toolkits. Chromium/Electron still does not provide native support for tablet input on Wayland, but it’s also worth noting that most of those applications run through Xwayland by default unless the user sets some command-line arguments.

If your favorite application does not work with tablets, please tell it to the developers of that application so they know that there’s demand for such an operation mode.

Q: What should I do? (as a toolkit developer)

A: Please add support for tablets! If your toolkit already supports the tablet input protocol, wonderful, no work to do. \o/

Q: Is KWin alone by stopping emulating tablet input?

A: No, it is not. Mutter (the Wayland compositor in GNOME Shell) doesn’t emulate tablet input either.

Closing words

Deprecating tablet emulation is disappointing but the options that we have are not great either. It’s either bring in more complexity in order to fix the existing issues (plus even more code to ensure that the pointer focus is managed correctly when using both pointer and tablet) into an already too complex codebase or just do nothing special about applications that don’t opt in into tablet input. Hopefully, the remaining applications and toolkits that still miss tablet support add it in the near future. If you have more thoughts about it, please reach out to us at our matrix room.

Qt Gradle Plugin 1.0 (QtGP) build tool has been released. You can include it in your Android builds from Maven Central.

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

Is Tor still safe to use?

Tags: tech, tor, privacy

The quick answer is yes. The longer answer is that more effort is still required to ensure the network has enough diversity of nodes to stay healthy.

https://blog.torproject.org/tor-is-still-safe/

The Subprime AI Crisis

Tags: tech, ai, machine-learning, gpt, business, economics, criticism

This is a very harsh and bleak view on the current generative AI craze. Clearly it survives on some sort of weird faith that things will magically improve. Some decision makers clearly run fully on said faith and lost all kind of realistic view of the situation. They are just very disconnected from the user’s needs.

There’s even a funny quote in there: “Generative AI must seem kind of magical when your entire life is either being in a meeting or reading an email”.

When this bubble bursts, it’s hard to predict what the fallout will be on the tech industry… for sure it won’t be pretty. It also begs the question: what is this industry going to do next? There’s clearly no plan after generative AI.

https://www.wheresyoured.at/subprimeai/

Elon Musk’s xAI supercomputer stirs turmoil over smog in Memphis

Tags: tech, ai, machine-learning, gpt, politics, ecology

Need to illustrate how much the current AI arm race is an ecological and social problem? Here is a very pathological case. This is what you get when you let the tycoons behind this completely unchecked.

https://www.npr.org/2024/09/11/nx-s1-5088134/elon-musk-ai-xai-supercomputer-memphis-pollution

Larry Ellison’s AI-Powered Surveillance Dystopia Is Already Here

Tags: tech, oracle, surveillance

People are gasping in horror with Larry Ellison’s latest claims… but really they should realize he’s not dreaming big. All of that is already here in one form or another. Maybe it was time to protest years ago?

https://www.404media.co/larry-ellisons-ai-powered-surveillance-dystopia-is-already-here/

Turning Everyday Gadgets into Bombs is a Bad Idea

Tags: tech, security, war, battery

Or why we should all be concerned and condemn the latest pager and walkie-talkie attacks. They clearly opened a Pandora’s box, it’d be surprising not to see more of those from various organizations. The funds and efforts required make it affordable enough.

https://www.bunniestudios.com/blog/2024/turning-everyday-gadgets-into-bombs-is-a-bad-idea/

Oracle, it’s time to free JavaScript™

Tags: tech, javascript, trademark, law, oracle

This is a good initiative. It makes no sense for Oracle to still cling onto JavaScript has a trademark.

https://javascript.tm/

Safe C++

Tags: tech, c++

Interesting proposal for a superset of C++ bringing a safe subset. Could it be a way to improve C++ use for the coming decade?

https://safecpp.org/

Threads, asynchronous IO, and cancellation

Tags: tech, asynchronous, multithreading, io

Or why going through an event loop might be more work initially but will make some things easier longer term. Nice way to frame how threads are bringing some opaque state.

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

Real-time Linux is officially part of the kernel after decades of debate

Tags: tech, linux, kernel, realtime

Definitely good news if you have to maintain a real-time Linux system for industrial use. No more patches to carry over.

https://arstechnica.com/gadgets/2024/09/real-time-linux-is-officially-part-of-the-kernel-after-decades-of-debate/

Writing an OS in Rust

Tags: tech, kernel, rust

An interesting endeavor to create you own OS using another language than one of the usual ones.

https://os.phil-opp.com/

Backup strategies for SQLite in production

Tags: tech, databases, sqlite, backup

Wish to use SQLite in production? You better have a good backup strategy. This article explains the main available options.

https://oldmoe.blog/2024/04/30/backup-strategies-for-sqlite-in-production/

6 Techniques I Use to Create a Great User Experience for Shell Scripts

Tags: tech, shell, scripting

Shell scripts deserve to be well designed like this indeed.

https://nochlin.com/blog/6-techniques-i-use-to-create-a-great-user-experience-for-shell-scripts

DirectX Adopting SPIR-V as the Interchange Format of the Future

Tags: tech, shader, vulkan, directx

This is good news. DirectX being the other big graphics API if it adopts SPIR-V as interchange format it’ll open the way to more shader reuses.

https://devblogs.microsoft.com/directx/directx-adopting-spir-v/

PixiJS | The HTML5 Creation Engine

Tags: tech, web, frontend, webgpu, 2d, graphics

Looks like an interesting tool to have in the box for 2D effects on the web.

https://pixijs.com/

Good forms

Tags: tech, gui, html, web, frontend, complexity

A good list to design HTML forms. The bar is indeed high and there’s value in simplicity.

https://daverupert.com/2024/09/good-forms/

The Undeniable Utility Of CSS :has

Tags: tech, web, frontend, css

This is indeed an interesting new CSS selector. Opens the door to doing more in a declarative way and with less Javascript.

https://www.joshwcomeau.com/css/has/

Goodhart’s Law in Software Engineering

Tags: tech, management, metrics

We should definitely be more wary of metrics indeed. They help for a while, but at some point you’ll necessarily get unfortunately burnt by them. The only fallback is “good judgement”… do what you can with this.

https://buttondown.com/hillelwayne/archive/goodharts-law-in-software-engineering/

Building Aggressively Helpful Teams

Tags: tech, team, management

Nice tricks to help the team jell. I should try this more.

https://brittonbroderick.com/2024/08/18/building-aggressively-helpful-teams/

Bye for now!

This year Akademy was in Würzburg (shock! horror!). I think its not too far fetched to say that we pulled it successfully.

How it came to be

During last years Akademy in Thessaloniki the idea came up given the high density of KDE people in the area to hold Akademy in Würzburg. On top we had the perfect venue in mind: two lecture halls for talks, BoF rooms and a ample common area for people to hack and socialize. I had such thoughts in the back of my mind for a while but did not share or go through with them.

However what Akademy does is it makes you talk to people and Tobias convinced it me that we should do it and more people even agreed that Akademy in Würzburg would be a good idea! (Of course some of these encouragers this does not mean work organizing Akademy like it would mean for us…) So on the second-to-last day of Akademy I sat down and wrote an email to my former university professor to enquire about the possibility of doing Akademy in the building that we envisioned.

And just like that, after some informal talks during Akademy and a meeting at the University and sending in a proposal after the Call for Hosts later you end up having weekly meetings to talk about and plan the next installment of Akademy.

How it did go

There were some problems but I think all in all this year Akademy went very well. I heard so much praise and positive feedback it felt a bit surreal at first (as did Sunday evening when all the talks were done). The most stressful situation for me happened on Sunday afternoon when I retrieved my charging phone from the team room to discover that the social event could not go ahead as planned and trying to manage that with the rest of the team. I think the resulting evening was very nice and chill and you could feel my relieve. I heard there was even an afterparty afterwards at the bar where we had held the welcome event.

Of course during the event there are always minor issues that need dealing with and looking out for those, dealing with them and trying to make sure everything is running smoothly (and the stress coming these things) meant that I couldn’t (and was not in the right state of mind) to focus much on the talks. When the BoF days started this was bit better but only on Thursday after the day trip I felt in a ‘conference mood’ and was able to focus fully on the BoFs that I was attending and sit down and hack a bit. If you want to learn more about the actual conference many people have blogged about it on the planet or read the report on the Akademy website.

In the end I think it’s fair to say that Akademy was a success. Made possible by KDE e.V. (go donate!), the sponsors, all the people of the Akademy team local and non-local, all the Volunteers on short and on long notice an last but not least all the awesome attendees - there would be no Akademy without any people. Thank you to you all! I am excited to learn about where next years Akademy will be (you can do it as well - it’s not hard and you get an awesome award on top) and looking forward to attending it as ‘normal Attendee’ and meeting everyone again there (if not earlier).

Today we are releasing GCompris version 4.2.

It contains bug fixes and graphics improvements on multiple activities.

This version adds translation for Latvian.

It is fully translated in the following languages:

• Arabic
• Bulgarian
• Breton
• Catalan
• Catalan (Valencian)
• Greek
• UK English
• Esperanto
• Spanish
• Basque
• French
• Galician
• Croatian
• Hungarian
• Indonesian
• Italian
• Lithuanian
• Latvian
• Malayalam
• Dutch
• Norwegian Nynorsk
• Polish
• Brazilian Portuguese
• Romanian
• Russian
• Slovenian
• Albanian
• Swedish
• Swahili
• Turkish
• Ukrainian

It is also partially translated in the following languages:

• Azerbaijani (97%)
• Belarusian (87%)
• Czech (97%)
• German (96%)
• Estonian (96%)
• Finnish (95%)
• Hebrew (96%)
• Macedonian (90%)
• Portuguese (96%)
• Slovak (84%)
• Chinese Traditional (96%)

You can find packages of this new version for GNU/Linux, Windows, Android, Raspberry Pi and macOS on the download page. This update will also be available soon in the Android Play store, the F-Droid repository and the Windows store.

Thank you all,
Timothée & Johnny

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.