Hello and welcome back to my blog! In this blog, I will be detailing the work I've done over the second coding period of my 2023 GSoC journey with KDE. Let's dive in!

Work done

Over the second coding period, I accomplished the following tasks:

Fix Okular Icon Rendering

Okular's Android app was not rendering the icons at all. At first, I thought that it might be an issue with the icons not being packaged. I tested out this theory, by exploring the contents of Okular's apk file. Inside the APK was a .qrc file, which I decompiled using a tool recommended to me in the KDE Android matrix room. Upon exploring the contents of the .qrc file, I found that all the icons were already packaged there. If I used the icons with their full paths in the qrc file instead of their freedesktop name (i.e. qrc:/path/to/document-open.svg instead of just document-open), the icon would show up properly in the app. I concluded that the issue was not due to faulty packaging of icons, but Kirigami not being able to find the proper icons.

Over the next week, I spent a large amount of time desperately trying to pick apart Okular and find the faulty bit of code that was causing the icons not to display. As I grew increasingly frustrated, I turned to the KDE android matrix room to ask for help.

They suggested that the KIconThemes library was causing issues just by being present, due to this line of code that executes any time the Okular app started up. What it does is, it automatically configures the app to use the breeze theme as a fallback. This was interfering with Kirigami's icon-finding mechanism, causing the icons to not show up.

Initially, I just removed KIconThemes as a dependency from Okular's CMakeLists.txt, but that didn't work. A couple of days later, several developers from the KDE Android matrix room pointed out that even though KIconThemes was removed, it was still being packaged with Okular by craft. They suggested that I wrap the offending code within a conditional compilation block so that Android would not execute it automatically.

I followed their advice, and it worked like a charm - Okular was finally displaying the icons properly.

I then created a Merge Request at the KIconThemes repository to implement the fix for the icons issue.

Peruse, another KDE application, was also having similar issues with icons as Okular. The fix also helped it to render icons properly.

Package Okular Icon

After fixing icon rendering, I added the Okular icon to the CMakeLists.txt for Okular's Android version, which would package it along with the other icons. This was needed because two places in the Okular app use icons:

• The global drawer

• The About Page

These places were empty when they should've been displaying the Okular logo, as can be seen here:

After adding the Okular icon to the kirigami_package_breeze_icons() array, you can now see the Okular icon in its glory in the global drawer and about page.

However, I did run into some footgun moments with craft while performing this task. This is because to test changes in Okular, I had always run the following craft commands to build and package it as an APK:

craft --compile okular
craft --package okular

However, icons are a special case. If you add a new icon, it has to be installed and qmerged as well. You do that by:

craft --compile --install --qmerge okular
craft --package okular

I spent a couple days trying to figure out what was wrong due to this small mistake. I only realized what was happening when I took a closer look at the output when freshly installing Okular using craft -i okular.

The members of the KDE Android Matrix room suggested that I edit the wiki page for Craft so that other people can avoid being plagued by this small mistake.

Moving from Kirigami.AboutPage to MobileForm.AboutPage

While adding the Okular icon to the app, I also came across MobileForm.AboutPage, which is an experimental feature from Kirigami Addons that changes the layout of the About page from Kirigami.AboutPage. I asked my mentor if we should move to MobileForm.AboutPage since it looks better and more modern, and he agreed. So I replaced Kirigami.AboutPage with MobileForm.AboutPage in this merge request.

Here's how the Kirigami.AboutPage looks in Okular:

Here's how the new MobileForm.AboutPage looks in Okular:

Porting to FormCard from MobileForm

Shortly after I had moved Okular to using MobileForm.AboutPage, Kirigami Addons renamed MobileForm to FormCard. The MobileForm QML import would still be available but it would not receive new features. The new FormCard will receive new improvements, so it is advised to switch to it. This blog post by Carl Schwan explains it in more detail. So I ported Okular to the new FormCard API in this merge request.

FormCard.AboutPage has a few subtle differences from MobileForm.AboutPage. Here's how it looks like:

Fix qtbase Crash/Hang in Okular

Sometime around the start of the first coding period, I noticed that Okular on my phone would freeze on a black screen when attempting to open PDFs in it. I initially worked around this running Okular in the Android emulator packaged with Android Studio.

However, since I had some more free time during the second coding period, my mentor and I decided to tackle this issue. The issue seemed to be device specific, and only a couple of the phones I tested Okular on had this issue.

I distinctly remembered that an older version of the Okular apk was running properly on my device, without freezing/crashing to a black screen whenever I attempted to open a PDF. Luckily I was able to find an old APK from my phone backups, and confirm this.

This older APK was v22.12.3 of Okular, with Qt 5.15.8, and KDE Frameworks 103.0. The newer APK with the black screen issue was release/23.04 of Okular, with Qt 5.15.10 and KDE Frameworks 108.0.

My mentor suggested downgrading Okular to version 22.12.3 and testing it. The app still crashed, so my mentor suggested that Qt itself might be causing issues, and so I compiled Qt 5.15.8 in Craft and testing Okular by building against it. It worked fine, and opened PDFs properly. After this I did the same with Qt 5.15.9, which displayed the black screen issue in Okular.

So far we had deduced that the issue occurred sometime between Qt version 5.15.8, and 5.15.9. To narrow down the search, my mentor then shared a list of commits which were applied between Qt 5.15.8 and 5.15.9, and were related to Android.

Immediately I noticed that when running Okular on Android, adb logcat would have some warning messages from Qt A11Y. During testing, I had also noticed that in the tombstone file generated by Okular crashing during the black screen, the stacktrace indicated that Qt was doing some threading-related stuff and also executing Qt A11Y code.

In the list of commits shared by my mentor, you will notice that commit 513fcf0d2ad3328830dbf73dc2a55ad1487393c0 deals with Qt A11Y and threading both, so this commit stood out to me. My suspicions turned out to be correct - when I checked out the commit in git, Okular was freezing/crashing as usual, but when I checkoud out the commit immediately before it, Okular was working fine.

I shared this information with my mentor, and he looked up some commits from qt6 that seemed related:

• https://invent.kde.org/qt/qt/qtbase/-/commit/b8a95275440b8a143ee648466fd8b5401ee1e839

• https://invent.kde.org/qt/qt/qtbase/-/commit/ac984bd8768b3d7e6439e0ffd98fd8b53e16b922

• https://invent.kde.org/qt/qt/qtbase/-/commit/b832a5ac72c6015b6509d60b75b2ce5d5e570800

To test these patches, I backported them using git cherry-pick, rebuilt Qt, and the rebuilt Okular.

After a bit of testing, I saw that the commit ac984bd8768b3d7e6439e0ffd98fd8b53e16b922 completely solved the issue of black screening when opening a PDF on Okular. Out of the 2 devices I tested this on, both no longer displayed any issues with this commit.

My mentor suggested that I send these patches to the kde/5.15 branch of qtbase at KDE's qtbase repository by following this guide: https://community.kde.org/Qt5PatchCollection#How_do_I_get_a_patch_merged

I followed the instructions given in the page - I cherry picked the commit to the kde/5.15 branch of qtbase, and opened a merge request on the kde/5.15 branch of KDE's qtbase repository.

Challenges faced

Getting used to Craft's system:

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

• from the KDE Wiki page about Craft.

In order to work with Okular, I had to get used to Craft. As a beginner who just learnt CMake over the course of GSoC, learning to use Craft took quite a bit of effort. The first few steps were a breeze, thanks to the KDE wiki page about Craft and also because I had worked with Craft during the first coding period.

However, Craft keeps bumping up versions of software such as KDE Frameworks, Qt, etc. every once in a while. This can make it tough to test out older versions of such software. In my personal experience, I had to mess around in Craft's version.ini files for Qt5, located at /CraftRoot/etc/blueprints/locations/craft-blueprints-kde/libs/qt5.

Building Qt in craft - binutils

While trying to build applications and libraries in craft, I frequently ran into errors about the GNU binutils not being able to recognize the file format of the compiled files. I usually bypassed these by setting the $PATH variable to point to the GNU binutils built for Android, usually located at /home/user/CraftRoot/tmp/android-24-toolchain/arm-linux-androideabi/bin. Now keep in mind that I have only encountered this issue when building for arm32 devices, it could be entirely possible that it builds just fine when building for arm64 android devices.

However, that's not all - I encountered this issue again when building Qt for arm32 Android inside the Craft environment. For example, when building qtbase, I got the following error when using the default toolchain.

/opt/android-sdk/ndk/22.1.7171670/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objcopy:/home/user/CraftRoot/build/libs/qt5/qtbase/image-MinSizeRel-5.15.9/bin/qmake: File format not recognized
Command ['/opt/android-sdk/ndk/22.1.7171670/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objcopy', '--only-keep-debug', '/home/user/CraftRoot/build/libs/qt5/qtbase/image-MinSizeRel-5.15.9/bin/qmake', '/home/user/CraftRoot/build/libs/qt5/qtbase/image-MinSizeRel-5.15.9-dbg/bin/qmake.debug'] failed with exit code 1
Action: install for libs/qt5/qtbase:5.15.9-1 FAILED

In this case, simply setting the $PATH variable did not work, I had to improvise and use the Xamarin android toolchain as it was more up to date, and add it to $PATH inside the Craft docker container. However, this toolchain generated much larger APK sizes, jumping from a modest 56 MB to 110 MB.

Maybe in the future I could try creating a Craft package for GNU binutils for Android, which would minimize, or at least reduce the frequency of running into problems like this. No promises though! :P

Debugging in Android

This has been mentioned in my previous blog post already, but Android's way of handling permissions made debugging a headache. Initially I rooted my Android phone and used gdbserver to try and get debugging going, but it eventually ended with me giving up and resorting to staring at ADB logcat and trying to make Okular crash so that it would produce a tombstone file. While this approach did lead me to success with solving the black screen issue, it would have been nice to have some good debugging infrastructure.

Remaining Work

While this GSoC coding period was useful to fix some of Okular's issues as well as improve it a bit, there is still some remaining work that would go a long way for Okular to be considered an attractive PDF reader on Android:

Adding a "recent documents" section

Okular on desktop has a list of documents that were recently opened by the user. This allows the user to quickly re-open documents that they frequently access, and consequently speeds up their workflow as well as being much more usable. However, Okular on Android lacks this feature, and it would go a long way to make Okular a more attractive PDF viewer.

Adding the ability to jump to a specific page number

Okular on Android has no support for jumping to a specific page number of a PDF. This can be tedious for example in large documents with hundreds of pages.

Fixing bookmarks

At the moment, bookmarked pages do not show up in the bookmarks tab, as the bookmarks tab of the side drawer cannot be accessed as it is grayed out.

What now?

This GSoC journey has been an enjoyable learning experience for me. In the future, I'd like to contribute to KDE again, no matter if its through GSoC or not.

I'll most likely try to contribute to KDE and other FOSS projects whenever I have free time, and help those projects to improve, while improving my skills at the same time.

Wrapping it up

This GSoC has been a valuable and unforgettable experience into the world of Open Source Software. Not only did I get to learn the process for contributing to open-source and hone my own skills, I was also able to contribute to KDE, one of my favorite FOSS projects.

I'm thankful to my mentor Albert Astals Cid for his patience and guidance, which undoubtedly helped me overcome many of the obstacles in my journey.

I'd also grateful for the KDE Community, especially the members of the KDE Android Matrix room - they helped me to fix the Okular icon rendering, and without their help I might have still been bashing my head trying to solve it.

That's all for now. See you next time, and have a nice day! :D

The post Kdenlive 23.08.1 released appeared first on Kdenlive.

Wayland. It comes up a lot: “Bug X fixed in the Plasma Wayland session.” “The Plasma Wayland session has now gained support for feature Y.” And it’s in the news quite a bit lately with the announcement that Fedora KDE is proposing to drop the Plasma X11 session for version 40 and only ship the Plasma Wayland session. I’ve read a lot of nervousness and fear about it lately.

So today, let’s talk about it!

What is Wayland?

Wayland is a set of protocols that govern how a compositor draws stuff on the screen, and how apps interact with the compositor’s drawing-stuff-on-the-screen infrastructure. It’s similar to the HTTP and SMTP protocols that govern how web browsers and email clients send and receive web pages and data.

Wayland also includes an implementation of those protocols in a set of extremely lightweight libraries called libwayland-client and libwayland-server that offer stable and versioned APIs. Apps and compositors such as KDE’s KWin and GNOME’s Mutter use those APIs to do stuff.

Why does Wayland exist?

In a nutshell, because X11–the thing it’s replacing–is dead.

X11 has been in maintenance mode for years, and recently has gotten no real development at all other than changes to the XWayland compatibility system that allows X11 apps to use a Wayland compositor. Having something as central as the window server being unmaintained is a major issue, as it means no bug fixes, no security patches, and no new features to let it keep up with a changing world.

Why did X die?

The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isn’t a fork of an old one is nearly impossible. Everyone strongly preferred to standardize on a single X server and migrated in unison from one to another when a better fork became available, because it was convenient. And it was convenient because because it centralized limited development resources, and when a feature was added to the X server, everyone gained access to it automatically.

But there was a drawback: because everyone was using Xorg, any feature added to support any use case could break everything else that everyone else used, and this happened frequently. Bug fixes frequently regressed obscure functionality that others were using.

In essence, Xorg became too large, too complicated, and too fragile to touch without risking breaking the entire Linux ecosystem. It’s stable today because it’s been essentially frozen for years. But that stability has come hand-in-hand with stagnation. As we all know in the tech world, projects that can’t adapt die. Projects that depend on them then die as well.

How is Wayland any better?

Wayland was conceived of by X developers who wanted to avoid repeating their own mistakes. In addition to a lot of technical differences, by being a minimal set of protocols and two extremely thin client and server libraries, all the heavy lifting was delegated to individual compositors, which became the window servers of their environments. A new feature added to one would not destabilize any other compositors. Compositors were also free to implement new features via private protocols outside of the standard ones that apps only targeting that compositor could use.

Wait, that sounds like it sucks

Wayland has not been without its problems, it’s true. Because it was invented by shell-shocked X developers, in my opinion it went too far in the other direction. Wayland’s minimal core protocols are lacking most of the features that non-trivial apps and desktops actually need to work–such as screen locking, screen sharing, cross-app window activation, non-integer scaling, and so on. Compositors all needed to come up with ways to do these things themselves. And that need for each compositor to implement everything itself fragments development efforts and disadvantages small teams without the expertise of heavy-hitting graphics developers. These are real problems and we shouldn’t sweep them under the rug.

Yes, but there are solutions

Over time the minimal core protocols have been extended to cover what’s needed for a Linux desktop and sophisticated apps to work. Much of this work is very recent, driven by KDE, and funded by Blue Systems and Valve Software. So most complaints you read about Wayland missing this or that (such as fractional scaling, or screen sharing, or global shortcuts) from over a year or two ago are likely to be wrong today.

In addition, the problem of fragmentation of effort is being solved by wlroots, a library of Wayland implementations that you can use to build a Wayland compositor. We don’t use it in KDE’s KWin compositor because we already did most of that work ourselves before wlroots existed, but it’s a big benefit to anyone writing a new compositor from scratch today. And there’s a chance we might port KWin to use wlroots in the future.

Why is the adoption taking so long?

The fact that Wayland’s minimal core protocol made it unable to fully replace the thing it aimed to replace was a bad architectural design decision on the part of its authors that crippled the prospect of its rapid adoption when it was released in 2008. We didn’t see the same problem with other newer projects like Systemd and PipeWire which were adopted much faster.

And unfortunately, shepherding new protocols through the approval process to fix this problem is a grueling political exercise. It demands empathy and compromise with people from other projects who approach the problem you’re trying to solve from a fundamentally different perspective. Someone may disagree that the problem is even worth solving. Bikeshedding derails the discussion and everyone gets demoralized and stops working on it. For a long time, the urgency of pushing through it was low because X wasn’t dead yet.

So it took over a 15 years and resulted in Wayland’s dirty laundry being aired in public for that whole time. And that sucks. But… we’re there now. Standard protocols now exist for just about everything anyone needs. The few remaining obvious omissions (like screen color calibration) are being actively worked on as a matter of priority.

“Are we there yet?”

Plasma and KDE apps work great on Wayland, especially in the upcoming Plasma 6 release. Like I said, there are still a few omissions, but those holes are being plugged very quickly these days.

Most 3rd-party apps that aren’t Wayland-native also work fine via the XWayland compatibility layer. But there are some that don’t, because they integrate very deeply into some part of the system in a way that requires X11 support. These need to be ported to use new Wayland APIs.

A lot of app developers became accustomed to tuning out Wayland news while it was still a toy, and didn’t do the porting work. Well, it’s not a toy anymore, and now many are now feeling blindsided by the sudden urgency to port their apps to use Wayland. That’s understandable. But this time it’s for real, and the time to port is now. For any protocols that still aren’t good enough and need revision, app developers’ input is needed to revise them or even propose new ones. This process takes a long time, so better to start sooner rather than later. But it’s not just gonna go away.

Which brings us to Fedora KDE

Fedora has always been a “leading edge” distro that pushes forward the technical state of the art on Linux by adopting new technology once it’s mostly ready, thus causing it rapidly improve in a way that it otherwise would not have. Fedora was the first distro to adopt Systemd, PulseAudio, and PipeWire. It was the first to use the Plasma Wayland session by default. And now Fedora KDE wants to be the first to drop the Plasma X11 session entirely and make everyone use the Plasma Wayland session.

It should be clear that Fedora’s target audience consists of people who are excited about change. If this is you, all of these projects should seem exciting and cool! If not… then Fedora isn’t for you. And that’s fine. The Linux world has approximately five hundred bajillion distros. What’s that you say? Only about 20 of them are any good? Well, fair enough, but even if that pulled-out-of-someone’s-butt number is accurate, there are still 19 distros that aren’t Fedora! Reinstalling your OS is unpleasant, but it’s important to choose the right one that suits your needs and preferences. Choice comes with the responsibility of choosing wisely.

Maybe you’re afraid that Fedora is a “canary in the coalmine” that shows the way everything is going to go. And you wouldn’t be wrong about that, but transitions still take time. Distros that intentionally ship old software like Ubuntu LTS or Debian Stable will let you keep using X11 for years and years. Arch will probably keep shipping X11 for a while too. You have options. By the time Ubuntu LTS removes X11 too, everything will be fully ready.

Putting it all together

Wayland is a replacement for X11, which is dead. Despite a rocky development process, it’s ready enough for Plasma and KDE apps that Fedora KDE is pushing it pretty hard. Many 3rd-party apps are already Wayland-native, but many are not, and they need to put in the work to port to Wayland. If anything they need is still missing, they need to step up to be part of the process of adding it. This process is happening, and isn’t going to stop happening. We need to work together to make it happen faster and more smoothly.

Kraft (Github) is a desktop utility making it easy to create offers and invoices quickly and beautifully in small companies.

Today we are releasing Kraft Version 1.1 with significant improvements for users and the Krafts integration with latest software such as cmake and KDE.

It received updated dutch translations in UI and also for the manual. The application icon was fixed, and some cmake related fixes were done that make Kraft working with different versions of Akonadi that are available on different distributions.

Macros

For users, two significant improvements are included: The header- and footer texts of the documents now may contain macros that support automatic computing of values such as dates that depend on the document date. With that, it is for example easy to have for example a payment date printed out on the document, that is ten days later than the document date.

There are even more interesting macros, stay tuned for a separate post about this feature.

Insert Templates Button

The second new feature is a new button that allows to insert templates for the header- or footer text at the cursor position. Before it was only possible to replace the entire text with a template. This will give users way more flexibility how to structure template texts.

In parallel to these improvements, work is also going on in a branch for Kraft 2.0 which will enable more collaborative functions for Kraft.

The upside of a wet summer followed by a late heatwave is here.

This week it was pretty much all Plasma 6 all the time. With the release date four and a half months away, work is kicking into high gear to make sure that we hit our deadline!

Plasma 6

General info – Open issues: 87

Made even more cursor responsiveness improvements for the Plasma Wayland session! The cursor is really very responsive now (Xaver Hugl, link)

This work as also substantially improved latency in general, especially for games (Xaver Hugl, link)

Kickoff now has an option to move its sidebar over to the other side of the main view. This has better Fitts’ Law adherence and zero risk of accidental category switching if you use the mouse pointer to activate Kickoff and launch Favorites more often than you activate it with the Meta key or switch categories (Forest Ix, link)

The default keyboard shortcut used to open the Activity Switcher has been changed to Meta+A, so that its prior shortcut Meta+Tab can be used some something else, which is coming soon… (Niccolò Venerandi, link)

When you have Powerdevil configured to hibernate after a period of sleep, invoking sleep using KRunner now respects that preference and hibernates at the appropriate time (Natalie Clarius, link)

Sped up the launch time of Plasma and QtQuick-based KDE apps by loading the mobile text editing toolbar on demand, rather than always (Fushan Wen, link 1 and link 2)

fstab-mounted NFS drives no longer produce duplicate items in the Places panel of various KDE apps and the open/save dialog (Méven Car, link)

Discover now shows release data for SteamOS system updates in a prettier and more comprehensible way (Jeremy Whiting, link)

Discover’s “About” page now uses the newer and more attractive FormCard style (Carl Schwan, link):

A variety of QtWidgets-based dialog windows that have menubars or toolbars now use the common unified header style that KDE’s app windows use (Carl Schwan, link):

Created a new standard component: Kirigami.InlineViewHeader, and ported a bunch of list and grid views to use it (me: Nate Graham, link):

The “Upgrade your distro now” notification message is no longer radioactive (Oliver Beard, link)

Other Significant Bugfixes

(This is a curated list of e.g. HI and VHI priority bugs, Wayland showstoppers, major regressions, etc.)

Spectacle now takes Rectangular Region screenshots correctly when you’re using any screen scale factors less than 100% (Noah Davis, Spectacle 24.02.0. Link 1 and link 2)

Fixed a case where the touchpad daemon could randomly crash (Gabriel Souza Franco and Fushan Wen, Plasma 5.27.8. Link)

Fixed a rare case where KWin would crash in the Plasma Wayland session when waking from sleep (Xaver Hugl, Plasma 5.27.9. Link)

The Alt+Tab window switcher is now fully accessible via the standard Orca screen reader in the Plasma Wayland session (Fushan Wen, Plasma 5.27.9. Link)

While updating a lot of Flatpak apps at the same time, discover can no longer exhaust the system’s set of available file handles and then fail (Discover 5.27.9. Link)

Automatically turning off the keyboard backlight when on battery power now works, if you’ve configured it to do this (Nicolas Fella, Plasma 6.0. Link)

Fixed a bug that could cause KIO-using apps to crash when trying to overwrite a file under certain circumstances (Kevin Ottens, Frameworks 5.111. Link)

Other bug-related information of interest:

• 5 Very high priority Plasma bugs (up from 4 last week). Current list of bugs
• 59 15-minute Plasma bugs (up from 58 last week). Current list of bugs
• 119 KDE bugs of all kinds fixed this week. Full list of bugs

Automation & Systematization

Added autotests for KHamburgerMenu (Felix Ernst, link)

Added more autotests for window placement in KWin (Vlad Zahorodnii, link)

Fixed a flaky autotest for the Task Manager in Plasma, and also expanded it to cover more things (Fushan Wen, link)

Fixed a flaky autotest in KIO (Méven Car, link)

…And everything else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.

How You Can Help

If you’re a developer, work on Qt6/KF6/Plasma 6 issues! Plasma 6 is usable for daily driving now, but still in need of bugfixing and polishing to get it into a releaseable state by the end of the year.

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

And finally, KDE can’t work without financial support, so consider making a donation today! This stuff ain’t cheap and KDE e.V. has ambitious hiring goals. We can’t meet them without your generous donations!

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

Willingham Sends Fables Into the Public Domain

Tags: culture, law, public-domain

This is unclear on the technicalities (is it even possible to just claim it like this? is CC0 required? etc.). Still this is a bold move, hats off to this renowned author.

https://billwillingham.substack.com/p/willingham-sends-fables-into-the

Google gets its way, bakes a user-tracking ad platform directly into Chrome | Ars Technica

Tags: tech, google, surveillance, attention-economy

If you’re still using Chrome, maybe you shouldn’t… They’re clearly making it easier to overcome ad blocker and the tracking won’t be a third party thing anymore, this browser will directly report on your behavior.

https://arstechnica.com/gadgets/2023/09/googles-widely-opposed-ad-platform-the-privacy-sandbox-launches-in-chrome/

Meet the Guy Preserving the New History of PC Games, One Linux Port at a Time

Tags: tech, gaming, maintenance, culture

Interesting conservation work. Video games being part of our culture, especially indie ones, it’s important for such work to happen and be funded.

https://www.404media.co/meet-the-guy-preserving-the-new-history-of-pc-games-one-linux-port-at-a-time/

Touch Pianist - Tap in Rhythm and Perform Your Favourite Music

Tags: tech, music, funny

Really cool and fun experiment. Surprisingly relaxing I find.

https://touchpianist.com/

If a hammer was like AI…

Tags: tech, ai, gpt, ethics, ecology, bias

Lays out the ethical problems with the current trend of AI system very well. They’re definitely not neutral tools and currently suffer from major issues.

https://axbom.com/hammer-ai/

Against LLM maximalism · Explosion

Tags: tech, ai, gpt, language

Now this is a very good article highlighting the pros and cons of large language models for natural language processing tasks. It can help on some things but definitely shouldn’t be relied on for longer term systems.

https://explosion.ai/blog/against-llm-maximalism

Computer Science from the Bottom Up

Tags: tech, system, unix, cpu, memory, filesystem

I didn’t read it since it’s basically a whole book. Still from the outline it looks like a very good resource for beginners or to dig deeper on some lower level topics.

https://www.bottomupcs.com/

A systematic approach to debugging | nicole@web

Tags: tech, debugging

Good process for fixing bug. Definitely similar to how I approach it as well.

https://ntietz.com/blog/how-i-debug-2023/

A user program doing intense IO can manifest as high system CPU time

Tags: tech, io, storage, cpu, kernel, performance

A good reminder that depending what happens in the kernel, the I/O time you were expecting might turn out to be purely CPU time.

https://utcc.utoronto.ca/~cks/space/blog/linux/UserIOCanBeSystemTime

Linear code is more readable

Tags: tech, programming, craftsmanship

A bit of a rambling, there’s something interesting in it though. Splitting small functions early will do more harm than good if they’re not reused. Don’t assume they automatically make things easier to read.

https://blog.separateconcerns.com/2023-09-11-linear-code.html

Async Rust Is A Bad Language

Tags: tech, rust, asynchronous, criticism

More details are surfacing regarding async and Rust… definitely not a match in heaven it seems.

https://bitbashing.io/async-rust.html

Good performance is not just big O - Julio Merino (jmmv.dev)

Tags: tech, performance, programming

Good list of things to keep in mind when thinking about performances. Of course, always measure using a profiler when you want to be really sure.

https://jmmv.dev/2023/09/performance-is-not-big-o.html

Response Time Is the System Talking

Tags: tech, queuing, networking, system, performance

Interesting way to approximate how loaded a system is.

https://two-wrongs.com/response-time-is-the-system-talking.html

FIFO queues are all you need for cache eviction

Tags: tech, caching

Interesting caching strategy. Looks somewhat simple to put in place as well.

https://blog.jasony.me/system/cache/2023/08/01/s3fifo

Death by a thousand microservices

Tags: tech, microservices, criticism, complexity

Looks like the morbid fascination for microservices is fading. This is very welcome. This piece is a good criticism of this particular fad and gives an interesting theory of why it came to be.

https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html

Making visually stable UIs | Horizon EDA Blog

Tags: tech, gui, fonts

Think of the typography and fonts if you don’t want to have text jumping around in your GUI.

https://blog.horizon-eda.org/misc/2020/02/19/ui.html

Bricolage | Some notes on Local-First Development

Tags: tech, web, frontend, crdt

Interesting, “state of the union” regarding local-first we frontend. Lots of pointers towards other resources too.

https://bricolage.io/some-notes-on-local-first-development/

Multi-page web apps

Tags: tech, web, frontend, complexity

Good reasoning, multi-page applications should be the default choice for web frontends architecture. The single page applications come at a cost.

https://adactio.com/journal/20442

The Tyranny of the Marginal User - by Ivan Vendrov

Tags: tech, attention-economy, criticism, design, ux

OK, this is a very bleak view… maybe a bit over the top I’m unsure. There seems to be some truth to it though.

https://nothinghuman.substack.com/p/the-tyranny-of-the-marginal-user

On Waiting - Tim Kellogg

Tags: management, organization, patience

This is a sound advice. In other words, don’t commit too early, only when you got enough information. Of course monitor to make sure you don’t miss said information.

https://timkellogg.me/blog/2023/09/14/wu-wei

Bye for now!

As last weeks post on countering string bloat has triggered some interest (and a few misunderstandings) here are a few more details on that topic. Nevertheless this isn’t going to be a comprehensive discussion of string handling in Qt (and was never meant to be), there’s plenty of posts and talks on that subject already out there if you want to dig deeper.

When to use QLatin1String

The KWeatherCore example in the last post was mainly discussing the use of QLatin1String in combination with Qt’s JSON API, as that has corresponding overloads. And that is a very important point, preferring QLatin1String over QStringLiteral for constant strings is only generally advisable if such overloads exist.

Things will work either way of course (as long as we are only dealing with 7bit ASCII strings), but at a cost. QLatin1String is implicitly convertible to a QString, which involves a runtime memory allocation of twice its size and a text codec conversion to UTF-16. QStringLiteral exists to avoid precisely that, and saving that runtime cost is generally preferable over a few bytes in storage.

So this is always a case-by-case decision. QLatin1String overloads only exist in places where they can actually be implemented more efficiently, and it only makes sense to add them in those cases.

Note that “overload” is to be understood a bit more loosely than in the strict C++ sense here. Examples:

• String comparison and searching.
• JSON keys.
• QLatin1String::arg as an alternative for QString::arg.
• String concatenations, in particular in combination with QStringBuilder.

Yes, exceptions might exist where the reduced binary size trumps the additional runtime cost, e.g. for sparsely used large data tables. But there might be even better solutions for that, and that’s probably worth a post on its own.

Tooling

With the right choice being a case-by-case decision, there’s also understandably demand for better tooling to support this, search/replace isn’t going to cut it. While I am not aware of a tool that reliably identifies places where QLatin1String overloads should be used instead, there are tools that can at least support that work.

Clazy has the qstring-allocations static check to identify QString uses that can potentially be optimized to avoid memory allocations. This is actually the reverse of what is discussed here, so it’s a good way to catch overzealous QLatin1String uses. It has the second to lowest reliability rating regarding false positives though, so this is also not something to apply without careful review.

Clazy’s qlatin1string-non-ascii check is another useful safety net, finding QLatin1String literals that cannot actually be represented in the Latin-1 encoding.

Enabling QT_NO_CAST_FROM_ASCII also helps a bit as it forces you to think about the right type and encoding when interfacing with QString API.

The other aspect of tooling is looking at binary size impact of code changes. A simple but effective tool is bloaty, which is what produced the size difference table in the previous post. Make sure to strip binaries beforehand, otherwise the debug information will drown everything else.

For a more detailed look, there is also the size tree map in ELF Dissector.

Expected savings

How much savings to expect varies greatly depending on a number of circumstances. It’s also worth looking at absolute and relative savings separately. In the previously mentioned KWeatherCore example this were 16kB or 7% respectively.

This is due:

• Few if any QLatin1String overloads were used, so a lot of room for optimization.
• The library is very small and a significant part of it is JSON handling.
• Other significantly more impactful optimizations to its static data tables had been applied previously (see e.g. this MR).

Let’s look at another example to put this into perspective, this change in KPublicTransport. Just like the KWeatherCore change this also changes QStringLiteral to QLatin1String in places where corresponding overloads exist, primarily in JSON API.

    FILE SIZE        VM SIZE
 --------------  --------------
  -0.1%     -16  -0.1%     -16    .eh_frame_hdr
  -0.1%    -144  -0.1%    -144    .eh_frame
  -0.1%    -430  -0.1%    -430    .text
  -0.9% -3.97Ki  -0.9% -3.97Ki    .rodata
  -0.3% -4.00Ki  -0.3% -4.54Ki    TOTAL

The savings here are lower though, just 4kB or 0.3%. This is due:

• The majority of this code already uses QLatin1String overloads, the change only fixes a few cases that slipped through.
• Unlike with KWeatherCore the QString overloads remain in use for generic code not using literal keys. We therefore see no reduction due to fewer used external symbols (.plt remains unchanged).
• The library is much larger in total.
• The data size is dominated by compiled in resources, primarily polygons in GeoJSON format (the big red box in the center of the above screenshot).

The latter would be the much more relevant optimization target here, as GeoJSON isn’t the most efficient way neither regarding space nor regarding runtime cost.

In general, the absolute amount of size reduction should be somewhat proportional to the amount of QStringLiteral changed to QLatin1String. If the relative change is surprisingly low, it’s worth checking what else is taking the space.

An even more extreme example that came up in discussions on this is Tokodon, where the relative reduction was just a fraction of a percent. A view in ELF Dissector reveals the reason for that, its giant compiled-in Emoji tables overshadowing everything else

Besides the data size (which wont be entirely avoidable here) this also involves a significant amount of static construction code, which is the even more interesting optimization target as it also impacts application startup and application runtime memory use.

Conclusion

As always with optimizations there is no silver bullet. Occasionally looking into the output of various profiling and analysis tools for your application or library usually turns up a few unexpected details that are worth improving.

Nevertheless I stand by my recommendation from last time to keep the seemingly minor details like the use of the right string API in mind. It’s an essentially free optimization that adds up given how widely applicable it is.

The release candidate is here for Krita 5.2, this means that we are confident that all the major bugs brought on by the changes in Krita 5.2 have now been fixed, and would like you to give it another round of testing.

Please pay extra attention to the following features of Krita, since they got updated or reworked since Beta2:

• assignment of profiles to displays in multi-monitor setup (Krita should use EDID info to map the displays to profiles everywhere, except on macOS)
• dockers layout should now be properly restored after Krita restart, even after the usage of canvas-only mode
• autokeyframing feature of animated layers got a lot of fixes since Beta2

Here is the full list of bugs (and other minor changes) have been fixed since the second beta:

• Fix crash when activating Halftone filter in Filter Brush (Bug 473242)
• Fix a crash when activating Color Index filter in the filter brush (Bug 473242)
• text: Write xml:space as XML attribute in SVG output
• text: Normalize linebreaks into LF when loading from SVG
• Build patched libraqm with Krita instead of in 3rdparty deps
• [qtbase] Correctly parse non BMP char refs in the sax parser
• Actually load the fonts in the QML theme (Bug 473478)
• Fix Channels docker to generate thumbnails asynchronously (Bug 473130)
• Fix wobbly lines when using line tool (Bug 473459)
• text: Make sure white-space overrides xml:space
• text: Reject negative line-height in SVG
• Simplified fix for tag selector and checkboxes problem (CCBug 473510)
• Fix creation of a new image from clipboard (Bug 473559)
• Make sure that the horizontal mode of the preset chooser is properly initialized
• Hide preset chooser mode button when the chooser is in horizontal mode (Bug 473558)
• Only repaint KisShapeLayerCanvas on setImage when really needed
• text: Do not synthesize bold in several cases like fonts that are already bold or variable fonts.
• AnimAudio: Fixed crash when loading animation file with audio attached, due to incompletely constructed canvas.
• Fix a model warning in KisTimeBasedItemModel (Bug 473485)
• Don’t recreate the frames when not necessary (Bug 472414)
• Fix cross-colorspace bitBlt with channel flags (Bug 473479)
• text: Also consider HHEA metrics for default line height (Bug 472502)
• Fix BDF font-size matching (Bug 472791)
• Make sure that the node emits nodeChanged() signal on opacity change (Bug 473724)
• Fix ‘enabled’ state of the actions in the Default Tool (Bug 473719)
• Respect statusbar visibility after Welcome page (Bug 472800)
• Fix a warning in outline generation code in shape tools (Bug 473715)
• Possibly fix a crash when switching animated documents (Bug 473760)
• OpenGL: Request DeprecatedFunctions on Windows to fix Intel driver (Bug 473782)
• Allow welcome page banner to shrink
• text: Use line-height when flowing text in shape (Bug 473527)
• text: Make first word of text-in-shape flush against the shape
• Fix color values under transparent pixels be lost in Separate Image (Bug 473948)
• flake: Fix transformation of text path and shape-inside (Bug 472571)
• Make sure that Krita correctly specifies video codec for libopenh264 (Bug 473207)
• Don’t allow New/Open File buttons to grow taller (Bug 473509)
• raqm: Fix Unicode codepoint conversion from UTF-16
• Android: Bump targetSdkVersion to 33
• Fix multiple issues with auto-keyframing code
• Edit Shapes tool: make moving points move points by a delta instead of snapping them to the cursor
• Initialize tool configGroup before optionWidget (Bug 473515)
• Fix updates on autokeyframing with onion skins enabled (Bug 474138)
• JPEG-XL: fix crash on importing XYB grayscale that needs transform
• JPEG-XL: also apply patches workaround on lossy export
• Fix artifacts when using assistants in images with high DPI (Bug 436422)
• Don’t allow closing hidden document views without confirmation (Bug 474396)
• logdocker: Fix infinite tail recursion with multiple windows (Bug 474431)

Download

Windows

If you’re using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.

Note that we are not making 32 bits Windows builds anymore.

• 64 bits Windows Installer: krita-x64-5.2.0-rc1-setup.exe
• Portable 64 bits Windows: krita-x64-5.2.0-rc1.zip
• Debug symbols. (Unpack in the Krita installation folder)

Linux

• 64 bits Linux: krita-5.2.0-rc1-x86_64.appimage

The separate gmic-qt AppImage is no longer needed.

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

macOS

Note: if you use macOS Sierra or High Sierra, please check this video to learn how to enable starting developer-signed binaries, instead of just Apple Store binaries.

• macOS disk image: krita-5.2.0-rc1.dmg

Android

We consider Krita on ChromeOS as ready for production. Krita on Android is still beta. Krita is not available for Android phones, only for tablets, because the user interface requires a large screen. RC1 packages for Android are signed as usual.

• 64 bits Intel CPU APK
• 32 bits Intel CPU APK
• 64 bits Arm CPU APK
• 32 bits Arm CPU APK

Source code

• krita-5.2.0-rc1.tar.gz
• krita-5.2.0-rc1.tar.xz

md5sum

For all downloads, visit https://download.kde.org/unstable/krita/5.2.0-rc1/ and click on Details to get the hashes.

Key

The Linux AppImage and the source .tar.gz and .tar.xz tarballs are signed. This particular release is signed with a non-standard key, you can retrieve is here or download from the public server:

gpg --recv-keys E9FB29E74ADEACC5E3035B8AB69EB4CF7468332F

The signatures are here (filenames ending in .sig).

The post Krita 5.2 Release Candidate is out! appeared first on Krita.