Planet KDE

This post is in part a response to an aspect of Nate’s post “Does Wayland really break everything?“, but also my reflection on discussing Wayland protocol additions, a unique pleasure that I have been involved with for the past months1.

Some facts

Before I start I want to make a few things clear: The Linux desktop will be moving to Wayland2 – this is a fact at this point (and has been for a while), sticking to X11 makes no sense for future projects. From reading Wayland protocols and working with it at a much lower level than I ever wanted to, it is also very clear to me that Wayland is an exceptionally well-designed core protocol, and so are the additional extension protocols (xdg-shell & Co.). The modularity of Wayland is great, it gives it incredible flexibility and will for sure turn out to be good for the long-term viability of this project (and also provides a path to correct protocol issues in future, if one is found). In other words: Wayland is an amazing foundation to build on, and a lot of its design decisions make a lot of sense!

The shift towards people seeing “Linux” more as an application developer platform, and taking PipeWire and XDG Portals into account when designing for Wayland is also an amazing development and I love to see this – this holistic approach is something I always wanted!

Furthermore, I think Wayland removes a lot of functionality that shouldn’t exist in a modern compositor – and that’s a good thing too! Some of X11’s features and design decisions had clear drawbacks that we shouldn’t replicate. I highly recommend to read Nate’s blog post, it’s very good and goes into more detail. And due to all of this, I firmly believe that any advancement in the Wayland space must come from within the project.

But!

But! Of course there was a “but” coming – I think while developing Wayland-as-an-ecosystem we are now entrenched into narrow concepts of how a desktop should work. While discussing Wayland protocol additions, a lot of concepts clash, people from different desktops with different design philosophies debate the merits of those over and over again never reaching any conclusion (just as you will never get an answer out of humans whether sushi or pizza is the clearly superior food, or whether CSD or SSD is better). Some people want to use Wayland as a vehicle to force applications to submit to their desktop’s design philosophies, others prefer the smallest and leanest protocol possible, other developers want the most elegant behavior possible. To be clear, I think those are all very valid approaches.

But this also creates problems: By switching to Wayland compositors, we are already forcing a lot of porting work onto toolkit developers and application developers. This is annoying, but just work that has to be done. It becomes frustrating though if Wayland provides toolkits with absolutely no way to reach their goal in any reasonable way. For Nate’s Photoshop analogy: Of course Linux does not break Photoshop, it is Adobe’s responsibility to port it. But what if Linux was missing a crucial syscall that Photoshop needed for proper functionality and Adobe couldn’t port it without that? In that case it becomes much less clear on who is to blame for Photoshop not being available.

A lot of Wayland protocol work is focused on the environment and design, while applications and work to port them often is considered less. I think this happens because the overlap between application developers and developers of the desktop environments is not necessarily large, and the overlap with people willing to engage with Wayland upstream is even smaller. The combination of Windows developers porting apps to Linux and having involvement with toolkits or Wayland is pretty much nonexistent. So they have less of a voice.

A quick detour through the neuroscience research lab

I have been involved with Freedesktop, GNOME and KDE for an incredibly long time now (more than a decade), but my actual job (besides consulting for Purism) is that of a PhD candidate in a neuroscience research lab (working on the morphology of biological neurons and its relation to behavior). I am mostly involved with three research groups in our institute, which is about 35 people. Most of us do all our data analysis on powerful servers which we connect to using RDP (with KDE Plasma as desktop). Since I joined, I have been pushing the envelope a bit to extend Linux usage to data acquisition and regular clients, and to have our data acquisition hardware interface well with it. Linux brings some unique advantages for use in research, besides the obvious one of having every step of your data management platform introspectable with no black boxes left, a goal I value very highly in research (but this would be its own blogpost).

In terms of operating system usage though, most systems are still Windows-based. Windows is what companies develop for, and what people use by default and are familiar with. The choice of operating system is very strongly driven by application availability, and WSL being really good makes this somewhat worse, as it removes the need for people to switch to a real Linux system entirely if there is the occasional software requiring it. Yet, we have a lot more Linux users than before, and use it in many places where it makes sense. I also developed a novel data acquisition software that even runs on Linux-only and uses the abilities of the platform to its fullest extent. All of this resulted in me asking existing software and hardware vendors for Linux support a lot more often. Vendor-customer relationship in science is usually pretty good, and vendors do usually want to help out. Same for open source projects, especially if you offer to do Linux porting work for them… But overall, the ease of use and availability of required applications and their usability rules supreme. Most people are not technically knowledgeable and just want to get their research done in the best way possible, getting the best results with the least amount of friction.

KDE/Linux usage at a control station for a particle accelerator at Adlershof Technology Park, Germany, for reference (by 25years of KDE)3 Back to the point

The point of that story is this: GNOME, KDE, RHEL, Debian or Ubuntu: They all do not matter if the necessary applications are not available for them. And as soon as they are, the easiest-to-use solution wins. There are many facets of “easiest”: In many cases this is RHEL due to Red Hat support contracts being available, in many other cases it is Ubuntu due to its mindshare and ease of use. KDE Plasma is also frequently seen, as it is perceived a bit easier to onboard Windows users with it (among other benefits). Ultimately, it comes down to applications and 3rd-party support though.

Here’s a dirty secret: In many cases, porting an application to Linux is not that difficult. The thing that companies (and FLOSS projects too!) struggle with and will calculate the merits of carefully in advance is whether it is worth the support cost as well as continuous QA/testing. Their staff will have to do all of that work, and they could spend that time on other tasks after all.

So if they learn that “porting to Linux” not only means added testing and support, but also means to choose between the legacy X11 display server that allows for 1:1 porting from Windows or the “new” Wayland compositors that do not support the same features they need, they will quickly consider it not worth the effort at all. I have seen this happen.

Of course many apps use a cross-platform toolkit like Qt, which greatly simplifies porting. But this just moves the issue one layer down, as now the toolkit needs to abstract Windows, macOS and Wayland. And Wayland does not contain features to do certain things or does them very differently from e.g. Windows, so toolkits have no way to actually implement the existing functionality in a way that works on all platforms. So in Qt’s documentation you will often find texts like “works everywhere except for on Wayland compositors or mobile”4.

Many missing bits or altered behavior are just papercuts, but those add up. And if users will have a worse experience, this will translate to more support work, or people not wanting to use the software on the respective platform.

What’s missing? Window positioning

SDI applications with multiple windows are very popular in the scientific world. For data acquisition (for example with microscopes) we often have one monitor with control elements and one larger one with the recorded image. There is also other configurations where multiple signal modalities are acquired, and the experimenter aligns windows exactly in the way they want and expects the layout to be stored and to be loaded upon reopening the application. Even in the image from Adlershof Technology Park above you can see this style of UI design, at mega-scale. Being able to pop-out elements as windows from a single-window application to move them around freely is another frequently used paradigm, and immensely useful with these complex apps.

It is important to note that this is not a legacy design, but in many cases an intentional choice – these kinds of apps work incredibly well on larger screens or many screens and are very flexible (you can have any window configuration you want, and switch between them using the (usually) great window management abilities of your desktop).

Of course, these apps will work terribly on tablets and small form factors, but that is not the purpose they were designed for and nobody would use them that way.

I assumed for sure these features would be implemented at some point, but when it became clear that that would not happen, I created the ext-placement protocol which had some good discussion but was ultimately rejected from the xdg namespace. I then tried another solution based on feedback, which turned out not to work for most apps, and now proposed xdg-placement (v2) in an attempt to maybe still get some protocol done that we can agree on, exploring more options before pushing the existing protocol for inclusion into the ext Wayland protocol namespace. Meanwhile though, we can not port any application that needs this feature, while at the same time we are switching desktops and distributions to Wayland by default.

Window position restoration

Similarly, a protocol to save & restore window positions was already proposed in 2018, 6 years ago now, but it has still not been agreed upon, and may not even help multiwindow apps in its current form. The absence of this protocol means that applications can not restore their former window positions, and the user has to move them to their previous place again and again.

Meanwhile, toolkits can not adopt these protocols and applications can not use them and can not be ported to Wayland without introducing papercuts.

Window icons

Similarly, individual windows can not set their own icons, and not-installed applications can not have an icon at all because there is no desktop-entry file to load the icon from and no icon in the theme for them. You would think this is a niche issue, but for applications that create many windows, providing icons for them so the user can find them is fairly important. Of course it’s not the end of the world if every window has the same icon, but it’s one of those papercuts that make the software slightly less user-friendly. Even applications with fewer windows like LibrePCB are affected, so much so that they rather run their app through Xwayland for now.

I decided to address this after I was working on data analysis of image data in a Python virtualenv, where my code and the Python libraries used created lots of windows all with the default yellow “W” icon, making it impossible to distinguish them at a glance. This is xdg-toplevel-icon now, but of course it is an uphill battle where the very premise of needing this is questioned. So applications can not use it yet.

Limited window abilities requiring specialized protocols

Firefox has a picture-in-picture feature, allowing it to pop out media from a mediaplayer as separate floating window so the user can watch the media while doing other things. On X11 this is easily realized, but on Wayland the restrictions posed on windows necessitate a different solution. The xdg-pip protocol was proposed for this specialized usecase, but it is also not merged yet. So this feature does not work as well on Wayland.

Automated GUI testing / accessibility / automation

Automation of GUI tasks is a powerful feature, so is the ability to auto-test GUIs. This is being worked on, with libei and wlheadless-run (and stuff like ydotool exists too), but we’re not fully there yet.

Wayland is frustrating for (some) application authors

As you see, there is valid applications and valid usecases that can not be ported yet to Wayland with the same feature range they enjoyed on X11, Windows or macOS. So, from an application author’s perspective, Wayland does break things quite significantly, because things that worked before can no longer work and Wayland (the whole stack) does not provide any avenue to achieve the same result.

Wayland does “break” screen sharing, global hotkeys, gaming latency (via “no tearing”) etc, however for all of these there are solutions available that application authors can port to. And most developers will gladly do that work, especially since the newer APIs are usually a lot better and more robust. But if you give application authors no path forward except “use Xwayland and be on emulation as second-class citizen forever”, it just results in very frustrated application developers.

For some application developers, switching to a Wayland compositor is like buying a canvas from the Linux shop that forces your brush to only draw triangles. But maybe for your avant-garde art, you need to draw a circle. You can approximate one with triangles, but it will never be as good as the artwork of your friends who got their canvases from the Windows or macOS art supply shop and have more freedom to create their art.

Triangles are proven to be the best shape! If you are drawing circles you are creating bad art!

Wayland, via its protocol limitations, forces a certain way to build application UX – often for the better, but also sometimes to the detriment of users and applications. The protocols are often fairly opinionated, a result of the lessons learned from X11. In any case though, it is the odd one out – Windows and macOS do not pose the same limitations (for better or worse!), and the effort to port to Wayland is orders of magnitude bigger, or sometimes in case of the multiwindow UI paradigm impossible to achieve to the same level of polish. Desktop environments of course have a design philosophy that they want to push, and want applications to integrate as much as possible (same as macOS and Windows!). However, there are many applications out there, and pushing a design via protocol limitations will likely just result in fewer apps.

The porting dilemma

I spent probably way too much time looking into how to get applications cross-platform and running on Linux, often talking to vendors (FLOSS and proprietary) as well. Wayland limitations aren’t the biggest issue by far, but they do start to come come up now, especially in the scientific space with Ubuntu having switched to Wayland by default. For application authors there is often no way to address these issues. Many scientists do not even understand why their Python script that creates some GUIs suddenly behaves weirdly because Qt is now using the Wayland backend on Ubuntu instead of X11. They do not know the difference and also do not want to deal with these details – even though they may be programmers as well, the real goal is not to fiddle with the display server, but to get to a scientific result somehow.

Another issue is portability layers like Wine which need to run Windows applications as-is on Wayland. Apparently Wine’s Wayland driver has some heuristics to make window positioning work (and I am amazed by the work done on this!), but that can only go so far.

A way out?

So, how would we actually solve this? Fundamentally, this excessively long blog post boils down to just one essential question:

Do we want to force applications to submit to a UX paradigm unconditionally, potentially loosing out on application ports or keeping apps on X11 eternally, or do we want to throw them some rope to get as many applications ported over to Wayland, even through we might sacrifice some protocol purity?

I think we really have to answer that to make the discussions on wayland-protocols a lot less grueling. This question can be answered at the wayland-protocols level, but even more so it must be answered by the individual desktops and compositors.

If the answer for your environment turns out to be “Yes, we want the Wayland protocol to be more opinionated and will not make any compromises for application portability”, then your desktop/compositor should just immediately NACK protocols that add something like this and you simply shouldn’t engage in the discussion, as you reject the very premise of the new protocol: That it has any merit to exist and is needed in the first place. In this case contributors to Wayland and application authors also know where you stand, and a lot of debate is skipped. Of course, if application authors want to support your environment, you are basically asking them now to rewrite their UI, which they may or may not do. But at least they know what to expect and how to target your environment.

If the answer turns out to be “We do want some portability”, the next question obviously becomes where the line should be drawn and which changes are acceptable and which aren’t. We can’t blindly copy all X11 behavior, some porting work to Wayland is simply inevitable. Some written rules for that might be nice, but probably more importantly, if you agree fundamentally that there is an issue to be fixed, please engage in the discussions for the respective MRs! We for sure do not want to repeat X11 mistakes, and I am certain that we can implement protocols which provide the required functionality in a way that is a nice compromise in allowing applications a path forward into the Wayland future, while also being as good as possible and improving upon X11. For example, the toplevel-icon proposal is already a lot better than anything X11 ever had. Relaxing ACK requirements for the ext namespace is also a good proposed administrative change, as it allows some compositors to add features they want to support to the shared repository easier, while also not mandating them for others. In my opinion, it would allow for a lot less friction between the two different ideas of how Wayland protocol development should work. Some compositors could move forward and support more protocol extensions, while more restrictive compositors could support less things. Applications can detect supported protocols at launch and change their behavior accordingly (ideally even abstracted by toolkits).

You may now say that a lot of apps are ported, so surely this issue can not be that bad. And yes, what Wayland provides today may be enough for 80-90% of all apps. But what I hope the detour into the research lab has done is convince you that this smaller percentage of apps matters. A lot. And that it may be worthwhile to support them.

To end on a positive note: When it came to porting concrete apps over to Wayland, the only real showstoppers so far5 were the missing window-positioning and window-position-restore features. I encountered them when porting my own software, and I got the issue as feedback from colleagues and fellow engineers. In second place was UI testing and automation support, the window-icon issue was mentioned twice, but being a cosmetic issue it likely simply hurts people less and they can ignore it easier.

What this means is that the majority of apps are already fine, and many others are very, very close! A Wayland future for everyone is within our grasp!

I will also bring my two protocol MRs to their conclusion for sure, because as application developers we need clarity on what the platform (either all desktops or even just a few) supports and will or will not support in future. And the only way to get something good done is by contribution and friendly discussion.

Footnotes

1. Apologies for the clickbait-y title – it comes with the subject ︎
2. When I talk about “Wayland” I mean the combined set of display server protocols and accepted protocol extensions, unless otherwise clarified. ︎
3. I would have picked a picture from our lab, but that would have needed permission first ︎
4. Qt has awesome “platform issues” pages, like for macOS and Linux/X11 which help with porting efforts, but Qt doesn’t even list Linux/Wayland as supported platform. There is some information though, like window geometry peculiarities, which aren’t particularly helpful when porting (but still essential to know). ︎
5. Besides issues with Nvidia hardware – CUDA for simulations and machine-learning is pretty much everywhere, so Nvidia cards are common, which causes trouble on Wayland still. It is improving though. ︎

KTextAddons is a library with Various text handling addons used by Ruqola and Kontact apps. It can be compiles for both Qt 5 and 6 and distros are advised to compile two builds for each until Ruqola is ported to Qt 6.

URL: https://download.kde.org/stable/ktextaddons/

SHA256: 8a52db8abfa8a9d68d2d291fb0f8be20659fd7899987b4dcafdf2468db0917dc

Changelog

• Drop unused KXmlGui dependency
• Adapt to new KConfigGroup API
• As we exclude emojis we need to remove it from list and not exclude it
• Use proxymodel when exclude emoticons were updated
• Allow to exclude some specific emoticons (Need for ruqola)
• Exclude mock engine => it’s for test
• Remove generate pri support (removed in kf6)

Plasma 6, Frameworks and Gear draw closer

Every few years we port the key components of our software to a new version of Qt, taking the opportunity to remove cruft and leverage the updated features the most recent version of Qt has to offer us.

KDE's megarelease is less than 50 days away. At the end of February 2024 we will publish Plasma 6, Frameworks 6, and a whole new set of applications in a special edition of KDE Gear all in one go.

If you have been following the updates here, here and here, you will know we are making our way through the testing phase and gradually reaching stability. KDE is making available today the first Release Candidate version of all the software we will include in the megarelease.

As with the Alpha and Beta versions, this is a preview intended for developers and testers. The software provided is nearing stability, but is still not 100% safe to use in a production environment. We still recommend you continue using stable versions of Plasma, Frameworks and apps for your everyday work. But if you do use this, watch out for bugs and report them promptly, so we can solve them.

Read on to find out more about KDE's 6th Megarelease, what it covers, and how you can help make the new versions of Plasma, KDE's apps and Frameworks a success now.

Plasma

Plasma is KDE's flagship desktop environment. Plasma is like Windows or macOS, but is renowned for being flexible, powerful, lightweight and configurable. It can be used at home, at work, for schools and research.

Plasma 6 is the upcoming version of Plasma that integrates the latest version of Qt, Qt 6, the framework upon which Plasma is built.

Plasma 6 incorporates new technologies from Qt and other constantly evolving tools, providing new features, better support for the latest hardware, and supports for the hardware and software technologies to come.

You can be part of the new Plasma. Download and install a Plasma 6-powered distribution (like Neon Unstable) to a test machine and start trying all its features. Check the Contributing section below to find out how you can deliver reports of what you find to the developers.

• Plasma 6 RC 1 Source Code Info Page
• Plasma 6 RC 1 Full Changelog
• Plasma 6 packagers' release notes

KDE Gear

KDE Gear is a collection of applications produced by the KDE community. Gear includes file explorers, music and video players, text and video-editors, apps to manage social media and chats, email and calendaring applications, travel assistants, and much more.

Developers of these apps also rely on the Qt toolbox, so most of the software will also be adapted to use the new Qt6 toolset and we need you to help us test them too.

• KDE Gear 24.02 RC 1 Source Code Info Page
• KDE Gear 24.02 RC 1 Full Changelog
• KDE Gear 24.02 packagers' release notes

Frameworks

KDE's Frameworks add tools created by the KDE community on top of those provided by the Qt toolbox. These tools give developers more and easier ways of developing interfaces and functionality that work on more platforms.

Among many other things, KDE Frameworks provide

• widgets (buttons, text boxes, etc.) that make building your apps easier and their looks more consistent across platforms, including Windows, Linux, Android and macOS
• libraries that facilitate storing and retrieving configuration settings
• icon sets, or technologies that make the integration of the translation workflow of applications easier

KDE's Frameworks also rely heavily on Qt and will also be upgraded to adapt them to the new version 6. This change will add more features and tools, enable your applications to work on more devices, and give them a longer shelf life.

• KDE Frameworks 6 RC 1 Source Code Info Page
• KDE Frameworks 6 RC 1 Full Changelog
• KDE Frameworks 6 packagers release notes

Contributing

KDE relies on volunteers to create, test and maintain its software. You can help too by...

• Reporting bugs -- When you come across a bug when testing the software included in this Alpha Megarelease, you can report it so developers can work on it and remove it. When reporting a bug
  • make sure you understand when the bug is triggered so you can give developers a guide on how to check it for themselves
  • check you are using the latest version of the software you are testing, just in case the bug has been solved in the meantime
  • go to KDE's bug-tracker and search for your bug to make sure it does not get reported twice
  • if no-one has reported the bug yet, fill in the bug report, giving all the details you think are significant.
  • keep tabs on the report, just in case developers need more details.
• Solving bugs -- Many bugs are easy to solve. Some just require changing a version number or tweaking the name of a library to its new name. If you have some basic programming knowledge of C++ and Qt, you too can help carry the weight of debugging KDE's software for the grand release in February.
• Joining the development effort -- You may have a deeper knowledge development, and would like to contribute to KDE with your own solutions. This is the perfect moment to get involved in KDE and contribute with your own code.
• Donating to KDE -- Creating, debugging and maintaining the large catalogue of software KDE distributes to users requires a lot of resources, many of which cost money. Donating to KDE helps keep the day-to-day operation of KDE running smoothly and allows developers to concentrate on creating great software. KDE is currently running a drive to encourage more people to become contributing supporters, but you can also give one-time donations if you want.

A note on pre-release software

Pre-release software is only suited for developers and testers. Alpha/Beta/RC software is unfinished, will be unstable and will contain bugs. It is published so volunteers can trial-run it, identify its problems, and report them so they can be solved before the publication of the final product.

The risks of running pre-release software are many. Apart from the hit to productivity produced by instability and the lack of features, using pre-release software can lead to data loss, and, in extreme cases, damage to hardware. That said, the latter is highly unlikely in the case of KDE software.

The version of the software included in KDE's 6th Megarelease is beta software. We strongly recommend you do not use it as your daily driver.

If, despite the above, you want to try the software distributed in KDE's 6th Megarelease, you do so under your sole responsibility, and in the understanding that the main aim, as a tester, you help us by providing feedback and your know-how regarding the software. Please see the Contributing section above.

The Qt for Android plugin, introduced more than a decade ago, has been a game-changing change that opened a multitude of possibilities for developers looking to harness the power and flexibility of Qt for Android application development. Since then, many Android, Qt, and plugin changes have been made to support new features. However, neither the overall architecture nor the public Java bindings have changed much. These bindings contain wrappers for the Android Activity. It is about time we did that! 

I took some time last week to work on these icons some more. Here are the results:

KDiagram 3.0.1 is an update to our charting libraries which fixes a bug in the cmake path configuration. It also updates translations and removes some unused Qt 5 code.

URL: https://download.kde.org/stable/kdiagram/3.0.1/

sha256: 4659b0c2cd9db18143f5abd9c806091c3aab6abc1a956bbf82815ab3d3189c6d

Signed by E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell jr@jriddell.org
https://jriddell.org/esk-riddell.gpg

‘Chingam’/ചിങ്ങം (named after the first month of Malayalam calendar) is the newest libre/open source font released by Rachana Institute of Typography in the year 2024.

It comes with a regular variant, embellished with stylistic alternates for a number of characters. The default shape of characters D, O, ഠ, ാ etc. are wider in stark contrast with the shape of other characters designed as narrow width. The font contains alternate shapes for these characters more in line with the general narrow width characteristic.

Users can enable the stylistic alternates in typesetting systems, should they wish.

• XeTeX: stylistic variant can be enabled with the StylisticSet={1} option when defining the font via fontspec package. For e.g.

% in the preamble
\newfontfamily\chingam[Ligatures=TeX,Script=Malayalam,StylisticSet={1}]{Chingam}
…
\begin{document}
\chingam{മനുഷ്യരെല്ലാവരും തുല്യാവകാശങ്ങളോടും അന്തസ്സോടും സ്വാതന്ത്ര്യത്തോടുംകൂടി ജനിച്ചിട്ടുള്ളവരാണ്‌…}
\end{document}

• Scribus: extra font features are accessible since version 1.6

• LibreOffice: extra font features are accessible since version 7.4. Enable it using Format→Character→Language→Features.

• InDesign: very similar to Scribus; there should be an option in the text/font properties to choose the stylistic set.

Development

Chingam is designed and drawn by Narayana Bhattathiri. Based on the initial drawings on paper, the glyph shapes are created in vector format (svg) following the glyph naming convention used in RIT projects. A new build script is developed by Rajeesh that makes it easier for designers to iterate & adjust the font metadata & metrics. Review & scrutiny done by CVR, Hussain KH and Ashok Kumar improved the font substantially.

Download

Chingam is licensed under Open Font License. The font can be downloaded from Rachana website, sources are available in GitLab page.

Here's our bi-monthly update from KDE's personal information management applications team. This report covers progress made in the months of November and December 2023.

Since the last report, 35 people contributed approximately 1500 code changes, focusing on bugfixes and improvements for the coming 24.02 release based on Qt6.

Transition to Qt6/KDE Frameworks 6

As we plan for KDE Gear 24.02 to be our first Qt6-based release, there's been on-going work on more Qt6 porting, removing deprecated functions, removing support for the qmake build system, and so on.

New feature

Kontact, KMail, KAddressBook and Sieve Editor will now warn you when you are running an unsuported version of KDE PIM and it is time to update it. The code for this is based on Kdenlive.

Itinerary

While the focus for Itinerary was also on completing the transition to Qt 6, with its nightly Android builds switching over a week ago, there also were a number of new features added, such as public transport arrival search, a new journey display in the timeline and a nearby amenity search. See Itinerary's bi-monthly status update for more details.

KOrganizer

In KOrganizer it is no possible to search for events without specifying a time range (BKO#394967). A new configuration option was added to only notify about events that the user is organizer or attendee of. This is especially useful when users add a shared calendar from their colleagues, but don't want to be notified about events that they do not participate in. Korganizer intercepts SIGINT/SIGTERM signal. It will avoid to lose data during editing.

Akonadi

Work has begun on creating a tool that would help users to migrate their Akonadi database to a different database engine. Since we started improving SQLite support in Akonadi during the year, we received many requests from users about how they can easily switch from MySQL or PostgreSQL to SQLite without having to wipe their entire configuration and setup everything from scratch with SQLite. With the database migrator tool, it will be very easy for users to migrate between the supported database engines without having to re-configure and re-sync all their accounts afterwards.

Dan's work on this tool is funded by g10 Code GmbH.

KMail

The email composer received some small visual changes and adopted a more frameless look similar to other KDE applications. In addition, the composer will directly display whether the openPGP key of a recipient exists and is valid when encryption is enabled.

The rust based adblocker received further work and adblock lists can be added or removed.

We removed changing the charset of a message and now only support sending emails as UTF-8. This is nowaday supported by all the other email clients. But we still support reading emails in other encoding.

Now kmail intercepts SIGINT/SIGTERM signal. It avoids to close by error KMail during editing.

Laurent finished to implement the "allow to reopen closed viewer" feature. This provides a menu which allows to reopen message closed by error.

In addition a lot of bugs were fixed. This includes:

• Fix bug 478352: Status bar has "white box" UI artifact (BKO#478352).
• Load on demand specific widget in viewer. Reduce memory foot.
• Fix mailfilter agent connection with kmail (fix apply filters)

A lot of work was done to rewrite the account wizard in QML. Accounts can now be created manually.

KAddressBook

Bug 478636 was fixed. Postal addresses was ruined when we added address in contact. (BKO#478636). Now KAddressbook intercepts SIGINT/SIGTERM signal. It avoids to close by error it during editing contact.

Kleopatra

Development focussed on fixing bugs for the release of GnuPG VS-Desktop® (which includes Kleopatra) in December.

• OpenPGP keys with valid primary key and expired encryption or signing subkeys are now handled correctly (T6788).
• Key groups containing expired keys are now handled correctly (T6742).
• The currently selected certificate in the certificate list stays selected when opening the certificate details or certifying the certificate (T6360).
• When creating an encrypted archive fails or is aborted, then Kleopatra makes sure that no partially created archive is left over (T6584).
• Certificates on certain smart cards are now listed even if some of the certificates couldn't be loaded (T6830).
• The root of a certificate chain with two certificates is no longer shown twice (T6807).
• A crash when deleting a certificate that is part of a certificate chains with cycles was fixed (T6602).
• Kleopatra now supports the special keyserver value "none" to disable keyserver lookups (T6761).
• Kleopatra looks up a key for an email address via WKD (key directory provided by an email domain owner) even if keyserver lookups are disabled (T6868).
• Signing and encryption of large files is now much faster (especially on Windows where it was much slower than on Linux) (T6351).

pim-sieve-editor

2 bugs were fixed in sieveeditor:

• Fix BUG: 477755: Fix script name (BKO#477755).
• Fix bug 476456: No scrollbar in simple editing mode (BKO#476456).

Now sieveeditor intercepts SIGINT/SIGTERM signal. It avoids to close by error it during editing sieve script.

pim-data-exporter

Now it intercepts SIGINT/SIGTERM signal. It avoids to close application during import/export.

A week has passed since I attended the 37th Chaos Communication Congress (37C3) in Hamburg, Germany, together with a bunch of other KDE people.

KDE Assembly

For the first time KDE had a larger presence, with a number of people and our own assembly. We also ended up hosting the Linux on Mobile assembly as their originally intended space didn’t materialize. The extra space demand was compensated by assimilating neighbouring tables of a group that didn’t show up for the most part.

KDE assembly featuring the event-typical colorful LEDs and sticker piles (photo by Victoria).

Just for the logistical convenience of having a meeting point and a place to store your stuff alone this was a big help, and it also made a number of people find us that we’d otherwise probably wouldn’t have met.

Talks

There was one KDE talk in the main program, Joseph’s Software Licensing For A Circular Economy covering some of the KDE Eco work. I’d estimate about 500 attendees, despite the “early” morning slot.

Beyond that I actually managed to attend very few talks, Breaking “DRM” in Polish trains being clearly one of my favorites.

Emergency and Weather Alerts

I got a chance to meet the author of FOSS Warn. FOSS Warn is a free alternative to the proprietary emergency and weather alert apps in Germany. That topic had originally motivated my work on UnifiedPush support for KDE, and an emergency and weather alert service that allows subscribing to areas of interest and receiving push notifications for new alerts, covering almost 100 countries.

The latter is a proof of concept demo at best though. The idea is to collaborate with the FOSS Warn team on a joint backend implementation, evolving this into something production-ready and usable for all of us.

While there’s still a couple of technicalities to resolve, after having met in person I’m very confident that this will all work out.

Open Transport Community

Other groups I’m involved with were present at 37C3 as well, like the Open Transport community, with the Bahnbubble Meetup being the event that brought everyone together.

Discussion topics included:

• Identifying and getting access to missing data tables and documentations for DB and VDV ticket barcodes.
• Helping others with implementing the ERA FCB ticket format.
• Evolving the Transport API Repository.
• International collaboration and networking between the Open Transport communities in Europe,
• Integration between Itinerary and Träwelling.
• Train station identifiers in Wikidata, including a recent property proposal for DB station numbers, as well as a yet to be written one for IFOPT identifiers.

Many more topics ended up being discussed in parallel, overall I’d say there’s more than enough content and interested people for its own dedicated event/conference on this. Until somebody organizes that there’s the open-transport Matrix channel and the Railways and Open Transport track at FOSDEM.

Indoor Localization and Routing

The OSM community was at 37C3 as well of course, and in that context I got one of the probably most unexpected contacts, by meeting one of the authors of simpleLoc. That’s an indoor navigation solution, which is one of the big open challenges in our indoor map view used in Itinerary.

Like other such solutions it’s unfortunately not fully available as Free Software, but the available information, components and published papers nevertheless turned out very valuable, in particular since this is using a localization approach that requires only commonly available smartphone sensors.

Much more immediately applicable were the hints on how they implemented indoor routing. Unlike for “outdoor” navigation graph-based algorithms are usually not an option, we need something that works on polygons in order to use OSM data as input directly. Existing solutions I encountered for that in a mapping/geography context were all proprietary unfortunately, but there’s a free library that solves that problem for 3D game engines: Recast Navigation.

While I’m not entirely sure yet how to map all relevant details to that (e.g. directional paths for escalators, tactile paving guides, etc), the initial experiments look very promising.

Routing through a complex indoor corridor.

There’s obviously a ton of work left, as this essentially requires mapping all relevant bits of OSM indoor data to a 3D model, and that’s at the very limit of what can be extracted from the OSM data and data model in many places.

KDE Outreach

While people working on technology make up a significant part of the audience of 37C3, there’s many more people from other areas attending as well, so this also was an opportunity for a bit of user research, following the pattern of the kde.org/for pages.

KDE for activists

On the KDE for Activists page we focus a lot on tools for secure and self-hosted infrastructure. The need for that seems like a given or even a hard requirement for people in that field, not something that needs to be argued for (the event itself might provide a certain selection bias for that though).

What we however need to improve on is making this much more robust and easy to setup and manage for people that might not be familiar with all the technical details, jargon and abbreviations we expose them to. Even worse, that can pose the risk of making dangerous mistakes, up to causing people physical harm.

KDE for FOSS projects

Meeting other FOSS developers is also interesting, in particular those not well connected to our usual bubble. That’s often single person projects, some of them even quite successful ones. Around those KDE is then the odd outlier, due to our size and choice of tools/infrastructure (ie. not Github).

Topics that typically come up then are handling of finances, legal risks/liability, shortcomings of Github, moderation of communication channels, etc., all things far less painful from the perspective of someone under the umbrella of a big organization like KDE.

I think there’s some interesting discussions to be had on how widely we want to extend the KDE umbrella and how we want to promote that, what other umbrella organizations there are and whether there are still uncovered gaps between those, and how to manage the scope and governance of such umbrella organizations.

It’s probably also worth talking more about what we already have and do in that regard, it’s not even clear to everyone apparently that joining a larger organization is even an option.

KDE for public administration

We got questions for pointers to material/support for doing medium-sized Linux/Plasma deployments in public administration. This is unfortunately something we don’t have anywhere in a well structured form currently I think.

It would seem very useful to have, beyond a KDE focus even. There’s people on the inside fighting for this, and while the upcoming Windows 11 induced large-scale hardware obsolescence is working in our favor there, the increasingly pervasive use of MS Teams is making a migration to FOSS infrastructure and workspaces much harder.

Conclusion

I had very high expectations for this after the experience at 36C3, but by day 3 this had exceeded all of them. The extreme breadth of people there is just unmatched, coming from FOSS/Open Data/Open Hardware projects tiny to large, public administration and infrastructure, education/universities, funding organizations, politics and lobbying, civil/social initiatives, you name it.

And all of that in a fun atmosphere that never stops to amaze. While walking down a corridor you might find yourself overtaken by a person driving a motorized couch, and if you have an urgent need for an electron microscope for whatever reason someone over in the other hall brought one just in case. And all of that is just “normal”, I could fill this entire post with anecdotes like that.

Ideas and plans for 38C3 were already discussed :)

Let’s go for my web review for the week 2024-01. First one of 2024, Happy New Year to all!

In 2024, please switch to Firefox – Roy Tanck

Tags: tech, mozilla, foss, web

Alright, it’s 2024… Looking for a New Year Resolution? This is definitely the one you should contemplate! Maybe also prepare your switch to Plasma 6, but different story. 😉

https://roytanck.com/2023/12/23/in-2024-please-switch-to-firefox/

 The Internet Is About to Get Weird Again

Tags: tech, web, culture, social-media

Very inspiring article. I really wish we’ll indeed see more and more weird and creative websites. People apparently feels uneasy in their current social media jails, the time is ripe to leap in the unknown again.

https://www.rollingstone.com/culture/culture-commentary/internet-future-about-to-get-weird-1234938403/

EU CRA: What does it mean for open source? - Bert Hubert’s writings

Tags: tech, foss, law

The current compromise might not be as bad as anticipated. Some things could be improved still. The community needs to be involved in the process.

https://berthub.eu/articles/posts/eu-cra-what-does-it-mean-for-open-source/

Birb + Fossil: An RSS Revival? - Tim Kellogg

Tags: tech, fediverse, rss, ai, nlp

Indeed there are a few trends at play right now which lead to RSS being in use again. I can only hope it’ll keep growing.

https://timkellogg.me/blog/2024/01/03/birb

How bad are search results? Let’s compare Google, Bing, Marginalia, Kagi, Mwmbl, and ChatGPT

Tags: tech, search, web

This looks like now is the time for smaller search engines to shine. Clearly the dominant ones are not doing a really good job anymore.

https://danluu.com/seo-spam/

Tesla blamed drivers for failures of parts it long knew were defective

Tags: tech, tesla, automotive, safety

The results of this investigation are actually super scary… Even if you don’t own one, those are in our streets. In any case it is a clear statement that you can’t and shall not run an automotive company like a startup…

https://www.reuters.com/investigates/special-report/tesla-musk-steering-suspension/

The I in LLM stands for intelligence | daniel.haxx.se

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

When bug bounty programs meet LLM hallucinations… developer time is wasted.

https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/

How I forked SteamOS for my living room PC — iliana.fyi

Tags: tech, valve, foss, linux, system

Funny reverse engineering of the latest SteamOS to use it in a different context. Give some information on their system design.

https://iliana.fyi/blog/build-your-own-steamos-updates/

Why I’m skeptical of low-code - Nick Scialli | Senior Software Engineer

Tags: tech, low-code

Proper word of caution. Those tools ain’t necessarily bad… but know what the limits will be.

https://nick.scialli.me/blog/why-im-skeptical-of-low-code/

How Standard Ebooks serves millions of requests per month with a 2GB VPS; or, a paean to the classic web - Alex Cabal

Tags: tech, complexity, craftsmanship, dependencies, php, web

Nice ode to simplifying web projects, to great effects. You can go a long way serving millions of requests if you choose your tools properly.

https://alexcabal.com/posts/standard-ebooks-and-classic-web-tech

A Closer Look to a Key-Value Storage Engine | Yihang’s Blog

Tags: tech, system, design, architecture, databases

Very interesting exploration of the design choices behind the creation of a key value storage engine.

https://silhding.github.io/2021/08/20/A-Closer-Look-to-a-Key-Value-Storage-Engine/

SQLALchemy vs Django ORM | Alexey Evseev

Tags: tech, databases, python, orm, django

Overview of the differences in behavior between the two most popular ORMs in the Python ecosystem. This shows interesting different design options for such things.

https://st4lk.github.io/en/blog/2023/12/09/sqlalchemy-vs-django-orm/

The ugrep file pattern searcher

Tags: tech, tools, command-line

Looks like another nice grep alternative. This one keeps its command line interface compatible with grep which is nice, not the case for other alternatives and that turns out to be my main gripe with them.

https://ugrep.com/

Container to WASM converter

Tags: tech, docker, webassembly

This makes for quite a few emulation layers stacked on each other. Still this is an interesting experiment.

https://github.com/ktock/container2wasm

Profilerpedia

Tags: tech, profiling

Nice reference for the tools available to profile software.

https://profilerpedia.markhansen.co.nz/

Occupancy explained

Tags: tech, amd, gpu, shader, performance

A very precise and thorough article about GPU occupancy. What it is, how it relates to perceived performances, it’s potentisl relationship with cache thrashing and the tools you can use to measure it on AMD GPUs.

https://gpuopen.com/learn/occupancy-explained/

Speed up your code: don’t pass structs bigger than 16 bytes on AMD64 · GitHub

Tags: tech, c++, assembly, performance

Not necessarily a practical advice in most of our daily code. Still this exhibits interesting low level details about argument passing. Might come in handy in a few cases, to be kept in mind.

https://gist.github.com/FeepingCreature/5dff669aad380a123b15659e195fb96c

Ambient Co-presence

Tags: tech, web, design

Good food for thought regarding shared presence on the web. A few good ideas in the design space. Obviously very web centric, I wonder what we could do on the desktop with shared documents for instance.

https://maggieappleton.com/ambient-copresence

The value of canonicity - Building Nubank

Tags: tech, engineering, management, developer-experience

Nice writeup about the benefits of homogeneity in an engineering organization. It also shows how it is a balancing act though, since you need experiments to happen in a controlled way for evolution to still happen.

https://building.nubank.com.br/the-value-of-canonicity/

Bye for now!

Ramon Miranda has published a new video on the Krita channel: Krita 5.2 Features. Take a look and learn what’s new in our latest release:

 

 

The post New Video: Krita 5.2 Features! appeared first on Krita.

Hi all,

I made a couple of videos explaining more updates for Breeze icons. Enjoy!

I have now been playing games only on Linux for a year, and it has been great.

With the GPU shortage, I had been waiting for prices to come back to reasonable levels before buying a new GPU. So far, I had always bought NVIDIA GPUs as I was using Windows to run games and the NVIDIA drivers had a better “reputation” than the AMD/Radeon ones.

With Valve’s Proton seriously taking off thanks to the Steam Deck, I wanted to get rid of the last computer in the house that was running Microsoft Windows, that I had kept only for gaming.

But the NVIDIA drivers story on Linux had never been great, especially on distributions that move kernel versions quickly to follow upstream releases like Fedora. I had tried using the NVIDIA binary drivers on Fedora Kinoite but quickly ran into some of the issues that we have listed in the docs.

At the time, the Universal Blue project did not exist yet (Jorge Castro started it a bit later in the year), otherwise I would have probably used that instead. If you need NVIDIA support today on Fedora Atomic Desktops (Silverblue, Kinoite, etc.), I heavily recommend using the Universal Blue images.

Hopefully this will be better in the future for NVIDIA users with the work on NVK

So, at the beginning of last year (January 2023), I finally decided to buy an AMD Radeon RX 6700 XT GPU card.

What a delight. Nothing to setup, fully supported out of the box, works perfectly on Wayland. Valve’s Proton does wonders. I can now play on my Linux box all the games that I used to play on Windows and they run perfectly. Just from last year, I played Age of Wonders 4 and Baldur’s Gate 3 without any major issue, and did it pretty close to the launch dates. Older titles usually work fairly well too.

Sure, some games require some little tweaks, but it is nothing compared to the horrors of managing a Windows machine. And some games require tweaks on Windows as well (looking at you Cyberpunk 2077). The best experience is definitely with games bought on Steam which usually work out of the box. For those where it is not the case, protondb is usually a good source to find the tweaks needed to make the games work. I try to keep the list of tweaks I use for the games that I play updated on my profile there.

I am running all of this on Fedora Kinoite with the Steam Flatpak. If you want a more console-like or Steam Deck-like experience on your existing computers, I recommend checking out the great work from the Bazzite team.

Besides Steam, I use Bottles, Cartridge and Heroic Games Launcher as needed (all as Flatpaks). I have not looked at Origins or Uplay/Ubisoft Connect games yet.

According to protondb, the only games from my entire Steam library that are not supported are mostly multiplayer games that require some specific anti-cheat that is only compatible with Windows.

I would like to say a big THANK YOU to all the open source graphics and desktop developers out there and to (in alphabetical order) AMD, Collabora, Igalia, Red Hat, Valve, and other companies for employing people or funding the work that makes gaming on Linux a reality.

Happy new year and happy gaming on Linux!

Cleaning up KDE's metadata – the little things matter too

Lots of my KDE contributions revolve around plugin code and their metadata, meaning I have a good overview of where and how metadata is used. In this post, I will highlight some recent changes and show you how to utilize them in your Plasma Applets and KRunner plugins!

Applet and Containment metadata

Applets (or Widgets) are one of Plasma's main selling points regarding customizability. Next to user-visible information like the name, description and categories, there is a need for some technical metadata properties. This includes X-Plasma-API-Minimum-Version for the compatible versions, the ID and the package structure, which should always be “Plasma/Applet”.

For integrating with the system tray, applets had to specify the X-Plasma-NotificationArea and X-Plasma-NotificationAreaCategory properties. The first one says that it may be shown in the system tray and the second one says in which category it belongs. But since we don't want any applets without categories in there, the first value is redundant and may be omitted! Also, it was treated like a boolean value, but only "true" or "false" were expected. I stumbled upon this when correcting the types in metadata files.
This was noticed due to preparations for improving the JSON linting we have in KDE. I will resume working on it and might also blog about it :).

What most applets in KDE specify is X-KDE-MainScript, which determines the entrypoint of the applet. This is usually “ui/main.qml”, but in some cases the value differs. When working with applets, it is confusing to first have to look at the metadata in order to find the correct file. This key was removed in Plasma6 and the file is always ui/main.qml. Since this was the default value for the property, you may even omit it for Plasma5.
The same filename convention is also enforced for QML config modules (KCMs).

What all applets needed to specify was X-Plasma-API. This is typically set to "declarativeappletscript", but we de facto never used its value, but enforced it being present. This was historically needed because in Plasma4, applets could be written in other scripting languages. From Plasma6 onward, you may omit this key.

In the Plasma repositories, this allowed me to clean up over 200 lines of JSON data.

metadata.desktop files of Plasma5 addons

Just in case you were wondering: We have migrated from metadata.desktop files to only metadata.json files in Plasma6. This makes providing metadata more consistent and efficient. In case your projects still use the old format, you can run desktoptojson -i pathto/metadata.desktop and remove the file afterward.
See https://develop.kde.org/docs/plasma/widget/properties/#kpackagestructure for more detailed information. You can even do the conversion when targeting Plasma5 users!

Default object path for KRunner DBus plugins

Another nice addition is that “/runner” will now be the default object path. This means you can omit this one key. Check out the template to get started: https://invent.kde.org/frameworks/krunner/-/tree/master/templates/runner6python. DBus-Runners that worked without deprecations in Plasma5 will continue to do so in Plasma6! For C++ plugins, I will make a porting guide like blog post soonish, because I have started porting my own plugins to work with Plasma6.

Finally, I want to wish you all a happy and productive new year!

Tellico 3.5.3 is available, with a few minor clean-ups.

Improvements and Bug Fixes

• Improved some entry matching heuristics when updating from other sources.
• Updated the author search for the Open Library data source.
• Updated Kino-Teatr data source.
• Fixed compilation for versions of KDE Frameworks < 5.94.
• Fixed layout bug in Fancy template for custom collections with no image.

A few weeks ago, right before the holidays, some chatter in the VDG channel happened where the desire to change our icons to a 24x24px size came up.

Most modern interfaces use this icon size as a base. Plasma has been encouraged many times to adopt this size. However, manpower is always something not readily available.

The conversation picked my interest. In the past, I have worked making icons using Inkscape. At the time, the interface didn’t have all the shortcut helpers that it does today. Also, with the advent of UI-specific graphical applications like Figma and Penpot, I figured it might be much easier to edit icons today than in the past. I am talking many years, FYI.

With this in mind, I downloaded a copy of the most current Breeze icon collection, accessed the 22px folder for actions and begun editing.

At first sight, most might think this is just a matter of mass-resizing from 22 to 24 and merge. However, the reality is much different. These icons feature mostly 1px lines. They also contain pixel fractions that lead to misalignment and blurriness. Since we don’t have the actual graphical original files, as they have been flattened in export, the shapes are only workable through editing nodes, which is a pain!

Another issue is that our Breeze icons contain a css sheet that correlates colors to colors in Plasma. This allows for easy color transformations on the system without much hassle. However, graphical applications like Figma and Penpot remove the css.

For this reason @manuelijin created a nice plugin for Figma called Icon Jetpack. This plugin will allow designers to export the updated icons with all the necessary pieces for production.

In the public Figma file, I created the colors needed for action icons and they are now embedded into the exported file.

Another criticism of our current icons we would like to address is how thin they feel in high-DPI screens. To address this, we have been making our lines 2px (for the most part) where it makes sense.

Given this is an update, and who knows how long it will take for another time when an update is done, I also feel it’s necessary to update many of the shapes we have. We are using rounding for making shapes a little more approachable. Some icons have been transformed inspired by the original files. For other files, I usually check on other icon providers to see how different or similar we are to most icons today. That way, if there is a need for more editing, we can land on something recognizable.

The editing process that seems the fastest involves recreating the shapes, using an icon grid, aligning to the grid as much as possible, reusing icons for consistency. This should help future designers consult the Figma file and edit en-masse.

For now, we are in the middle of editing icons. My intention is that we do a first pass and seek feedback. Do another refinement pass and then see how the community reacts to the edits. Hopefully the work is useful and can be merged eventually.

We have a total of 1206 icons. So far, we have edited 262.

Here is a before/after:

There are some more edits at the bottom of the file that I didn’t include.

Hope you like.

I also made a couple of videos to show the process and see if any other designers would like to contribute some time to update the icons.

This is a lighter month due to holidays (and also I’m trying not to burn out), but I tried to fit in a bit of KDE anyway. It’s all bugfixes anyway because of the feature freeze!

Not mentioned is a bunch of really boring busywork like unbreaking the stable branches of Gear applications due to the CI format changing.

Tokodon #

Bugfix Fixed a bunch of papercuts with the Android build, and the new nightlies should be appearing in the F-Droid repository soon! It’s mostly adding missing icons and making sure it looks good in qqc2-breeze-style (the style we use on Android and Plasma Mobile.) 24.02

Bugfix Fixed Akkoma and Pleroma tags not being detected correctly, they should open in Tokodon instead of your web browser again! 24.02

Plasma #

Bugfix KScreenLocker CI now runs supported tests, see the KillTest fixes and pamTest fix. Failing tests also make the pipeline visibly fail, as it should. (Unfortunately, the pipeline as of writing fails to due some unrelated regression?) 6.0

Bugfix The lockscreen greeter now handles even the fallback theme failing, and display the “please unlock using loginctl” message instead of a black screen. 6.0

Bugfix Improves the QtQuickControls style selection mechanism to work around a possible regression in Qt6. This should stop applications from mysteriously not opening in the rare (but unsupported) cases where our official styles aren’t installed/loading. 6.0

Kirigami #

Bugfix Fixed a bunch of TextArea bugs that affected mobile form factors, such as Plasma Mobile and Android. This is mostly for Tokodon (because we abuse TextAreas a lot in scrolling content) but it can help other applications too! The selectByMouse property is now respected, the cursor handles should show up less. 6.0

Bugfix Invisible MenuItems in qqc2-breeze-style are collapsed like in qqc2-desktop-style. Mobile applications should no longer have elongated menus with lots of blank space! 6.0

Bugfix You can finally right-click with a touchpad in qqc2-desktop-style TextFields again! This bug has been driving me up a wall when testing our Qt6 stuff. 6.0

Feature When the Kirigami theme plugin fails to load, the error message will soon be a bit more descriptive. This should make it easier for non-developers to figure out why Kirigami applications don’t look correct. 6.0

Android #

Bugfix Fixed KWeather not launching on Android because it needed QApplication. I didn’t know QtCharts is QWidgets-based! 24.02

I also went around and fixed up a bunch of other mobile applications with Android contributions too small to mention. Applications like Qrca, Kongress, etc.

NeoChat #

Bugfix Prevent the NeoChat notification daemon from sticking around forever although that should rarely happen. 24.02

Outside of KDE #

Nagged for a new QtKeychain release due to a critical bug that would cause applications to never open KWallet5. Please also nag your distributions to package 0.14.2 soon! Anything using QtKeychain 0.14.1 or below won’t work in Plasma 6. This doesn’t affect people in the dev session, because QtKeychain should be built from git.

Helping the Gentoo KDE Team with packaging Plasma 6 and KDE Gear 6. I managed to update my desktop to Plasma 6 and submitted fixes to get it closer to working. I also added Arianna, PlasmaTube and MpvQt packages.

My work in KDE for November 2023

My Work in KDE

Home

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

Drivers of social influence in the Twitter migration to Mastodon | Scientific Reports

Tags: tech, social-media, sociology, psychology, community, fediverse, twitter

Despite understandable limitations, this studies has a few interesting findings on how communities can more easily switch platforms (in this case from Twitter to Mastodon). At least one is a bit counter-intuitive.

https://www.nature.com/articles/s41598-023-48200-7

Substack says it will not remove or demonetize Nazi content - The Verge

Tags: tech, moderation, social-media

Another platform failing at proper moderation…

https://www.theverge.com/2023/12/21/24011232/substack-nazi-moderation-demonetization-hamish-mckenzie

How Big is YouTube? - Ethan Zuckerman

Tags: tech, social-media, google, research

An important question for proper statistics about the content itself. Surprisingly harder to get an answer to it than one would think.

https://ethanzuckerman.com/2023/12/22/how-big-is-youtube/

The New York Times sues OpenAI and Microsoft for copyright infringement - The Verge

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

It was only a question of time until we’d see such lawsuits appear. We’ll see where this one goes.

https://www.theverge.com/2023/12/27/24016212/new-york-times-openai-microsoft-lawsuit-copyright-infringement

The growing energy footprint of artificial intelligence - ScienceDirect

Tags: tech, ai, machine-learning, gpt, economics, energy, ecology

Very interesting paper about the energy footprint of the latest trend in generator models. The conclusion is fairly clear: we should think twice before using them.

https://www.sciencedirect.com/science/article/pii/S2542435123003653#fig1

More than calculators: Why large language models threaten learning, teaching, and education | by Amy J. Ko | Bits and Behavior | Dec, 2023 | Medium

Tags: tech, ai, machine-learning, gpt, school, learning, education

When underfunded schools systems preaching obedience and conformity meet something like large language models, this tips over the balance enough that no proper learning can really happen anymore. Time to reform our school systems?

https://medium.com/bits-and-behavior/more-than-calculators-why-large-language-models-threaten-public-education-480dd5300939

You don’t need analytics on your blog

Tags: tech, blog, self-hosting, attention-economy

Definitely true… never had use for more than the server logs for understanding the traffic on my blog. No need to invade the privacy of people through their browser.

https://blog.yossarian.net/2023/12/24/You-dont-need-analytics-on-your-blog

Using Qt for Mobile in 2023 | Cameron Gaertner | Software Developer

Tags: tech, mobile, qt, android, ios

The experience is still not great on iOS and Android. This is in part due to the platforms design though, this still make Qt a great fit when you control the platform like for Plasma Mobile. For less friendly platforms this still limits the use to cases where you already have quite some Qt code. Still the same situation than a few years ago.

https://camg.me/qt-mobile-2023/

To Type or Not to Type: Quantifying Detectable Bugs in JavaScript

Tags: tech, javascript, type-systems, bug, quality

Interesting study, the amount of bugs which could have been prevented by the introduction of static typing in Javascript code bases is definitely impressive (15% is not a small amount in my opinion).

https://discovery.ucl.ac.uk/id/eprint/10064729/1/typestudy.pdf

Why large companies and fast-moving startups are banning merge commits

Tags: tech, git, version-control

It looks like git workflows using rebase are becoming the norm. People are actively trying to avoid merge commits in their repository history. Tooling support could be a bit better though.

https://graphite.dev/blog/why-ban-merge-commits

rscss - Styling CSS without losing your sanity

Tags: tech, css

Interesting guidelines for organizing CSS. This should avoid making things too much of a mess.

https://ricostacruz.com/rscss/

How to (and how not to) fix color banding

Tags: tech, graphics

Exploration of the causes of color banding and how to work around them.

https://blog.frost.kiwi/GLSL-noise-and-radial-gradient/

So You Want to Optimize Your Code?

Tags: tech, mozilla, observability, telemetry, profiling, optimization, performance

Very nice collection of stories from the trenches of Firefox development. Lots of lessons learned to unpack about optimizing for the right thing, tooling, telemetry and so on.

https://yoric.github.io/post/so-you-want-to-optimize-your-code/

John the Toolmaker

Tags: tech, tools, craftsmanship, developer-experience

It’s indeed important to hone your tools as well. Even though most things are not blocked due to tools, the right ones when well designed can make things easier.

https://two-wrongs.com/john-the-toolmaker

On chains and complex systems – Surfing Complexity

Tags: tech, complexity, reliability

Word of caution on how we tend to reason about complex systems. They don’t form a chain but a web, and that changes everything to understand how they can break.

https://surfingcomplexity.blog/2023/12/23/on-chains-and-complex-systems/

Cold-blooded software

Tags: tech, dependencies, maintenance

This is an interesting metaphor. I’ll try to keep it in mind.

https://dubroy.com/blog/cold-blooded-software/

Beyond Technical Aspects How Do Community Smells Influence the Intensity of Code Smells?

Tags: tech, community, smells, organization, quality

This study does a good job looking at the impact of community smells over the presence of code smells. This is an excellent reminder that the organization influences greatly the produced code.

https://repository.tudelft.nl/islandora/object/uuid%3A426a340b-83a6-480b-bbac-0d711092c704/datastream/OBJ/download

The LinkedIn Developer Productivity and Happiness Framework

Tags: tech, linkedin, developer-experience, metrics, productivity

Interesting framework. I wouldn’t take everything at face value, but this looks like a good source of inspiration to design your own.

https://linkedin.github.io/dph-framework/

Explorers are bad leaders | Derek Sivers

Tags: tech, management, leadership

A bit too archetypal for my taste but there’s some truth to it. If you lean towards “explorer” (I think I do), it’s hard to be also a leader. Now you could be aware of your flaws and put tools in place to compensate for them when you need lead.

https://sive.rs/exled

Bye for now! And see you in 2024!

People who have visited any of the larger C++ conferences surely know Rainer Grimm, know his talks, workshops and books.

Rainer Grimm

Unfortunately, he has been diagnosed with ALS, a serious progressive nerve condition.

Since ALS research doesn’t get much attention or funding, Rainer started a fund raising campaign for funding ALS research with ALS-Ambulanz of the Charité and I Am ALS organization.

You can support my work on Patreon, or you can get my book Functional Programming in C++ at Manning if you're into that sort of thing. -->