Let’s go for my web review for the week 2023-41.

Six Months Ago NPR Left Twitter. The Effects Have Been Negligible - Nieman Reports

Tags: tech, twitter, information, social-media, criticism, fediverse

The first signs of journalism finding some independence from social media? That would be very welcome.

https://niemanreports.org/articles/npr-twitter-musk/

WordPress.com blogs can now be followed on Mastodon and other federated platforms | TechCrunch

Tags: tech, fediverse, blog, social-media

This is a huge thing for the ferdiverse. Let’s see where this leads.

https://techcrunch.com/2023/10/11/wordpress-com-blogs-can-now-be-followed-on-mastodon-and-other-federated-platforms/?guccounter=1

Engage a Wider Audience With ActivityPub on WordPress.com – WordPress.com News

Tags: tech, fediverse, blog, social-media

This is nice to see how easy it is to make sure a WordPress blog appears on the Fediverse. Hopefully will bring lots of activity.

https://wordpress.com/blog/2023/10/11/activitypub/

How AMD May Get Across the CUDA Moat

Tags: tech, cpu, gpu, performance, amd, nvidia

Will AMD really turn this around? Wait and see.

https://www.hpcwire.com/2023/10/05/how-amd-may-get-across-the-cuda-moat/

The midwit home - DYNOMIGHT INTERNET NEWSLETTER

Tags: tech, smarthome

Definitely this, I think people are very much overdoing the smart home thing. I far prefer something not too “smart” in this space.

https://dynomight.substack.com/p/midwit-home

“We’ll call it AI to Sell it, Machine Learning to Build it”

Tags: tech, ai, machine-learning

I agree with this, be precise about what you’re using. Blanket terms won’t lead you anywhere to creating proper systems.

https://theaiunderwriter.substack.com/p/well-call-it-ai-to-sell-it-machine

HTTP/2 Rapid Reset: deconstructing the record-breaking attack

Tags: tech, security, http

Interesting deep dive into the latest massive DDoS attack seen in the wild.

https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/

Coordinated Disclosure: 1-Click RCE on GNOME (CVE-2023-43641) - The GitHub Blog

Tags: tech, gnome, security

If you’re using a GNOME base environment be responsible and make sure you install your security patches.

https://github.blog/2023-10-09-coordinated-disclosure-1-click-rce-on-gnome-cve-2023-43641/

Where does my computer get the time from? – Tony Finch

Tags: tech, computers, time

Very good exploration about how to get time on computers. As usual it’s way less straightforward than what you might think.

https://dotat.at/@/2023-05-26-whence-time.html

Postgres: the next generation. Investing in the next generation of committers. – James Governor’s Monkchips

Tags: tech, databases, postgresql, community, hr

This is a very important point. Communities should make sure that new blood gets in. Companies should also avoid just recruiting top talent and groom juniors to contribute.

https://redmonk.com/jgovernor/2023/10/10/postgres-the-next-generation-investing-in-the-next-generation-of-committers/

Fury - A blazing fast multi-language serialization framework powered by jit and zero-copy

Tags: tech, data, performance, serialization

Looks like an interesting serialization framework. If it holds true to its claims it could be very useful in some place.

https://www.furyio.org/blog/fury_blazing_fast_multiple_language_serialization_framework

QBinDiff: A modular diffing toolkit

Tags: tech, tools, command-line

Looks like an interesting tool for diffing binary data.

https://blog.quarkslab.com/qbindiff-a-modular-diffing-toolkit.html

Unit-testing shell scripts and tools with shtk - Julio Merino (jmmv.dev)

Tags: tech, tests, command-line, shell

This can come in handy for automated tests which need to be ran from within a shell.

https://jmmv.dev/2023/10/unit-testing-with-shtk.html

Simulation Islands :: Box2D

Tags: tech, simulation, physics

This one is a lot. This is a very interesting exploration in rigid body simulation though. Shows well the trade-offs in term of performance and how to keep it usable for third party developers.

https://box2d.org/posts/2023/10/simulation-islands/

Scrollbars are becoming a problem

Tags: tech, ux, accessibility, gui

Some things we tend to not notice… the scroll bars need a way to be brought back and to be large for better accessibility.

https://artemis.sh/2023/10/12/scrollbars.html

On Importance of Naming in Programming | Wasp

Tags: tech, programming, craftsmanship

It’s one of the two hardest problems of programming after all. Needs to be thought through.

https://wasp-lang.dev/blog/2023/10/12/on-importance-of-naming-in-programming

API Best Practices: Foundations of Robust and Efficient APIs

Tags: tech, http, rest, web, services

A bit basic and obvious, still a good list of things to keep in mind when designing REST APIs.

https://medium.com/@atakanserbes/api-best-practices-d27876b1a1bd

McKinsey Developer Productivity Review - Dan North & Associates Ltd

Tags: tech, management, business, productivity

Very good review of the McKinsey paper about developer productivity. It not only highlights all the problems with it, it also makes suggestions to make a better paper next time.

https://dannorth.net/mckinsey-review/

Creativity faucet: Increase your creativity

Tags: creativity, writing

Interesting advices about creativity. The metaphors used help a bit as well.

https://www.julian.com/blog/creativity-faucet

VA hospital’s IT snafu blamed on cat’s keyboard surfing • The Register

Tags: tech, data, vandalism, funny

This is why cats cannot be trusted around computers!

https://www.theregister.com/2023/10/05/hospital_cat_incident/

Bye for now!

F10 for the Main Menu!

We now have a new KStandardShortcut. With https://commits.kde.org/kconfig/782e43f8076e5f4a10111a6b4d2cc6b1741c9798 the F10 key is now assigned to “Open Main Menu”. This is in my opinion a big win for accessibility because up until now for blind people there was no consistent way in our software to open the main menu.

You can see the problem for yourself if you try to get to the menu bar in your favourite KDE application. Notice how you can't get there using the Tab key? You actually need to hold down the Alt key and then use mnemonics i.e. the underlined letter to jump right there. Now blind people obviously can't see those underlined letters or there might not even be a menu bar in the first place so there actually was no reliable way for them to explore all the actions our software had to offer.

So now we decided (or rather I suggested and everyone seems to agree) to have F10 as the key to open the main menu. Why F10 you ask? Well, mostly because everyone else is already using it: Gnome, Microsoft, Chrome/ium, and Firefox (but Alt also works here). We don't want users to have to care which toolkit they use when they just want to open the main menu, so F10 was the logical choice.

However, only deciding on a standard shortcut obviously isn't enough. The opening of the main menu also needs to be implemented. My goal was to implement this for many applications for free. The other goal was to not disrupt those applications too much by taking away their F10 key. Unfortunately, a little bit of disruption is still necessary and this blog is here to announce this.

So considering that we have applications that use the menu bar as their main menu and others that use a hamburger menu and others that might have neither of those or some custom main menu, the best I did for now is to implement F10 to open a main menu in KHamburgerMenu. This is handled as a normal keyboard shortcut that is assigned to KHamburgerMenu by default and which will open either the menu bar or the hamburger menu depending on what the application currently uses. Even if the application currently has both the main menu and a hamburger menu button completely hidden my implementation makes sure that a menu still opens so no blind person ever has to wonder why nothing happened.

All of this means that after upgrading to KF6, pressing F10 in your KHamburgerMenu-using application might have a keyboard shortcut conflict. This won't/shouldn't lead to a crash or anything, just to an annoying popup. This can be avoided by assigning one of the conflicting actions to something else either in application code or by the user.

If an application does not use KHamburgerMenu, there will be no change at all. I would however encourage everyone to make F10 open the main menu for every application. That's typically very easy to implement. QMenuBar for example has a method for this. But honestly, if we are talking about an application that could be using KHamburgerMenu, it might be about as much work to implement a very minimal KHamburgerMenu. In kdenlive they only had to add 20 lines for this: https://invent.kde.org/multimedia/kdenlive/-/commit/cb38d57691cfba311c0e59fd748d88a5b8690ba8 This implementation will allow users to re-assign the keyboard shortcut.

I haven't really checked how to best do this in Kirigami-based applications.

Anyways, with F10 by itself partially dealt with, there is one more F10 related accessibility feature I need to talk about:

Shift+F10 to Open Context Menus!

You see, people who can't use a mouse pointer or other pointing device rely on the keyboard to open context menus. However, many keyboards these days do not have a Menu key. Therefore there is no way to open context menus by only using a keyboard! Well, at least not in KDE applications. Actually, this is again a situation where everyone else has already decided that context menus should be triggered by Shift+F10. This is already recommended by the Web Accessibility Initiative, Microsoft, and implemented in Chrome/ium and Firefox. We are, however, behind on this.

So on to the implementation. Skip to the end of this section if you only want to know what I will be doing and how this might affect your application.

How can I make every application also listen for Shift+F10? It would be really nice if, from one day to the other, all of our software would open context menus on Shift+F10. This can be accomplished by binding Shift+F10 to the Menu key which is surprisingly easy to do even as an end user. If you want to have this functionality today, do the following (not sure if it works on Wayland):

1. Create an .Xmodmap file in your home directory (https://linux.die.net/man/1/xmodmap):

   cd 
   xmodmap -pke > .Xmodmap 
   

   This file will be used to re-assign keys or keyboard shortcuts.

2. Open that file and change the line that looks somewhat like this

   keycode 76 = F10 F10 F10 F10 F10 F10 XF86Switch_VT_10
   

   to this

   keycode 76 = F10 Menu F10 F10 F10 F10 XF86Switch_VT_10
   

   Replacing this second occurrence of F10 in this line with Menu will tell the software Xmodmap that from now on, pressing the key with the keycode 76 simultaneously with Shift should be translated to a Menu key press.

Delete this file later if you don't want key re-assignment anymore.

Now obviously this means that no software anywhere will be able to use Shift+F10 for anything. Or rather: It will always be interpreted as a Menu key, so the Menu key and Shift+F10 would always do the same.

Honestly, it might be a bit rude to take away Shift+F10 from all software, but I am not sure if this would even be a problem. I kind of doubt that there are many applications that have any crucial functionality on Shift+F10 and do not allow to re-assign this. If this was the only downside to this approach, I might have tried to convince the wider KDE community that this or something similar was the best way forward. However, the thing is that this only solves the problem in situations in which we/Plasma have control over the system. This won't fix any of our software when it is used in a system in which one can't interpret Shift+F10 as Menu.

A different idea I had, which is a bit more targeted, would have been to instead implement the above as part of the KDE platform. Qt software adapts itself to the platform it runs on, so we have some control there which we can force upon software by implementing a platform plugin (see https://doc.qt.io/qt-6/qpa.html or https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbkeyboard.cpp#n903). This would then only affect Qt software instead of affecting the whole system, but once again: This only works as long as our software runs on a platform that we control.

So this needs to be implemented on a non-system layer. Frameworks perhaps? What about interpreting Shift+F10 as Menu through an EventFilter on top of the QApplication?

This works and is portable but I would still take away softwares' autonomy to use Shift+F10 as they please (or at least require them to opt out). It is also not nice for performance reasons because such an EventFilter will slightly slow down every user interaction with the application.

Okay, let's try to be even more cautious and choose a different implementation. Let's simply override QMainWindow::keyPressEvent(). Unfortunately this means that only key press events on children of QMainWindow can be handled. Key presses on secondary windows the application might have won't be within our grasp. However, on the plus side, key presses will only arrive at this method if they hadn't be handled by the application already. So we wouldn't be taking away Shift+F10 from the application! Good news!

So this is what I am going to do: I will override the QMainWindow::keyPressEvent() in the KXmlGui framework so that we post our own context menu events whenever a Shift+F10 key press comes in. This works pretty well so far from my testing. It doesn't always work unfortunately because the context menu opening was, in some cases, implemented in a way that expects either right-clicks or Menu key presses in a hard-coded way. They don't react to QContextMenuEvents as they should. So in those cases I might adapt some widgets so they behave nicely.

This will result in applications using the KXmlGui framework reacting to Shift+F10 by opening context menus if the applications don't already handle or use Shift+F10 themselves. If applications really absolutely do not want anything to happen when Shift+F10 is pressed, they can filter these events out beforehand.

Shout-out and Thanks

This work is being supported by the NLnet foundation and the European Commission! The project I am being funded for isn't really specifically about accessibility, but the people at NLnet are so nice and forward-thinking that I am allowed to do a good amount of work on improving accessibility in Dolphin as part of my grant. As is the nature of open source, in this case many KDE applications will benefit from this work.

I also want to mention Fushan Wen here even though he had nothing to do with any of the work mentioned in this blog post simply because he has been doing outstanding work for accessibility in KDE for many month now.

The Problem with C++ Tooling

An ISO accepted C++ tooling is inexistent, so each project will choose their own toolings based on personal preference, and sometimes, based on Corporations preferences, and unfortunately there's no common ground on what should be used. There are some programs that got the Standard by consensus, like CMake. But even tough, projects will choose handmade makefiles, KConfig, meson, autotools, and many others exist.

The same thing happens for Package Managers, each Linux distributtion has a variant of packages, and on top of that there's vcpkg, conan - each one with pros and cons.

The lack of a node or a cargo or a pip that's the entry point for the language makes it complex for developers to know where to start, and the most common idea is to build what doesn't exist, or manually install (via git submodules/git subtrees) things that are not disponible in your distribution or operating system.

How Codevis Started (Tools and Libraries)

Codevis started as an experiment to see if it would be possible to apply the ideas in the Large Scale C++ book by John Lakos. A small proof of concept was created three years ago, and we adopted a lot of libraries to be able to work fast keeping the quality high:

• Qt (5 and 6)
• soci (database layer used at CERN)
• QuaZip (easy access to compressed files)
• LLVM and CLang (parsing of C++ files)
• Sqlite3 (our actual database)
• Doxygen (Documentation)
• Python (Plugins)
• Catch2 (Tests)

And this is already a fair number of libraries, specially considering that those libraries also depend on others, keeping the Dependency graph quite large.

One problem that we had was to create a CI for all systems we targeted with all those libraries. both of the most common C++ package managers failed us:

• conan did not had LLVM (and we indeed created patches for it, adding missing libraries)
• vcpkg did not had some libraries that we needed, too.

Because of this we had to manually create base CI scripts that would download, compile, install the libraries that were not found on the package managers but this is frail, as any handwritten script is.

We started to look for a new home, and KDE was nice enough to host us. This gave us their amazing CI and buildsystems, that already had all the libraries we used, plus a few more.

So we were able to drop the handwritten scripts for, mostly, llvm.

Why did the change from Pure Qt to KDE Frameworks?

When you are inside of a system that works, and that offers powerful and battle tested libraries, it's worth to try to use them. There are many libraries in the KDE Frameworks that I wanted to use before but it was too hard to bring to windows if I'm not using craft, resembles to conan and knows how to build libraries and applications within the KDE universe.

Adding the necessary information to build Codevis in craft was much simpler than expected.:

• clone craft-blueprints-kde
• copy a program template and chagne it's name
• point to the kde repository with a list of libraries it should use

The full codevis recipe for windows, mac and linux using craft is the following: Note that every line on runtimeDependencies and buildDependencies are a craft recipe inside of the same repository, so just by searching the folders it's easy to know what to add for your program.

import info
from Packager.CollectionPackagerBase import PackagerLists

class subinfo(info.infoclass):
    def setTargets(self):
        self.versionInfo.setDefaultValues()
        self.description = "Codevis is a software to visualize large software architectures."
        self.displayName = "Codevis"
        self.webpage = "http://invent.kde.org/sdk/codevis"
        self.svnTargets["master"] = "http://invent.kde.org/sdk/codevis.git"

    def setDependencies(self):
        self.buildDependencies["kde/frameworks/extra-cmake-modules"] = None
        self.runtimeDependencies["libs/llvm"] = None
        self.runtimeDependencies["libs/zlib"] = None
        self.runtimeDependencies["libs/catch2"] = None
        self.runtimeDependencies["qt-libs/quazip"] = None
        self.runtimeDependencies["libs/runtime"] = None
        self.runtimeDependencies["libs/qt5/qtbase"] = None

from Package.CMakePackageBase import *

class Package(CMakePackageBase):
    def __init__(self):
        CMakePackageBase.__init__(self)
        self.subinfo.options.configure.args += ["-DUSE_QT_WEBENGINE=OFF ", "-DCOMPILE_TESTS=OFF "]

    def createPackage(self):
        self.defines["executable"] = "bin\\codevis_desktop.exe"
        return TypePackager.createPackage(self)

How easy is to bring a 50 - 100K lines of code to KDE?

• We adopted KConfig

With The build part fixed, it was time to adopt some libraries to remove some handwritten logic we had. I wrote a configuration to c++ parser to easily access configuration keys from .ini format, but this was the only project using it, so why not change to KConfig, that uses a XML based description for settings, and it's used by almost all programs within the KDE Infrastructure (and it certainly has way more unittests preventing breackages than what I have on my try)

• We adopted KXmlGUI

KXMLGui is one of the killer features of the KDE Frameworks. It allow you to split the logic of your interface with a description of Menus and Toolbars in XML, and in runtime it provides some nice features like allowing the user to change the toolbars with any action registered within the system, and a searchable command pallete, that's something I use in all KDE applications on my machine, and I sure was missing this on Codevis.

• We adopted KDocTools

Documentation is complex, but having an integrated documentation viewer and semantics ready, that could compile into hmtl with integrated search is impressive. Now we just need the time to actually write that documentation...

• We adopted KNewStuff

KNewStuff is a technology that integrates with pling.com and allows to distribute certain types of downloadable goodies, like wallpapers - or in our case, plugins to improve the system with things that the main developers didn't had the time to do yet.

• We adopted KNotification

Since the application takes a while to parse C++ code, or to run some plugins, KNotification is used to send a desktop notification to the user when an action ends. A small feature, but good for UX.

• We adopted KTextEditor

We need to have a place for users to develop plugins for Codevis, so KTextEditor was not a hard choice, it's the editor that powers up Kate, one of the flagship applications from KDE. Using it has been extremely easy and fast, supporting syntax-highlihting for multiple formats.

An Honest, and unbiased, view

The work to port Codevis to use KDE libraries took around 2 weeks, and things were good. No major breakage and just some changes in behavior (mostly for the better). We also helped the KF6 libraries with ideas while discussing on their public channel in Matrix, and patches for some other programs while developing (such as Konsole, Kate, Konversation).

Nothing is perfect, but the outcome was a better, more stable, Codevis and the community was great while helping us understand how to use / handle specifics of a library - like KNotification using raw news without a corresponding call to a deleter. This was fixed by a comment on the Documentation stating that it auto-deletes itself.

Should Corporations Adopt KDE Libraries?

For sure. The libraries are really high quality, and there are more than 90 of them. Not using something that's already working and with tests, is a waste of money on the corporation side.

Are the devs Happy?

Yes, and I would use KDE Frameworks again.

The work for Codevis is sponsored by Bloomberg, and done by Codethink in the open, inside of the KDE Repositories.

At the moment I am hard at work putting together the final bits for the AppStream 1.0 release (hopefully to be released this month). The new release comes with many new new features, an improved developer API and removal of most deprecated things (so it carefully breaks compatibility with very old data and the previous C API). One of the tasks for the upcoming 1.0 release was #481 asking about a formal way to distinguish Linux phone applications from desktop applications.

AppStream infamously does not support any “is-for-phone” label for software components, instead the decision whether something is compatible with a device is based the the device’s capabilities and the component’s requirements. This allows for truly adaptive applications to describe their requirements correctly, and does not lock us into “form factors” going into the future, as there are many and the feature range between a phone, a tablet and a tiny laptop is quite fluid.

Of course the “match to current device capabilities” check does not work if you are a website ranking phone compatibility. It also does not really work if you are a developer and want to know which devices your component / application will actually be considered compatible with. One goal for AppStream 1.0 is to have its library provide more complete building blocks to software centers. Instead of just a “here’s the data, interpret it according to the specification” API, libappstream now interprets the specification for the application and provides API to handle most common operations – like checking device compatibility. For developers, AppStream also now implements a few “virtual chassis configurations”, to roughly gauge which configurations a component may be compatible with.

To test the new code, I ran it against the large Debian and Flatpak repositories to check which applications are considered compatible with what chassis/device type already. The result was fairly disastrous, with many applications not specifying compatibility correctly (many do, but it’s by far not the norm!). Which brings me to the actual topic of this blog post: Very few seem to really know how to mark an application compatible with certain screen sizes and inputs! This is most certainly a matter of incomplete guides and good templates, so maybe this post can help with that a bit:

The ultimate cheat-sheet to mark your app “chassis-type” compatible

As a quick reminder, compatibility is indicated using AppStream’s relations system: A requires relation indicates that the system will not run at all or will run terribly if the requirement is not met. If the requirement is not met, it should not be installable on a system. A recommends relation means that it would be advantageous to have the recommended items, but it’s not essential to run the application (it may run with a degraded experience without the recommended things though). And a supports relation means a given interface/device/control/etc. is supported by this application, but the application may work completely fine without it.

I have a desktop-only application

A desktop-only application is characterized by needing a larger screen to fit the application, and requiring a physical keyboard and accurate mouse input. This type is assumed by default if no capabilities are set for an application, but it’s better to be explicit. This is the metadata you need:

<component type="desktop-application">
  <id>org.example.desktopapp</id>
  <name>DesktopApp</name>
  [...]
  <requires>
    <display_length>768</display_length>

    <control>keyboard</control>
    <control>pointing</control>
  </requires>
  [...]
</component>

With this requires relation, you require a small-desktop sized screen (at least 768 device-independent pixels (dp) on its smallest edge) and require a keyboard and mouse to be present / connectable. Of course, if your application needs more minimum space, adjust the requirement accordingly. Note that if the requirement is not met, your application may not be offered for installation.

Note: Device-independent / logical pixels

One logical pixel (= device independent pixel) roughly corresponds to the visual angle of one pixel on a device with a pixel density of 96 dpi (for historical X11 reasons) and a distance from the observer of about 52 cm, making the physical pixel about 0.26 mm in size. When using logical pixels as unit, they might not always map to exact physical lengths as their exact size is defined by the device providing the display. They do however accurately depict the maximum amount of pixels that can be drawn in the depicted direction on the device’s display space. AppStream always uses logical pixels when measuring lengths in pixels.

I have an application that works on mobile and on desktop / an adaptive app

Adaptive applications have fewer hard requirements, but a wide range of support for controls and screen sizes. For example, they support touch input, unlike desktop apps. An example MetaInfo snippet for these kind of apps may look like this:

<component type="desktop-application">
  <id>org.example.adaptive_app</id>
  <name>AdaptiveApp</name>
  [...]

  <requires>
    <display_length>360</display_length>
  </requires>

  <supports>
    <control>keyboard</control>
    <control>pointing</control>
    <control>touch</control>
  </supports>
  [...]
</component>

Unlike the pure desktop application, this adaptive application requires a much smaller lowest display edge length, and also supports touch input, in addition to keyboard and mouse/touchpad precision input.

I have a pure phone/table app

Making an application a pure phone application is tricky: We need to mark it as compatible with phones only, while not completely preventing its installation on non-phone devices (even though its UI is horrible, you may want to test the app, and software centers may allow its installation when requested explicitly even if they don’t show it by default). This is how to achieve that result:

<component type="desktop-application">
  <id>org.example.phoneapp</id>
  <name>PhoneApp</name>
  [...]

  <requires>
    <display_length>360</display_length>
  </requires>

  <recommends>
    <display_length compare="lt">1280</display_length>
    <control>touch</control>
  </recommends>
  [...]
</component>

We require a phone-sized display minimum edge size (adjust to a value that is fit for your app!), but then also recommend the screen to have a smaller edge size than a larger tablet/laptop, while also recommending touch input and not listing any support for keyboard and mouse.

Please note that this blog post is of course not a comprehensive guide, so if you want to dive deeper into what you can do with requires/recommends/suggests/supports, you may want to have a look at the relations tags described in the AppStream specification.

Validation

It is still easy to make mistakes with the system requirements metadata, which is why AppStream 1.0 will provide more commands to check MetaInfo files for system compatibility. Current pre-1.0 AppStream versions already have an is-satisfied command to check if the application is compatible with the currently running operating system:

:~$ appstreamcli is-satisfied ./org.example.adaptive_app.metainfo.xml
Relation check for: */*/*/org.example.adaptive_app/*

Requirements:
 • Unable to check display size: Can not read information without GUI toolkit access.
Recommendations:
 • No recommended items are set for this software.
Supported:
 ✔ Physical keyboard found.
 ✔ Pointing device (e.g. a mouse or touchpad) found.
 • This software supports touch input.

In addition to this command, AppStream 1.0 will introduce a new one as well: check-syscompat. This command will check the component against libappstream’s mock system configurations that define a “most common” (whatever that is at the time) configuration for a respective chassis type.

If you pass the --details flag, you can even get an explanation why the component was considered or not considered for a specific chassis type:

:~$ appstreamcli check-syscompat --details ./org.example.phoneapp.metainfo.xml
Chassis compatibility check for: */*/*/org.example.phoneapp/*

Desktop:
 ✘ Incompatible
 • recommends: This software recommends a display with its shortest edge
   being << 1280 px in size, but the display of this device has 1280 px.
 • recommends: This software recommends a touch input device.

Laptop:
 ✘ Incompatible
 • recommends: This software recommends a display with its shortest edge 
   being << 1280 px in size, but the display of this device has 1280 px.
 • recommends: This software recommends a touch input device.

Server:
 ✘ Incompatible
 • requires: This software needs a display for graphical content.
 • recommends: This software needs a display for graphical content.
 • recommends: This software recommends a touch input device.

Tablet:
 ✔ Compatible (100%)

Handset:
 ✔ Compatible (100%)

I hope this is helpful for people. Happy metadata writing! 😀

KNotifications is KDE’s framework for creating popup notifications. It supports Linux, Windows, macOS, and Android, making it, to my knowledge, the most complete cross-platform library for this available in C++. This makes it natually interesting to use for non-KDE Qt application developers.

However there is one aspect that makes it less attractive for third-party developers: It’s number of dependencies. As of KNotifications 5.110 it depends on the following other KDE Frameworks:

• KCoreAddons
• KConfig
• KWindowSystem

as well as some third-party like QtWidgets, X11, libdbusmenu-qt and libcanberra.

While none of these are a hard blocker for usage in most cases the overall impression isn’t very appetizing. During the KF5 time we already weeded out some dependencies that don’t make sense on some platforms, like removing the QtWidgets dependency on Android. We were however somewhat limited in our ability to do large cleanups by our strict API/ABI stability promise. For KF6 we have the opportunity do to larger cleanups.

One larger source of dependencies is the KStatusNotifierItem class, which is part of the KNotifications framework and is used to create system tray icons. Since its functionality is rather independent from creating popup notifications we decided to split it out into a separate, new framework. This significantly reduces the number of dependencies of KNotifications. A number of other changes further reduced the number of dependencies and cleaned up the public API a bit.

As a result what will become KF6 KNotifications on Linux only depends on Qt (QtGui + QtDBus, and optionally QtQml for QML support), KConfig (that would also be feasible to remove if someone is motivated enough) and libcanberra (for playing notification sounds).

Other KDE Frameworks received similar changes, but KNotifications is likely the one where this has the largest impact.

Doing this kind of work is part of my position as KDE Software Platform Engineer. To support my work please consider donating to KDE e.V..

This is a sort-of reply to Herzenschein’s blog post from a few months ago. He goes over how to tell KConfig put it’s files into app-specific folders instead of dumping them into the garbage bin of ~/.config. He noted that he hasn’t touched KConfigXT yet, so this is how to make it work with KConfigXT applications.

However you’ll notice by default KConfigXT generates constructors for your configuration class like this:

class Config : public KConfigSkeleton
{
  Q_OBJECT
  public:

    Config( QObject *parent );
    ~Config() override;
...

That’s not useful, and it took me a minute to figure out how to allow KConfigSkeleton and the KConfig compiler to let me pass AppConfigLocation. However, the solution is very simple.

First, you need to make sure it’s not a Singleton. (There’s probably a way to make it work with a singleton though.) Make sure that setting is turned off in your .kcfgc:

File=config.kcfg
ClassName=Config
Mutators=true
DefaultValueGetters=true
GenerateProperties=true
Singleton=false

And then in your .kcfg, modify the <kcfgfile> block to add arg = "true" instead of hardcoding a filename. It will look something like this:

<kcfgfile arg="true" />

Once you run the compiler again, you’ll get a constructor that allows you to pass a KSharedConfig!

class Config : public KConfigSkeleton
{
  Q_OBJECT
  public:

    Config( KSharedConfig::Ptr config = KSharedConfig::openConfig() );
    ~Config() override;
...

And then you call the usual function:

new Config(KSharedConfig::openConfig("myappconfigrc", KConfig::SimpleConfig, QStandardPaths::AppConfigLocation));

Now enjoy your configuration file living in it’s own directory! Here’s the constructor parameter logic in KConfig which was essential in figuring this out.

Let’s go for my web review for the week 2023-40.

BBC Gives Up On Threads (By Instagram), Sticks With Mastodon — Darnell (Seize The Day)

Tags: tech, fediverse

This is an interesting move from the BBC. We can only theorize on the reasons but that’s a positive example of a successful fediverse presence so far.

https://darnell.day/bbc-gives-up-on-threads-by-instagram-sticks-with-mastodon

AI from a legal perspective [LWN.net]

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

Looks like it was a very interesting talk. Situation still needs to be monitored in any case, it’s uncertain how those cases will be ruled.

https://lwn.net/SubscriberLink/945504/ee1f1db87dae56b1/

Predictive Policing Software Terrible At Predicting Crimes – The Markup

Tags: tech, politics, bias

A bad solution in search of a problem basically. Let’s look at the alternatives and fund proper solutions to why people are victimized, shall we?

https://themarkup.org/prediction-bias/2023/10/02/predictive-policing-software-terrible-at-predicting-crimes

Lazarus luring employees with trojanized coding challenges: The case of a Spanish aerospace company

Tags: tech, security

Very refined attack including the social engineering side of things. Catching developers with coding challenges, it’s definitely cunning.

https://www.welivesecurity.com/en/eset-research/lazarus-luring-employees-trojanized-coding-challenges-case-spanish-aerospace-company/

Google Doc injects tracking redirects in documents

Tags: tech, google, surveillance

Why you can’t trust this kind of proprietary software…

https://fosstodon.org/@Joe_0237/111145684757912952

Compromised Microsoft Key: More Impactful Than We Thought | Wiz Blog

Tags: tech, microsoft, cloud, security

Totally missed this over the summer… this is a huge breach. It will have a long lasting impact. The scope might be larger than we expect.

https://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr

Microsoft comes under blistering criticism for “grossly irresponsible” security | Ars Technica

Tags: tech, microsoft, cloud, security

Really a bad summer for Microsoft security wise. Trust should be low among Azure customers now. Who was paying attention though?

https://arstechnica.com/security/2023/08/microsoft-cloud-security-blasted-for-its-culture-of-toxic-obfuscation/

The Marvin Attack

Tags: tech, security

An attack which doesn’t want to die. Time to retire RSA use with TLS, this is really overdue.

https://people.redhat.com/~hkario/marvin/

Python 3.12: what didn’t make the headlines - Bite code!

Tags: tech, python, programming

A few good things went unnoticed. The performances are still not there.

https://www.bitecode.dev/p/python-312-what-didnt-make-the-headlines

Open Sourcing Ferrocene - Ferrous Systems

Tags: tech, rust, safety

This is a big deal for the places where Rust could shine.

https://ferrous-systems.com/blog/ferrocene-open-source/

The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!) @ tonsky.me

Tags: tech, unicode, encodings

Very nice primer on how Unicode works. Definitely a must read and a good starting point. Definitely highlights properly some of the difficulties we need to deal with now and talks about the normalization forms.

https://tonsky.me/blog/unicode/

Lessons From Debugging

Tags: tech, programming, debugging

List of strategies to keep in mind when debugging.

https://matt-rickard.com/lessons-from-debugging

Concurrency Freaks: 50 years later, is Two-Phase Locking the best we can do?

Tags: tech, multithreading, databases

Good way to understand two phase locking better, its tradeoffs, variants and how it’s been improved.

https://concurrencyfreaks.blogspot.com/2023/09/50-years-later-is-two-phase-locking.html?m=1

Database Migrations

Tags: tech, architecture, databases

Interesting primer of the intricacies of database migrations. It can get complex fairly quickly.

https://vadimkravcenko.com/shorts/database-migrations/

Goodbye to sequential integers, hello UUIDv7!

Tags: tech, uuid, databases

Interesting property of the newer UUIDv7 spec.

https://buildkite.com/blog/goodbye-integers-hello-uuids

mimic.css

Tags: tech, web, css, frontend, funny

Nice and fun little demo of what can be done with CSS animations.

https://erictreacy.github.io/mimic.css/

Flexbox Froggy - A game for learning CSS flexbox

Tags: tech, web, css, frontend, funny

Fun way to understand better the CSS layouting using flexboxes.

https://flexboxfroggy.com/

OCuLink as an eGPU and cheap PCIe connectivity solution for laptops and mobile devices

Tags: tech, 3d, gpu

Interesting connector, I didn’t know about this one.

https://rkblog.dev/posts/pc-hardware/gpd-win-max2/oculink-as-egpu-solution/

Optimization Techniques for GPU Programming - 3570638.pdf

Tags: tech, gpu, computation, performance, optimization

Very thorough paper on optimization techniques when dealing with GPUs. Can be a useful reference or starting point to then dig deeper. Should also help to pick the right technique for your particular problem.

https://dl.acm.org/doi/pdf/10.¹¹⁴⁵⁄_3570638

Diora Devlog

Tags: tech, 3d

Very clever tricks for a performant little engine.

https://dioragame.com/devlog/?log=3

pkgx — Run Anything

Tags: tech, command-line, tools, developer-experience

Looks like an interesting tool to manage developer environments.

https://pkgx.sh/

bruno

Tags: tech, http, tools

Looks like an interesting alternative to things like postman or insomnia. To test when I get the chance.

https://www.usebruno.com/

Dependency Whac-A-Mole

Tags: tech, architecture, dependencies, complexity

Mind how you pick your dependencies and how they fare over time. You might need to reevaluate and let go some of them.

https://blog.ploeh.dk/2023/10/02/dependency-whac-a-mole/

Cloud Costs Every Programmer Should Know

Tags: tech, cloud, business, cost

Interesting approximations to get a feel of how much a cloud project will cost.

https://www.vantage.sh/blog/cloud-costs-every-programmer-should-know

Conventional Comments

Tags: tech, codereview, communication

We see this kind of comments in some reviews, this would benefit from being more widespread.

https://conventionalcomments.org/

What Predicts Software Developers’ Productivity?

Tags: tech, management, organization, productivity

Interestingly (or maybe unsurprisingly) most of the factors this research found impactful are not technical. So mind the social constructs of your organization.

https://newsletter.getdx.com/p/factors-of-developer-productivity

Seniority and self-management: you don’t have to do this alone - Jacob Kaplan-Moss

Tags: tech, coaching, management

Definitely this, I too often see people trying to just power through. Being responsible of something doesn’t mean you do it all alone, on the contrary. If you’re struggling with it look for help, it can take many forms including coaching.

https://jacobian.org/2023/oct/4/seniority-and-self-management/

Bye for now!

Welcome to the first "Codevis Weekly Update"

What is Codevis?

Codevis is a tool to help developers manage large codebases, sponsored by Bloomberg, developed by Codethink and hosted on the KDE Infrastructure, with all that, completely opensource with a permissive license. Codevis uses a mix of technologies to do what it does, mainly LLVM and Clang to do the heavy lifting of understanding C++ Codebases, Qt for Callback management (in the form of Signal/Slots), KDE Frameworks libraries for the desktop application, and pure Qt for the CLI application. The database layer is written with Soci , the same database layer used in CERN, targeting sqlite3.

But How does it work?

Codevis analyzes all the visible source code from your project and creates a graph database (using a relational database) in a way that the analyst can load and interpret information from the codebase without loading the codebase. The graph-database is comprehensive, and has all the information we think it's important, and also a lot of information that's good to have, with a bunch of information because why not. Since something that's not important for me could be really important for a company with billions of lines of code.

It just generates visualization?

No. Codevis also allows you to draw your software architecture and generate ready-to-compile c++ code from it. Think of this as a possibility to have C++ templates for complex projects tha are also visually documented. You can create libraries, classes, structures, connect them quickly on a dirty mockup during a meeting, and the output could be 60 c++ files on disk with all the classes, folder-hierarchy and CMake ready to compile.

This will not add any method or implement anything, but just the creation of the C++ files and CMake scripts from a small architecture meeting is pretty interesting in my point of view.

Contributing to KDE sometimes leads to a flood of negative or even insulting feedback. To not get disheartened by this it is important to correctly assess the significance of these comments. One possible stance to take towards these reports can be taken from punk culture.

I hope this video with hand-crafted subtitles will be a valuable resource for people stumbling into this situation in the future. Enjoy the skateboarding clips!