Planet KDE

Qt for MCUs 2.6.1 has been released and is available for download. As a patch release, Qt for MCUs 2.6.1 provides bug fixes and other improvements, and maintains source compatibility with Qt for MCUs 2.6.x. It does not add any new functionality.

We recently remove the Plucker/Palm support in Okular, because it was unmaintained and we didn't even find [m]any suitable file to test it.

If you are using it, you have a few months to step up and bring it back, if not, let's have it rest.

Last weekend I attended FOSDEM as part of KDE’s presence there, gave a talk about semantic data extraction of travel-related emails, met old long-time friends, had many interesting discussions and the occasional waffle. One topic however got slightly out of hand and ended up consuming most of my time.

Open Public Transport Routing

For road-based routing a few FOSS and Open Data services exist, OSM has some integrated on their website for example. We don’t have something like this for public transport though.

There we are stuck with proprietary services, run mostly by transport operators themselves or by companies like Google. Those have a number of issues:

• Borders. Transport operators tend to only cover the area they are serving, be it a municipality, a region or a country.
• Competition. Transport operators have no interested in showing services offered by their competitors.
• Access. Most of those services are meant for the corresponding websites or apps of the operators, access for 3rd parties (and even more so non-paying FOSS 3rd parties) is often restricted one way or the other.
• Privacy and data protection. Google is involved.

While much of this is understandable from an operator perspective, it’s not really satisfying from a user perspective. Therefore demand for an independently-run fully open public transport routing service has been building up since quite some time.

Roughly this would need three non-trivial ingredients:

• A FOSS routing engine.
• Freely available schedule data as well as realtime position/delay/disruption data.
• Someone to run that as a service.

So for context and dramatic effect here’s how things developed in chronological order.

Before 2023

With GTFS, NeTEx, SIRI, etc. standards for exchanging schedule and realtime data exist. Regulation mandating operators to publish such data also exists in several regions of the world (including the EU), compliance with that still has room for improvement though (especially in the EU).

With OpenTripPlanner (OTP), Navitia and MOTIS there are also three FOSS routing engine available.

Deployments for those also exist. OTP is used nation-wide in Finland and Norway, by a few municipalities in Germany (stadtnavi, bbnavi) and by community-run projects in the cities of Münster and Ulm. Being run not by transport operators, those show what becomes possible when your goal isn’t to sell your services but to help people to find the best way to get from A to B.

The Navitia team also runs an instance covering many areas all over the world. Routing between different coverage areas isn’t supported, but it’s often the only way to get any coverage at all, in particular outside of Europe. Many of the FOSS transport apps rely on this.

None of the FOSS engines scales well enough yet to be able to route across all of Europe though.

2023

Navitia drops many coverage areas from their free service and SNCB discontinues their Hafas API, leaving the FOSS transport apps with several large gaps in the regions they can serve.

MOTIS is meanwhile said to have achieved acceptable performance for routing on an European-scale dataset on realistic hardware.

The year ends with various discussions on that topic at 37C3 showing a growing demand for a proper alternative, while at the same time technical blockers crumble.

February 3rd 14:00

It’s the first morning at FOSDEM. Mikolai Gütschow from Transportr presents in the Railway and Open Transport devroom, and towards the end of his talk suggests to create an open public transport routing service among the various parties in the growing FLOSS public transport ecosystem.

Picture by OpenRail Association (source). February 3rd 15:30

Following Mikolai’s talk a few interested people meet in the hallway discussing this subject. There is a sense of actually starting to look into possibly working towards implementing this eventually, gathering people that had shown interest in this, determining what would be needed in terms of infrastructure and approaching organizations that might potentially able and interested in hosting this.

And then things escalated a bit.

February 3rd 17:00

Approaching the end of day 1 of FOSDEM, a powerful server had been found. Retired from previously doing simulations in an university physics lab it comes with plenty of memory (which is important for this), and is hosted and available for free.

Moreover, Jonah had already been looking into setting up MOTIS on it and was getting the first results.

February 4th 11:00

The people interested in this (more by now) meet again in the hallway, to catch up on what had changed meanwhile and to discuss how to continue. Two topics are in focus in particular:

• Project setup, infrastructure and communication channels to work together.
• Designing a setup that allows for easy crowd-sourcing of the GTFS feed maintenance.

The last point is probably where most of the work has to be spend overall. FOSS routing engines exist, but they depend on correct input data, and that data is spread out into hundreds if not thousands of separate feeds of varying quality.

Keeping on top of each single one of those will likely involve manual work to some extend, and that is best done by someone local, understanding the local language and able to judge the correctness and completeness of the data. In some cases it might also involve working with the local public transport operator to resolve issues and/or to remind them of regulation requiring the publication of this data.

Luckily there is also quite some prior work around GTFS quality assurance and processing tools available which this can be built on top of.

February 4th 13:00

The hardest problem is solved, the thing has a name, Transitous, and a project repository in the Github public-transport organization. With concrete next steps in hand people head for lunch.

February 4th 14:30

While walking across FOSDEM to another unrelated meeting we get offered more servers to host this on. Just normal FOSDEM things.

February 4th 22:00

From on board of trains home the first code lands and the first merge requests are opened.

February 5th 07:30

People not having been at FOSDEM have gotten word of this and want to join.

February 5th and onwards

There is a continuous stream of work going on, including discussing GTFS feed metadata formats, identifying and fixing API issues in MOTIS, server setup and implementing MOTIS client support in KPublicTransport.

KTrip showing MOTIS search results across four countries and multiple different transport operators.

Initial experiments also show that further work in clients is needed to deal with the much larger variety of operators in the results, some of which might not be usable with an already existing ticket for example.

Outlook

This is and remains an enormous task and there’s no guarantee of success. But if only a fraction of the momentum from the past weekend remains over the next weeks and months this might actually work out.

If you are interested in collaborating on this, join the #opentransport Matrix channel and the Transitous Github project!

Saturday, 10 February 2024

KDE today announces the release of KDE Frameworks 5.115.0.

KDE Frameworks are 83 addon libraries to Qt which provide a wide variety of commonly needed functionality in mature, peer reviewed and well tested libraries with friendly licensing terms. For an introduction see the KDE Frameworks release announcement.

This release is part of a series of planned monthly releases making improvements available to developers in a quick and predictable manner.

New in this version Breeze Icons

• Update Google icon (bug 462165)

Extra CMake Modules

• ECMUninstallTarget: port generated code away from deprecated exec_program

KCalendarCore

• src/incidence.cpp - fix infinite looping

KCoreAddons

• Add isProcExists func to check if /proc exists
• Determine UNIX process if "/proc" does not exist

KDeclarative

• Show GridDelegate labels as plaintext (bug 480106)

KHolidays

• holiday_ie_en-gb - Add St Brigid's Day (bug 479832)

KIconThemes

• CI: Don't require Windows test to pass

KIO

• KDirModel: Consider invalid roots are local fs (bug 477039)
• slavebase: abort mimetype emission when the worker was terminated (bug 474909)
• KDirModel: Allow expanding network directories in file picker again (bug 479531)
• KCoreDirLister: updateDirectory: update parent folder if it is listed (bug 440712)
• copyjob: Fix implicitly skipping files when copying (bug 479082)

KTextEditor

• Add parent widget for diff dialogs

KWallet Framework

• Emit the walletCreated signal in the KWalletD::pamOpen function if a new wallet is created during its call

Prison

• Enable exceptions for videoscannerworker.cpp

Security information

The released code has been GPG-signed using the following key: pub rsa2048/58D0EE648A48B3BB 2016-09-05 David Faure [email protected] Primary key fingerprint: 53E6 B47B 45CE A3E0 D5B7 4577 58D0 EE64 8A48 B3BB

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

We’ve been waiting 20 years for this - The History of the Web

Tags: tech, web, blog, culture

Excellent piece about the resurgence of old trends on the web.

https://thehistoryoftheweb.com/weve-been-waiting-20-years-for-this/

The European regulators listened to the Open Source communities! - Voices of Open Source

Tags: tech, foss, law

Looks like good progress has been made. A few more adjustments would be welcome before it gets ratified.

https://blog.opensource.org/the-european-regulators-listened-to-the-open-source-communities/

Google workers complain bosses are ‘inept’ and ‘glassy-eyed’

Tags: tech, google, transparency, management

Things don’t look great in this giant… it’s astonishing how much eroding vision and transparency can hurt an organization.

https://www.sfgate.com/tech/article/google-workers-company-culture-pichai-18653877.php

Netflix: Piracy is Difficult to Compete Against and Growing Rapidly * TorrentFreak

Tags: tech, streaming, video, business

Unsurprising trend… this was a market where there was no chance to have a single dominant platform due to the existing studio behemoths. So now we’re in the streaming wars, people can’t afford to pay for every silos… and they turn to piracy again. Could have been all avoided if we went the “global license” route instead of dumping money on platforms.

https://torrentfreak.com/netflix-piracy-is-difficult-to-compete-against-and-growing-rapidly-240204/

Stract search engine

Tags: tech, search, web

A new search engine trying to grow. The approach seems interesting, we’ll see where it goes.

https://stract.com/about

Browsers Are Weird Right Now – Tyler Sticka

Tags: tech, web, browser

A bit opinionated and sarcastic maybe… still it feels right, the web browsers landscape is in a sad state.

https://tylersticka.com/journal/browsers-are-weird-right-now/

Over the Edge: The Use of Design Tactics to Undermine Browser Choice

Tags: tech, microsoft, browser, vendor-lockin

Not unexpected of course, but at least it makes it clear that Microsoft is actively trying to prevent users from using the browser they want.

https://research.mozilla.org/browser-competition/over-the-edge-the-use-of-design-tactics-to-undermine-browser-choice/

Microsoft is seeking a software architect to port Microsoft 365 to Rust | TechSpot

Tags: tech, microsoft, rust

If they really commit to it, this means Microsoft will really invest big in Rust. Let’s wait and see…

https://www.techspot.com/news/101739-microsoft-seeking-software-architect-port-microsoft-365-rust.html

Blog - How I Also Hacked my Car

Tags: tech, automotive, security

The infotainment systems on car are not as locked down as one might think. Another proof of it.

https://goncalomb.com/blog/2024/01/30/f57cf19b-how-i-also-hacked-my-car

Rust Won’t Save Us: An Analysis of 2023’s Known Exploited Vulnerabilities – Horizon3.ai

Tags: tech, security, memory, rust

Indeed, not all security issues are due to memory related problems. It’s 20% of the security issues. This is of course massive, but there’s still 80% of the security issues coming from wrong authentication, appliances and so on.

https://www.horizon3.ai/analysis-of-2023s-known-exploited-vulnerabilities/

OPML is underrated

Tags: tech, blog, rss, opml

Definitely true. This is a good way to share your feeds with friends or to setup a blogroll.

https://kmaasrud.com/blog/opml-is-underrated.html

s/bash/zsh/g

Tags: tech, zsh, shell

Indeed, use zsh more. It’s good… or at least better.

https://www.arp242.net/why-zsh.html

VirtualBox KVM public release — Cyberus Technology

Tags: tech, linux, virtualization

This is an interesting VirtualBox fork for Linux. Using KVM as backend should bring interesting benefits.

https://cyberus-technology.de/articles/vbox-kvm-public-release

When “letting it crash” is not enough

Tags: tech, erlang, safety, crash, resilience

It’s here to sell something. That said it does a good job explaining the Erlang model and its “let it crash” approach to failures. Also highlights the obvious limitations.

https://flawless.dev/essays/when-letting-it-crash-is-not-enough/

Cool Things You Can Do with SELECT - Edward Loveall

Tags: tech, sql, databases

Indeed, a very underappreciated keyword in SQL. It can do much more than what it’s often used for.

https://blog.edwardloveall.com/cool-things-you-can-do-with-select

Postgres is Enough · GitHub

Tags: tech, databases, postgresql

Nice index pointing to resources to do many things with Postgres.

https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f06dbb

<model-viewer>

Tags: tech, web, 3d, webcomponents

Looks like a really convenient web component to display 3D models on web pages.

https://modelviewer.dev/

Method of Differences

Tags: tech, mathematics, history

Interesting explanation of the method of differences to easily compute polynomials.

https://ztoz.blog/posts/method-differences/

How to hire low experience, high potential people

Tags: hr, interviews

Good ideas and questions to interview candidates. I don’t think I would use everything though. Also I think some of what’s proposed here would work for candidates at any level of experience.

https://worktopia.substack.com/p/how-to-hire-low-experience-high-potential

Bye for now!

A tad over two years ago, I revealed the 15-Minute Bug Initiative–an attempt to improve the out-of-the box user experience for Plasma by focusing on fixing obvious papercut issues. The idea was to crush the meme of “KDE is buggy” the same way we systematically addressed similar complaints like “KDE is ugly” and “KDE is bloated” in years past.

Well, it’s been two years, so how did it go? Let’s talk about it! First some numbers, because we like numbers:

• Starting number of bugs: 92
• Current number of bugs: 32
• Total number of bugs fixed (because more were added over time): 231
• Percent of all total 15-minute bugs that have been fixed: 87.8%

(note if you’re from the future: if you visit those links, some numbers may be different–hopefully lower for the second one and higher for the third one!)

Wow! That’s quite a few. So this initiative looks like it’s been a real success so far! Nevertheless, 32 bug reports remain open, so we can’t declare victory yet. These are some of the stubbornest, hardest-to-fix bugs that require major re-architecting, working upstream, or similarly challenging efforts. Hopefully the pace of improvement seen over these years has managed to convince you that they’ll eventually be resolved as well.

“Wait a minute, Plasma is still buggy AF you n00b”

Keep in mind these aren’t all the bug reports in the world we can fix (there are over 5000 of them for Plasma and Plasma-aligned software alone), just the ones I and some others have deemed to be most obvious to the average user! If you’re not an average user because you have three monitors arranged in a weird shape, each plugged into a different GPU from a different vendor and its own different DPI, scale factors, and custom Plasma panels, plus 4 activities and 9 virtual desktops and 6 internal disks, only half of which automount, and 12 apps set to autostart, and each of them is installed onto different disks, 15 window rules, and finally a custom theming setup including Kvantum themes and Aurorae window decorations… then yeah, you’re probably going to experience some more bugs compared to a more typical user who doesn’t have such a complex setup!

That’s okay. We care about you too, and we do work on those kinds of more esoteric bugs because many of us also have complex setups! But progress here will be necessarily slower, because the complex setups are more varied, more unusual, and harder to debug. And let’s be honest here: those of us with setups like these are experts capable of working around most bugs we find, who really should be helping to investigate and fix them. Admit it, you know it’s true!

But in a way, this is good: it represents Plasma moving from “It’s generally buggy” to “it’s specifically buggy–buggy with only certain less common combinations of settings, rather than buggy in a way that anyone can find within 15 minutes of using a system with its default settings. Improving on that was the point of this initiative.

Next steps

Up until now we’ve been ignoring Wayland-only bugs here, because the Wayland session was not the default one. Well, with Plasma 6 that changes, so all of those Wayland-only issues that meet the loose criteria to be a 15-minute bug will be promoted. Similarly, current 15-minute bugs that are X11-only will be demoted. So sometime in the next few weeks, expect the list to shift around a bit.

Once the number gets down to 0, it will of course go up again periodically as new bugs are found or introduced. But this is great! It means we can whack them as they appear, rather than letting them pile up over time. In this way the list becomes a “rapid response needed” task list rather than a backlog we’re always behind on.

What happens with those development resources once the 15-minute Plasma bugs are under control? I have a plan, first articulated in the original announcement 2 years ago: extend the program to Frameworks bugs! There are quite a few candidates there too. And because frameworks bugs can affect Plasma and our vast app library, quality will go up overall.

Speaking of those apps, once the 15-minute Frameworks bugs are also down to zero or close to it, we can include app bugs. This will finally give us complete coverage! I have a dream that one day, we’ll have a stable and mostly bug-free UI layer and our limited development resources can be focused more on performance work, sustainably-crafted new features, usability, more standardized styling, etc. I think it’s doubtful we can get there while we’re still battling routine bugs all the time.

How you can help

As always, help work on the existing 15-minute bugs if you can! If not, it’s always useful to work on bug triaging, so that more of those issues that will eventually become 15-minute bugs can get discovered. Another impactful way is to donate to KDE e.V., the nonprofit that support KDE on a ridiculously small budget. We’re still running the Plasma 6 fundraiser which represents a great way to donate!

One of the key components to using a Plasma Wayland session is obviously the Qt Wayland Client module for running Qt applications in a Wayland environment. While it has been successfully deployed to millions of devices over the years, there’s still a few areas that feel like they haven’t been touched much since its inception as part of the Qt Lighthouse project, what turned into QPA, the Qt Platform Abstraction.

WIP: Qt Wayland client-side decoration with a proper drop shadow and all Improving the SHM Backing Store

Fushan Wen complained about abysmal performance when using Kolourpaint (a faithful re-creation of the original MS Paint, just better) under Wayland. Thanks to Hotspot (my favorite profiler front-end) we found a bottleneck in Qt’s Wayland SHM (Shared Memory) Backing Store, the infrastructure that provides software-rendered applications with a canvas to draw into. The way Wayland works is basically that an application creates a wl_buffer, fills it with content, and “sends” it to the compositor. Once the compositor is done processing it (e.g. after having uploaded it to the GPU) the client may re-use that buffer again.

If we pick a different buffer to draw into because we want to start drawing before the compositor is done with the previous one, any previous content needs to be transferred over since Qt expects to see the contents it drew previously. This is where we found the choke point: Even though the application reported the correct region that changed (when drawing with a brush only the new splodges of color need to be rendered after all), Qt Wayland copied the entire buffer. Therefore, I replaced the original memcpy with proper damage tracking which significantly sped up rendering. Many thanks to Ilya Fedin for continued support while implementing this.

I then did more profiling and found that when painting on a window with alpha channel, Qt first clears the region to be painted. While there’s not much we can optimize about a “fill with color” call, we can skip doing that entirely if we have just created a new buffer, like is done repeatedly as you resize the window. The new buffer is initialized with zeroes already, therefore we can just start painting on it. Last but not least, I added support for “scrolling” the backing store, which is something Qt might ask us to do when scrolling through a view, such as a text editor or terminal window, and then have the application just fill in a small gap that’s left.

Prettified “Bradient” Decoration Kolourpaint running under Weston with client-side decorations

I very much dislike client-side decorations for their inconsistencies and burden they put on application developers but I nevertheless grew tired of seeing how hideous Qt applications looked on colleague’s computers running Gnome Shell. That is why I spent some time on making Qt’s “Bradient” decoration plug-in not stick out like a sore thumb. While it’s a massive improvement over the blue decoration Qt Wayland originally shipped, there is still a lot to be desired.

I believe it’s quite detrimental that Mutter (Gnome’s window manager and Wayland compositor) doesn’t support server-side decorations at all under Wayland. There’s plenty of applications that display non-application content and don’t care much about providing any decoration. For example, even running kwin_wayland under Gnome for development purposes gives you a window with no title bar or window border whatsoever.

Qt likewise relies on the desktop environment to provide a window frame and its drawing of client-side decorations under Wayland is if anyting a massive band-aid. Currently, Qt’s backing store just adds a window decoration around it and then returns the application a region inside the image that excludes the decoration again. It also lacks several features that one would expect from a window title bar, like double click to maximize or clicking the icon to bring up the window manager menu. In the future I am looking forward to putting the decoration into a sub-surface (or even using libdecor) which hopefully fixes many issues related to input and format handling.

Opening the window menu by clicking the icon, just as you would expect

To start off, the easiest change I did was using the correct mouse cursors for resizing the window. I then found that mouse input wasn’t properly translated when the window border was too thick, something that wasn’t noticeable with the default 3px border but surely would become a problem once we added a large shadow. Next, I fixed it not updating live when system colors changed, e.g. when enabling “Dark Mode”. Additionally, the title bar now includes the application name to be consistent with the title it sends to the compositor for display in task bar and window switchers.

Still, adding a proper drop shadow is work in progress: the most important part is to actually remove the window border and rounded corners altogether when the window is maximized or tiled and to adjust the button layout machinery to cope with changing margins. However, I also need to move the qt_blurImage function which creates the drop shadow texture into a place where I can use it without Qt Graphics Views or Qt Widgets (it’s currently used internally by QGraphicsBlurEffect).

Drag’n’Drop

Furthermore, I improved drag and drop handling: Qt Wayland now tries to decode URLs as UTF-8 – Chrome sometimes sends them like this – rather than just UTF-16. I also had it ignore the mysterious “DELETED” format Firefox sends that is likely a remnant from the XDnd specification. The latter fixes dropping an image to the desktop to set it as a wallpaper since Firefox doesn’t actually let anyone read this entry and Plasma gets stuck on it until it runs into a socket timeout.

The mouse now also uses the proper drag cursors. While the compositor may overrule the preferred action, we still want the default to match other desktop environments. I also fixed keyboard modifier propagation during drag and drop. While Wayland sends an explicit keyboard modifier change (Shift/Alt/Meta pressed or released), it does so after sending the actual key press. Qt on the other hand only updates its internal modifier state in response to an actual key presses. This meant that Qt doesn’t properly update its internal state when pressing a modifier when starting to drag a file and then holding Shift to initiate a “Move” operation. To fix that, Qt Wayland emits drag and drop events (and others) using the Wayland-internal modifier state rather than the one in QGuiApplication.

Discuss this post on KDE Discuss.

In the last post I talked about making things like detachable tabs or widgets work in a Wayland work. The protocol I submitted has now been merged into wayland-protocols!

Following I quickly switched Qt and KWin to use the now standardized protocol. KWin will support it with the initial 6.0 release. The Qt patch has been picked all the way down to the 6.6 branch which means it should be in the 6.6.3 release.

I am also happy to see that Robert Mader is working on making Chrome use the standard protocol, picking up my proof-of-concept level patch. Thank you!

Happy dragging!

Greetings, Kubuntu Community!

Today marked an important Kubuntu Council meeting, where we witnessed significant progress and collaboration among our esteemed council members – Darin Miller, Rik Mills, Valorie Zimmerman, Aaron Honeycutt, Jonathan Riddell (Kubuntu Treasurer), and Simon Quigley(Lubuntu). In this blog post, we’re excited to share the highlights and outcomes of the discussions that took place.

1. Focus on the Upcoming Kubuntu LTS Release 24.04
   
   A primary focus of our meeting was setting the objectives for the imminent Kubuntu LTS release. The council engaged in in-depth discussions to ensure that the upcoming release meets the high expectations of our community and continues the Kubuntu legacy of excellence.
   
2. Ubuntu Flavours Statement of LTS Support
   
   Understanding the importance of clear communication, we considered the necessity of a statement regarding Long-Term Support (LTS) required by Ubuntu recognised flavours. This move aligns with our commitment to provide transparency and detailed information to our users.
   
3. Exciting Collaboration with Scarlett Gately Moore
   
   We’re thrilled to announce that we have agreed to contract Scarlett Gately Moore for a three-month period. With a preliminary budget allocated, Scarlett will play a crucial role in delivering key projects:-
   
   – The 24.04 LTS Release,
   – Updating the Kubuntu Installer to Calamares,
   – Preparing an Alpha of Plasma 6 targeting the 24.10 release.
   
   This decision was unanimously agreed upon and reflects our dedication to continually enhancing Kubuntu.

Actions Moving Forward:

Coordination and Oversight: Simon Quigley will be coordinating with Rik Mills and Scarlett Moore, managing the intricate details and ensuring the smooth delivery of our objectives.

Financial Processes: Simon Quigley will oversee the invoicing process with Scarlett Moore, following the agreed pro-forma. Jonathan Riddell, our Kubuntu Treasurer, will handle the commissioning of payments.

Communication and Documentation: As a part of our commitment to keep the community informed, I, Rick Timmis, will be updating the Kubuntu Council mailing list about the meeting’s outcomes. Additionally, I will draft an LTS Statement for submission to the Ubuntu Technical Board, detailing our approach and commitment to Kubuntu’s Long-Term Support.

This meeting was a testament to the dedication and passion of our council members and the broader Kubuntu community. We’re excited about the direction in which Kubuntu is heading and are eager to see the fruition of these projects.

Stay tuned for more updates, and thank you for your continued support of Kubuntu!

Closing:

Best Regards,

Rick Timmis
Kubuntu Council

A lot has happened since the last update on KDE Itinerary, with the transition to Qt 6 finally completed, public transport coverage extended to more countries, a new journey map view and many more fixes and improvements.

New Features Journey map view

Mathis added a map view to the journey details page, so besides a list view of all stops you can now alternatively look at the route of a bus or train trip on a map as well.

Map view of a train connection.

Clicking on intermediate or final stops will show additional information such as the platform and provides access to the detailed station map.

Extended public transport coverage

Jonah has put quite some effort into filling the gaps in public transport data coverage in Europe, adding support for the following providers to the KPublicTransport library:

• Pasažieru vilciens (Latvia)
• LTG Link (Lithuania)
• Željeznički prevoz Crne Gore (ŽPCG) (Montenegro)
• Srbijavoz (Serbia)

Journey search result for a train connections between Latvia and Lithuania.

This not only benefits Itinerary but also KTrip.

Swapping arrival and departure location

A small but often requested convenience feature for the journey search has been added, the ability to swap arrival and departure stations with a single action.

Arrival/departure swap button in the upper right. Infrastructure Work Qt 6 port

Itinerary and all its dependencies finally completed the switch to Qt 6 in December. Despite the lengthy preparations for this a number of issues were only uncovered in the final steps of that process:

• Kirigami’s new way of displaying context actions clashes with Itinerary’s custom navigation bottom bar.
• Subtle changes in QVariant comparison behavior resulted in excessive timeline updates.
• Various default values in Kirigami and/or the Qt Quick Controls styles changed affecting list elements, ListView clipping, dialog/overlay placements, etc.
• There’s a behavior change for file dialog file type filters that lead to several support file types not being selectable on Android.
• Behavior changes in how Kirigami handles non-square icons required changes in how we display public transport line icons.

There’s also immediate benefits from this of course:

• Itinerary now uses the Breeze style on Android, which not only looks better but also reduces differences with the Linux version simplifying development and testing.
• Qt 6 allowed us to optimize the initial data loading by skipping expensive CBOR/JSON compatibility checks.

Qt 6 based Flatpak and Android nightly builds

Users of the nightly builds already get the new Qt 6 based version. For Android that has been a seamless switch, Flaptpaks moved to a new location though:

With Itineray being one of the more complex Android apps of KDE switching that to Qt 6 also exposed a number of remaining issues in the entire stack:

• Temporary content: URIs like used when sharing attachments from an email program to Itinerary were not readable by Qt anymore (fixed in Qt).
• Timezone lookup by IANA id performance is rather poor with Qt 6, which affects startup time if you have lot of data in Itinerary (partially worked around, fix for Qt pending).
• Reporting of flipped video frames in Qt Multimedia now works correctly on Android, resulting in a previous workaround for that causing upside-down barcode geometries (workaround removed in KF::Prison).
• Qt Multimedia camera access crashed when being used after an app had been suspended (fixed in Qt).
• Kirigami Addon’s new date and time picker didn’t correctly use Android’s native controls (fixed in Kirigami Addons).
• Remaining uses of Qt5Compat andQt.labs.platform components in Kirigami and Kirigami Addons were removed, decreasing the APK size noticeably.

All of this also benefits other KDE Android apps.

Accessibility

Motivated by getting automated UI tests set up using the AT-SPI Selenium driver, interaction with Itinerary using the accessibility interface has been improved in many places. Besides changes in the application itself this has also resulted in improvements in Kirigami and Kirigami Addons and thus helping all apps using those.

There’s more work to do though, around combo boxes and the date picker for example.

And even though this is not yet integrated in the CI pipeline, the first few automated tests created that way have already caught regressions in the application and in the Kirigami framework.

OSM raw data tile server update

The fixes for OSM raw data tile server powering e.g. Itinerary’s train station maps addressing node order loss on directional lines as well as improving tile generation performance have now finally been deployed on maps.kde.org. This unblocks work on rendering directional features, and it’s also crucial for the investigations around routing mentioned below.

Indoor map routing

As mentioned in my report from 37C3 we now have a very promising looking approach for routing in our train station maps. Compared to “outdoor” routing this is challenging as this has to work with areas rather than graphs, and on multiple floors.

Implementation of a proof of concept continued and is meanwhile running integrated in our indoor map demo application.

Multi-floor route through Berlin central station. Fixes & Improvements Travel document extractor

• New or improved travel document extractors for Accor, B&B Hotels, BlaBlaBus, Deutsche Bahn, Egencia, Emirates, Hilton, Iberia, IRCTC, Lufthansa, Meininger, NS, Pretix, SNCB, SpiceJet.
• Improved generic extractor for RCT2 tickets crossing the end-of-year boundary.
• Improved generic extractor for schema.org JSON-LD or Microdata events.
• Fix crash on action-less PDF links.
• Improved support for full-day events.
• Added schema.org annotations on foss.events making events from there directly importable.

All of this has been made possible thanks to your travel document donations!

Itinerary app

• Improved support for actions defined by providers via schema.org annotations, such as registering for an event or reserving a table at an restaurants.
• Onboard live data is now merged into the current journey state when available.
• Automatically pick an appropriate text color for Apple Wallet passes that don’t specify a text color themselves but use a background image. This fixes passes sometimes being rendered unreadable under these conditions.
• Fix manually selecting transfers in the timeline.
• Request camera runtime permissions on Android when using the barcode scanner.
• Move loading indicator out of the way once the first results of a public transport search are displayed.
• Fixed public transport stop searches after changing the country combo box.
• Fixed seat section in train page not sometimes showing up correctly.
• Added average speed statistics on the journey page.
• Fixed import of large backups on Android.

FOSDEM

If you are at FOSDEM tomorrow or the day after don’t miss to meet us at the KDE stand, in building H this time!

How you can help

Feedback and travel document samples are very much welcome, as are all other forms of contributions. The KDE Itinerary workboard or the more specialized indoor map workboard show what’s on the todo list, and are a good place for collecting new ideas. For questions and suggestions, please feel free to join us in the KDE Itinerary Matrix channel.

When designing an embedded product, there’s a lot riding on those crucial first decisions of choosing a hardware vendor and board. Clearly, the hardware you select must be powerful enough to support your product, a challenging determination given that software is usually still in the planning stages at this point in the process. Plus, planning for post-launch capabilities that may be on the drawing board creates additional uncertainty as to how much power you’ll need. However, overspending on beefed up capacity that you will never use costs money, impacting the company’s bottom line.

Optimizing time spent optimizing

It’s not that you can’t change the hardware midstream, but it often takes a while to realize that the existing platform isn’t going to fit. Until hardware constraints become too problematic to ignore, software engineers can waste time working around a limited platform, struggling to debug it properly, and ultimately delivering a suboptimal product. A midstream hardware change stalls development, curtails developer creativity, and forces further software adaptations, elongating the development timeline and adding costs.

When underpowered means underdelivering

However, a more severe problem arises when teams fail to recognize the need for a hardware upgrade. Building around a less powerful chip to keep down costs can stifle feature sets and cripple performance. This can trap software teams into spending more time working on costly workarounds than on making forward progress. Operating at the edge of a usable system often results in feature cuts and time spent building makeshift solutions that lead to poor product quality, diminished user experience, and a codebase filled with workarounds. This creates deep holes that are nearly impossible to dig out of.

Right-sizing your silicon

Oof. Okay, what to do about it? Here a few guidelines that may help:

• Carefully weigh your processing power, RAM, storage capacity, and I/O needs against the potential impacts they can make on development deadlines. As code size approaches onboard storage and RAM capacity, the time and effort to make things work grows exponentially. This is also the case for ongoing maintenance where preserving some headroom for additional features and fixes is essential.
• Highly complex feature sets like user-configurable capabilities, new over-the-air updates, or 3D visualizations consume RAM and storage space much faster than other areas. Estimate generously to avoid the risk of having an amazing feature that can barely fulfil its promise.
• Any embedded system is going to be connected to a raft of sensors, peripherals, and physical buttons. Detailed I/O planning is crucial to ensure your systems have enough GPIOs, A/Ds, D/As, UARTs, and USB, SPI, and I2C ports. Be sure to consider product expansions such as additional product lines and feature upgrades. Planning for some spare I/O capacity through expansion boards or modules early on can mitigate significant coding and reliability issues later on.
• Boards with additional peripherals, even if not currently required, can add value down the line. For example, an extra USB port can be a huge advantage during development for networking or additional storage, and onboard Bluetooth can enable future customer-requested features.

Critical choices shouldn’t be rushed

The intersection of hardware capability and software design is where successful embedded systems are born. Thoughtful hardware selection, a forward-looking approach to product design, and an integrated hardware-software development strategy are critical to a strong start in your embedded project. By prioritizing these considerations, you’re well positioned to deliver a product that meets current requirements in a reasonable amount of time and is adaptable for future demands.

We recommend reading a couple of our best practice guides, Designing Your First Embedded Linux Device and Best Practices: Embedded Development Hardware, which addresses this topic in more detail along with other best practices to get your project started on the right foot.

 

The post The Embedded Developer’s Dilemma in Choosing Hardware appeared first on KDAB.

With Qt 6.2, we introduced a new CMake API to handle internationalization (i18n) of Qt-based projects: qt_add_translations, qt_add_lupdate and qt_add_lrelease. These functions have shortcomings that we address in the upcoming Qt 6.7 release.

Plasma 6: The Final Stretch

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 now just one month 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, 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 second Release Candidate version of all the software we will include in the megarelease.

As with the Alpha and Beta versions, release candidates are previews intended for developers and testers. The software provided is now considered largely stable, 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 in the upcoming month.

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 support 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 2 Source Code Info Page
• Plasma 6 RC 2 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 2 Source Code Info Page
• KDE Gear 24.02 RC 2 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 2 Source Code Info Page
• KDE Frameworks 6 RC 2 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 catalog 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.

Now it’s full circle, a whole year of KDE has started again! This is a bit of a smaller post, for two reasons. First I have begun stripping out of the less interesting stuff I do - like really boring bugfixes, whoop. Secondly, I’ll be busy at $work for the next few months and I don’t know what my schedule is going to look like yet.

Plasma #

Bugfix Finished up Aleix’s QML API for Layer Shell Qt, and exposing it via a proper installable QML module. This is only useful for developers. 6.0

Feature Working on adding a simple tablet tester to the Drawing Tablet KCM, modeled after a certain KDE application’s own. 6.1

The new Tablet Tester

Feature Also working on adding a configurable pen pressure curve, allowing artists to tweak the pen pressure curve of their pen or eraser. It will have two fully-controllable points of articulation and two partially-fixed points for adjusting the thresholds. 6.1

What configuring your pen pressure curves could look like!

Bugfix Fix camera-video-symbolic being coloured wrong, when using dark color schemes like Breeze Dark. I also fixed document-send-symbolic using the wrong icon at 16x size. 6.0

The fixed camera icon The fixed send icon

Bugfix I added more common keywords for Screen Locking settings. 6.1

Bugfix Removed some Wayland-techno terminology from Drawing Tablet settings, “Pen buttons” should be called that. 6.1

KWin #

Feature I opened a merge request for the necessary things on the KWin side needed for configuring pen pressure. 6.1

Tokodon #

The next major release is upon us, so I started doing some last-minute bugfixing. This is also when we branch, so I can start breaking strings again! I hope to start adding new features next month.

Feature There has been an excess of bug reports of people using Tokodon without a way to store passwords. And if you use Tokodon on Android, it would be helpful to enable notifications but we have no way to ask you yet. To solve both of these problems (and possibly more in the future) I added a new initial setup flow. Said system will also prevent you from starting Tokodon without a way to save account data, hopefully preventing more of these bug reports in the future! 28.04?

Part of the new initial setup flow, UI to be improved on in the future of course.

Feature Tokodon now warns you when you’re viewing a private post, noting that this affects replies in an unusual way. I want to add more tips about Mastodon and ActivityPub-isms to work around these issues that are out of our hands. 28.04?

What the tip looks like in Tokodon

And now some smaller stuff:

• Bugfix The display of the home timeline name now makes more sense on desktop, preventing some duplicate text. 28.04?
• Bugfix Don’t show empty biography cards on profiles. 24.02
• Bugfix Visually separate the active account in the switcher. 24.02
• Bugfix Improve the “login error” message with icons, and better help text. 24.02
• Bugfix Fixed numerous alignment and padding issues everywhere. 24.02

PlasmaTube #

Same as Tokodon, I’ve been doing some more bug-fixing in preparation for the February mega-release and will continue to do so.

• Bugfix Added a proper video thumbnail placeholder, instead of loading videos being displayed as empty space. 24.02

• Bugfix Added a way to go directly to the channel page from a video item. This stops having to load the video, wait for it to finish and then navigate to the channel from the player. 24.02

• Bugfix Use the standard ItemDelegate component everywhere now. It should look and feel like expected. And it makes my life as a developer way better! 28.04?

• Feature Added a share button to the video player. 28.04?

• Feature Added a date chip to the video player for checking the published date. 28.04?

Kongress #

Bugfix Fixed two instances of broken section headers. 24.02

NeoChat #

Bugfix The room list now hides subtitle text when there is none, slightly improving the alignment. 24.02

The fixed alignment for rooms

Bugfix Improved the look of the search message dialog, like I did for the Explore Rooms dialog before. 24.02

The header is now properly coloured and separated Frameworks #

Bugfix Fixed symbolic icons being wrongly matched with a non-symbolic fallback, even if a symbolic version of said icon exists. This notably will fix lots of wrongly coloured icons in the system tray. 6.0

Bugfix Small improvements to the Kirigami platform plugin error message. This means that it’s easier to debug this issue when you give us logs. 6.0

Websites #

I spent some time trying to put in some small improvements to our Human Interface Guidelines, many of them are merged now but still need to take care of the rest.

• Don’t mention devicePixelRatio at all, remove mentions of Plasma Units that are no longer relevant in 6..
• Fix capitalization and shorten wording of 3rd-party theme note.
• Remove some lingering mentions of PC2.
• Move the “Generate Media” page underneath the “Contribute” category, since it’s only useful for that.
• Don’t put the mobile bullet point so far down the page.
• Remove the useless and incomplete KCMGrid page.
• Mention the ellipses unicode character in the label writing docs.
• Make a note that disabled context menu items should be avoided in most circumstances.

Smaller stuff #

• Updated Konvex to Qt6, I still plan on sitting down with it and getting it ready for review.
• Participated in the AMA today.
• Rebased and integrated lots of fixes that were stalling due to lack of an author around to rebase.

I hope to see you next month with more KDE stuff!

Qt 6.7 comes with some new and exciting APIs for window management in Qt Quick. In this blog post we'll look at the changes, and what use-case they open up.

This a lazy and anti-rant post… I want to shine a light on the fantastic KDE software that I use daily. You can do similar things with GNOME and whatever else, but that’s for someone else to write. I have some bias because I have contributed to several of these applications, but that doesn’t detract from the point that I depend on them daily.

Screenshot of KMail from kde.org

I check my work and personal mail using KMail. I’m one of those lucky few that checks my mail from two IMAP-compliant servers, so I steer clear from Outlook/GMail. I keep track of tasks, events and meetings using Merkuro. I can keep tabs on my calendar since the time applet is synced thanks to Akonadi. I really enjoy and use the integration between these Akonadi applications, such as accepting invitations to meetings which are automatically recorded into my calendar.

My work uses Rocket.Chat, and I use Ruqola for interacting with that:

Screenshot of Ruqola from kde.org

Even when not working, I still use KDE software! One of them is drawing, and I use Krita for that (which is a great application in general, you should use it!) It’s completely replaced Procreate and Clip Studio Paint which I used before. I really like it’s integrated brush engines and default brush set, along with all of it’s built-in functionality like animation support. I even use Krita when sketching on-the-go or in bed now instead of Procreate, since my Lenovo Yoga runs Linux and KDE Plasma. When I edit videos, my program of choice is Kdenlive (which is a great application in general, you should use it!) It does everything I want it to do, honestly I have very little trouble with it but my needs are minimal.

Screenshot of Kdenlive from kde.org

My primary chat platform is Matrix, so of course I use NeoChat as my preferred client everywhere I can. I chose Mastodon as my Twitter-replacement, and I use Tokodon so much that I don’t even open up their web interface anymore! The less I have to run in the browser the better, in my opinion.

Screenshot of Tokodon from kde.org

There’s also lots of small utilities that I use, such as Spectacle for screenshots and quick screen recordings. I use Kate for all of my text editing, such as this post right now! Gwenview is my image viewer of choice too. Of course I use Okular for reading the occasional PDF. Can’t forget about Okteta when I’m trying to dissect some binary file.

Screenshot of Kasts from kde.org

I even use KDE applications for consuming media, too. I use PlasmaTube to feed my YouTube addiction. I like to put videos in picture-in-picture and even added that to the next release, meaning I can stop using the web interface for Invidious. I have started listening to some podcasts, and have been using Kasts for those. I elarned recently that it even can sync via NextCloud!

Upcoming #

Here’s some software I recently learned about, and want to start using soon:

• Accessibility Inspector, which is a KDE-based alternative to GNOME’s Accerciser.
• Codevis, a code visualization program, I used it once before but I need to try it again.
• Fielding, a REST API client. I plan to expand it’s features further so I don’t have to depend on Insomina.
• Powerplant, something to help keep your plants. I only have one plant to keep right now, so this is the perfect time to learn how to use it!

Hope this sheds some light on my favorite applications, and gives you ideas for using them! I enjoy how fast these applications are, and how integrated and nice they all look together. I couldn’t go over every single one, but maybe I can expand in the future.

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

Where have all the flowers gone? | daverupert.com

Tags: tech, web, blog, culture

Good continuation of “where have all the websites gone?”. They’re still here but we changed, all the more reason for curating.

https://daverupert.com/2024/01/where-have-all-the-websites-gone/

The Open Source Sustainability Crisis

Tags: tech, foss, sustainability

Yes, there’s something to do in this space. More funding is necessary, some form of platform might help… but it definitely won’t be enough.

https://openpath.chadwhitacre.com/2024/the-open-source-sustainability-crisis/

Platform Tilt: Documenting the Uneven Playing Field for an Independent Browser Like Firefox - Open Policy & Advocacy

Tags: tech, firefox, web, browser, google, apple, microsoft

Nice call from Mozilla to make this public. This way it is very obvious where the blockers are on some platforms.

https://blog.mozilla.org/netpolicy/2024/01/19/platform-tilt/

Victory! Ring Announces It Will No Longer Facilitate Police Requests for Footage from Users | Electronic Frontier Foundation

Tags: tech, surveillance

Still a long way to go but definitely a move in the right direction.

https://www.eff.org/deeplinks/2024/01/ring-announces-it-will-no-longer-facilitate-police-requests-footage-users

Fairly Trained launches certification for generative AI models that respect creators’ rights

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

This is an interesting move, we’ll see if this certification gets any traction.

https://www.fairlytrained.org/blog/fairly-trained-launches-certification-for-generative-ai-models-that-respect-creators-rights

Nightshade: Protecting Copyright

Tags: tech, ai, machine-learning, copyright

The tooling to protect against the copyright theft of image generator models training is making progress. This will clearly turn into an arm race.

https://nightshade.cs.uchicago.edu/whatis.html

Reading QR codes without a computer!

Tags: tech, barcode, qrcode

Another great way to understand how QR codes work.

https://qr.blinry.org/

Journey to the Centre of the JVM — Daniel Spiewak

Tags: tech, java, multithreading, memory

Very interesting talk. It gives a good idea of some properties of the JVM memory model. It also shows how the CPU architecture properties can leak all the way through changing some of the behavior of JVM code. Too bad this particular thing seems badly documented on the JDK side.

https://www.youtube.com/watch?v=EFkpmFt61Jo

That’s it! I’m making my own C++ package manager…

Tags: tech, c++, dependencies, buildsystems

Clearly I can understand the feeling. That’s yet another attempt at a solution for this… it’s young, will it get traction? Has the benefit of being kind of simple, too simplistic maybe?

https://david-delassus.medium.com/thats-it-i-m-making-my-own-c-package-manager-555eecbf7d2e

Re: The Case for Rust (in the base system)

Tags: tech, rust, c++, safety, system

Very interesting contribution to the FreeBSD hackers mailing list. Gives quite a good background about Rust, C++ and safety. Debunks a few claims you can easily hear in many places as if they were common knowledge.

https://lists.freebsd.org/archives/freebsd-hackers/2024-January/002876.html

On‐demand JSON: A better way to parse documents? - Keiser - Software: Practice and Experience - Wiley Online Library

Tags: tech, json, parsing, performance, c++

Very interesting approach to JSON parsing. Comes with a very thorough performance analysis.

https://onlinelibrary.wiley.com/doi/10.1002/spe.3313

Handling external API errors: A resumable approach

Tags: tech, api, services, consistency

On the difficulties of dealing with third party APIs. How to handle failures and reach eventual consistency? A few good solutions and patterns are proposed here.

https://thoughtbot.com/blog/handling-errors-when-working-with-external-apis

The most important goal in designing software is understandability | nicole@web

Tags: tech engineering, craftsmanship, quality

Understandability is indeed a very important goal. There are easy ways to improve it in a system.

https://ntietz.com/blog/the-most-important-goal-in-designing-software-is-understandability/

TDD Revisited - Ian Cooper - NDC Porto 2023 - YouTube

Tags: tech, tdd, tests

Nice talks, debunks very well quite a bit of the fallacies around people wrongly practicing TDD. I never realized how the root cause of those fallacies was the misusing of the “unit tests” term instead of “developers test”. This was indeed the wrong term, knew it, but first time I realize how profound the effects were.

https://www.youtube.com/watch?v=IN9lftH0cJc

Trunk Based Development

Tags: tech, version-control

A nice knowledge base about what is probably my favorite branching model. Goes in the variations you can have, the trade-offs and the other techniques you need to bring in for it to work well.

https://trunkbaseddevelopment.com/

On “owning” software - avdi.codes

Tags: tech, economics, cost, licensing, services, foss

Good exploration on how the total cost of ownership is spread depending on how is licensed the software you use and where you get your support from. I think there’s one point a bit too glanced over in the analysis of the cost for the proprietary SaaS case: what’s the cost of fixing a bug that affect your team? You might be a tiny fish in a large pond, good luck getting attention from support in this case.

https://avdi.codes/on-owning-software/

Lessons learned: 1,000 days of distributed at Atlassian

Tags: tech, atlassian, remote-working

Interesting report about distributed and remote work at Atlassian. They really did their homework. I recommend reading the whole report, they came up with a few original ideas.

https://www.atlassian.com/blog/distributed-work/distributed-work-report

Cancel your meetings if you can live with the outcome - Andy Grunwald

Tags: tech, meetings

Interesting approach to handling meetings. Start thinking about what happens if you’re not there.

https://andygrunwald.com/blog/cancel-your-meetings-if-you-can-live-with-the-outcome/

Bye for now!

KDE’s 6th Megarelease is the is-it-tacky-is-it-awesome name we came up with for the combined release of KDE Frameworks 6, Plasma 6 and KDE Gear’s bundle of apps and libraries. It’s out in a month’s time and it’s the porting of all our libraries and many of our apps to Qt 6. In principle this makes no difference to end users but we still like to make a song and dance about it and there will be new features and old cruft removed which allows for accelarated new features to come shortly. But first it needs testing. So download KDE neon Testing Edition which is build with the Git branches of the soon to be released products and install it either on hardware if you can or on something like Virtualbox (mind on Virtualbox you need to turn on “Enable 3D Accelaration” in Display settings because it uses Wayland, you should also turn on “EFI Special OSes only” if only to feel special).

Many thanks to Carlos and the others who have worked hard to get everything here.

In the beginning, there was C.

That sentence actually could serve as the introduction to a multitude of blog posts, all of which would come to the conclusion “legacy programming conventions are terrible, but realistically we can’t throw everything out and start over from scratch”. However, today we will merely be looking at two ways C has contributed to making language interoperability difficult.

extern "C", but for structs

In the first installment of this series, I mentioned that one blocker to language interoperability is struct layout. Specifically, different programming languages may organize data in structs in different ways. How can we overcome that on our way to language interoperability?

Layout differences are mostly differences of alignment, which means that data is just located at different offsets from the beginning of the struct. The problem is that there is not necessarily a way to use keywords like align to completely represent a different language’s layout algorithm.

Thankfully, there is a solution. In our example used previously, we were using Rust and C++ together. It turns out that Rust can use the #[repr(C)] representation to override struct layouting to follow what C does. Given that C++ uses the same layouting as C, that means that the following code compiles and runs:

// file: cppmodule.cpp #include <iostream> #include <cstdint> struct Foo { int32_t foo; int32_t bar; bool baz; }; void foobar(Foo foo) { std::cout << "foo: " << foo.foo << ", bar: " << foo.bar << ", baz: " << foo.baz << '\n'; } extern { #[link_name = "_Z6foobar3Foo"] pub fn foobar(foo: Foo); } #[repr(C)] pub struct Foo { pub foo: i32, pub bar: i32, pub baz: bool, } fn main() { let f = Foo{foo: 0, bar: 42, baz: true}; unsafe { foobar(f); } }

My proof-of-concept project polyglot automatically wraps C++ structs with #[repr(C)] (and also does so for enums).

The one major downside of this approach is that it requires you to mark structs that you created in your Rust code with #[repr(C)]. In an ideal world, there would be a way to leave your Rust code as is; however, there is currently no solution that I am aware of that does not require #[repr(C)].

Arrays, strings, and buffer overflows

Now that we’ve covered structs in general, we can look at the next bit of C behavior that turned out to be problematic: handling a list of items.

In C, a list of items is represented by an array. An array that has n elements of type T in it really is just a block of memory with a size n * sizeof(T). This means that all you have to do to find the kth object in the array is take the address of the array and add k * sizeof(T). This seemed like a fine idea back in the early days of programming, but eventually people realized there was a problem: it’s easy to accidentally access the seventh element of an array that only has five elements, and if you write something to the seventh element, congratulations, you just corrupted your program’s memory! It’s even more common to perform an out-of-bounds write when dealing with strings (which, after all, is probably the most used type of array). This flaw has led to countless security vulnerabilities, including the famous Heartbleed bug, (you can see a good explanation of of how Heartbleed works at xkcd 1354).

Eventually, people started deciding to fix this. In languages like Java, D, and pretty much any other language invented in the last 25 years or so, strings (and arrays) are handled more dynamically: reading from or writing to a string at an invalid location will generally throw an exception; staying in bounds is made easy by the addition of a length or size property, and strings and arrays in many modern languages can be resized in place. Meanwhile, C++, in order to add safer strings while remaining C-compatible, opted to build a class std::string that is used for strings in general (unless you use a framework like Qt that has its own string type).

All of these new string types are nice, but they present a problem for interoperability: how do you pass a string from C++ to Rust (our example languages) and back again?

Wrap all the things!

The answer, unsurprisingly, is “more wrappers”. While I have not built real-life working examples of wrappers for string types, what follows is an example of how seamless string conversion could be achieved.

We start with a C++ function that returns an std::string:

// file: links.cpp #include <string> std::string getLink() { return "https://kdab.com"; }

We’ll also go ahead and create our Rust consumer:

// file: main.rs mod links; fn main() { println!("{} is the best website!", links::getLink()); }

Normally, we would just create a Rust shim around getLink() like so:

// wrapper file: links.rs extern { #[link_name = "_Z7getLinkB5cxx11v"] pub fn getLink() -> String; // ??? }

However, this doesn’t work because Rust’s String is different from C++’s std::string. To fix this, we need another layer of wrapping. Let’s add another C++ file:

// wrapper file: links_stringwrapping.cpp #include "links.h" // assuming we made a header file for links.cpp above #include <cstring> const char *getLink_return_cstyle_string() { // we need to call strdup to avoid returning a temporary object return strdup(getLink().c_str()); }

Now we have a C-style string. Let’s try consuming it from Rust. We’ll make a new version of links.rs:

// wrapper file: links.rs #![crate_type = "staticlib"] use std::ffi::CStr; use std::os::raw::c_char; use std::alloc::{dealloc, Layout}; extern { #[link_name = "_Z28getLink_return_cstyle_stringv"] fn getLink_return_cstyle_string() -> *const c_char; } pub fn getLink() -> String { let cpp_string = unsafe { getLink_return_cstyle_string() }; let rust_string = unsafe { CStr::from_ptr(cpp_string) } .to_str() .expect("This had better work...") .to_string(); // Note that since we strdup'ed the temporary string in C++, we have to manually free it here! unsafe { dealloc(cpp_string as *mut u8, Layout::new::()); } return rust_string; }

With these additions, the code now compiles and runs. This all looks very convoluted, but here’s how the program works now:

1. Rust’s main() calls links::getLink().
2. links::getLink() calls getLink_return_cstyle_string(), expecting a C-style string in return.
3. getLink_return_cstyle_string() calls the actual getLink() function, converts the returned std::string into a const char *, and returns the const char *.
4. Now that links::getLink() has a C-style string, it converts it into a Rust CString wrapper, which is then converted to an actual String.
5. The String is returned to main().

There are a few things to take note of here:

1. This process would be relatively easy to reverse so we could pass a String to a C++ function that expects an std::string or even a const char *.
2. Rust strings are a bit more complicated because we have to convert from a C-style string to CString to String, but this is the basic process that will need to be used for any automatic string type conversions.
3. This basic process could also be used to convert types like std::vector.

Is this ugly? Yes. Does it suffer from performance issues due to all the string conversions? Yes. But I think this is the most user-friendly way to achieve compatible strings because it allows each language to keep using its native string type without requiring any ugly decorations or wrappers in the user code. All conversions are done in the wrappers.

Implementation

Based on the concepts here, I’ve written a (non-optimal) implementation of type proxying in polyglot that supports proxying std::string objects to either Rust or D. In fact, I’ve taken it a bit further and implemented type proxying for function arguments as well. You can see an example project, along with its generated wrappers, here.

Next up

Interoperability requires lots of wrappers, and as I’ve mentioned, polyglot can’t generate wrappers for anything more complex than some basic functions, structs, classes, and enums. In the next installment of this series, we’ll explore some viable binding generation tools that exist today.

The post Mixing C++ and Rust for Fun and Profit: Part 2 appeared first on KDAB.