Planet KDE

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.

When running Linux software and encountering a crash, and you make a bug report about it (thank you!), you may be asked for backtraces and debug symbols.

And if you're not developer you may wonder what in the heck are those?

I wanted to open up this topic a bit, but if you want more technical in-depth look into these things, internet is full of info. :)

This is more a guide for any common user who encounters this situation and what they can do to get these mystical backtraces and symbols and magic to the devs.

Backtrace

When developers ask for a backtrace, they're basically asking "what are the steps that caused this crash to happen?" Debugger software can show this really nicely, line by line. However without correct debug symbols, the backtrace can be meaningless.

But first, how do you get a backtrace of something?

On systems with systemd installed, you often have a terminal tool called coredumpctl. This tool can list many crashes you have had with software. When you see something say "segmentation fault, core dumped", this is the tool that can show you those core dumps.

So, here's a few ways to use it!

How to see all my crashes (coredumps)

Just type coredumpctl in terminal and a list opens. It shows you a lot of information and last the app name.

How to open a specific coredump in a debugger

First, check from the plain coredumpctl list the coredump you want to check out. Easiest way to deduce it is to check the date and time. After that, there's something called PID number, for example 12345. You can close the list by pressing q and then type coredumpctl debug 12345.

This will often open GDB, where you can type bt for it to start printing the backtrace. You can then copy that backtrace. But there's IMO easier way.

Can I just get the backtrace automatically in a file..?

If you only want the latest coredump of the app that crashed on you, then print the backtrace in a text file that you can just send to devs, here's a oneliner to run in terminal:

coredumpctl debug APP_NAME_HERE -A "-ex bt -ex quit" |& tee backtrace.txt

You can also use the PID shown earlier in place of the app name, if you want some specific coredump.

The above command will open the coredump in a debugger, then run bt command, then quit, and it will write it all down in a file called backtrace.txt that you can share with developers.

As always when using debugging and logging features, check the file for possible personal data! It's very unlikely to have anything personal data, BUT it's still a good practice to check it!

Here's a small snippet from a backtrace I have for Kate text editor:

#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 ... #18 0x00007f5653fbcdb9 in parse_file (table=table@entry=0x19d5a60, file=file@entry=0x19c8590, file_name=file_name@entry=0x7f5618001590 "/usr/share/X11/locale/en_US.UTF-8/Compose") at ../src/compose/parser.c:749 #19 0x00007f5653fc5ce0 in xkb_compose_table_new_from_locale (ctx=0x1b0cc80, locale=0x18773d0 "en_IE.UTF-8", flags=<optimized out>) at ../src/compose/table.c:217 #20 0x00007f565138a506 in QtWaylandClient::QWaylandInputContext::ensureInitialized (this=0x36e63c0) at /usr/src/debug/qt6-qtwayland-6.6.0-1.fc39.x86_64/src/client/qwaylandinputcontext.cpp:228 #21 QtWaylandClient::QWaylandInputContext::ensureInitialized (this=0x36e63c0) at /usr/src/debug/qt6-qtwayland-6.6.0-1.fc39.x86_64/src/client/qwaylandinputcontext.cpp:214 #22 QtWaylandClient::QWaylandInputContext::filterEvent (this=0x36e63c0, event=0x7ffd27940c50) at /usr/src/debug/qt6-qtwayland-6.6.0-1.fc39.x86_64/src/client/qwaylandinputcontext.cpp:252 ...

The first number is the step where we are. Step #0 is where the app crashes. The last step is where the application starts running. Keep in mind though that even the app crashes at #0 that may be just the computer handling the crash, instead of the actual culprit. The culprit for the crash can be anywhere in the backtrace. So you have to do some detective work if you want to figure it out. Often crashes happen when some code execution path goes in unexpected route, and the program is not prepared for that.

Remember that you will, however, need proper debug symbols for this to be useful! We'll check that out in the next chapter.

Debug symbols

Debug symbols are something that tells the developer using debugger software, like GDB, what is going on and where. Without debugging symbols the debugger can only show the developer more obfuscated data.

I find this easier to show with an example:

Without debug symbols, this is what the developer sees when reading the backtrace:

0x00007f7e9e29d4e8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5

Or even worse case scenario, where the debugger can't read what's going on but only can see the "mangled" names, it can look like this:

_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE

Now, those are not very helpful. At least the first example tells what file the error is happening in, but it doesn't really tell where. And the second example is just very difficult to understand what's going on. You don't even see what file it is.

With correct debug symbols installed however, this is what the developer sees:

QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x7fe88c001620, event=0x7fe888002c20) at kernel/qcoreapplication.cpp:1064

As you can see, it shows the file and line. This is super helpful since developers can just open the file in this location and start mulling it over. No need to guess what line it may have happened, it's right there!

So, where to get the debug symbols?

Every distro has it's own way, but KDE wiki has an excellent list of most common operating systems and how to get debug symbols for them: https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

As always, double check with your distros official documentation how to proceed. But the above link is a good starting point!

But basically, your package manager should have them. If not, you will have to build the app yourself with debug symbols enabled, which is definitely not ideal.. If the above list does not have your distro/OS, you may have to ask the maintainers of your distro/OS for help with getting the debug symbols installed.

Wait, which ones do I download?!

Usually the ones for the app that is crashing. Sometimes you may also need include the libraries the app is using.

There is no real direct answer this, but at the very least, get debug symbols for the app. If developers need more, they will ask you to install the other ones too.

You can uninstall the debug symbols after you're done, but that's up to you.

Thanks for reading!

I hope this has been useful! I especially hope the terminal "oneliner" command mentioned above for printing backtraces quickly into a file is useful for you!

Happy backtracing! :)

Improving the qcolor-from-literal Clazy check

For all of you who don't know, Clazy is a clang compiler plugin that adds checks for Qt semantics. I have it as my default compiler, because it gives me useful hints when writing or working with preexisting code. Recently, I decided to give working on the project a try! One bigger contribution of mine was to the qcolor-from-literal check, which is a performance optimization. A QColor object has different constructors, this check is about the string constructor. It may accept standardized colors like “lightblue”, but also color patterns. Those can have different formats, but all provide an RGB value and optionally transparency. Having Qt parse this as a string causes performance overhead compared to alternatives.

Fixits for RGB/RGBA patterns

When using a color pattern like “#123” or “#112233”, you may simply replace the string parameter with an integer providing the same value. Rather than getting a generic warning about using this other constructor, a more specific warning with a replacement text (called fixit) is emitted.

testf4ile.cpp:92:16: warning: The QColor ctor taking RGB int value is cheaper than one taking string literals [-Wclazy-qcolor-from-literal] QColor("#123"); ^~~~~~ 0x112233 testfile.cpp:93:16: warning: The QColor ctor taking RGB int value is cheaper than one taking string literals [-Wclazy-qcolor-from-lite QColor("#112233"); ^~~~~~~~~ 0x112233

In case a transparency parameter is specified, the fixit and message are adjusted:

testfile.cpp:92:16: warning: The QColor ctor taking ints is cheaper than one taking string literals [-Wclazy-qcolor-from-literal] QColor("#9931363b"); ^~~~~~~~~~~ 0x31, 0x36, 0x3b, 0x99 Warnings for invalid color patterns

Next to providing fixits for more optimized code, the check now verifies that the provided pattern is valid regarding the length and contained characters. Without this addition, an invalid pattern would be silently ignored or cause an improper fixit to be suggested.

.../qcolor-from-literal/main.cpp:21:28: warning: Pattern length does not match any supported one by QColor, check the documentation [-Wclazy-qcolor-from-literal] QColor invalidPattern1("#0000011112222"); ^ .../qcolor-from-literal/main.cpp:22:28: warning: QColor pattern may only contain hexadecimal digits [-Wclazy-qcolor-from-literal] QColor invalidPattern2("#G00011112222"); Fixing a misleading warning for more precise patterns

In case a “#RRRGGGBBB” or “#RRRRGGGGBBBB” pattern is used, the message would previously suggest using the constructor taking ints. This would however result in an invalid QColor, because the range from 0-255 is exceeded. QRgba64 should be used instead, which provides higher precision.

I hope you find this new or rather improved feature of Clazy useful! I utilized the fixits in Kirigami, see https://invent.kde.org/frameworks/kirigami/-/commit/8e4a5fb30cc014cfc7abd9c58bf3b5f27f468168. Doing the change manually in Kirigami would have been way faster, but less fun. Also, we wouldn't have ended up with better tooling :)

Having ended 2023 with attending 37C3 the new years starts with planning and booking for conferences and events I want to attend in 2024.

My Events in 2024 FOSDEM

February 3-4 in Brussels, Belgium. I’ll be speaking about semantic data extraction in KMail and Nextcloud Mail in the Modern Email devroom.

There’s also going to be a Railways and Open Transport devroom again which I’m particularly looking forward to, and of course the KDE stand.

OSM Hack Weekend

February 24-25 in Karlruhe, Germany (wiki).

Based on historical patterns another such weekend can probably be expected for autumn, and a similar pair of events might also happen in Berlin again. As time permits I’ll try to join those as well.

FOSSGIS Konferenz

March 20-23 in Hamburg, Germany. Together with Tobias Knerr I’ll be hosting a session about OSM indoor mapping.

KDE Akademy

September 07-12 in Würzburg, Germany. It would need a pandemic for me to miss that one.

38C3

And for concluding 2024 there’s then going to be the 38th Chaos Communication Congress (38C3), December 27-30, presumably in Hamburg, Germany again. Ticket supply permitting I’d love to go there and hope we’ll have a KDE presence there again.

What’s (still) missing

Some events aren’t on the list (yet), for various reasons:

• Linux App Summit (LAS) 2024: No official date and location yet. Obviously something I’d attend again as well, however there’s indications it might not be in Europe this time, and intercontinental travel for a three day event is hard to justify for me.
• State of the Map (SotM) 2024: OSM’s global yearly conference I so far have failed to attend in person. Overlaps with Akademy this year though, and also would require intercontinental travel.
• KDE sprints: None scheduled yet, although there have been first discussion for another KDE PIM sprint at least. Time permitting I’ll of course try to attend anything I’m involved with.

Even with all of that it’s still likely incomplete, typically more things come up during the year or I discover new events to attend along the way. I also haven’t seen anything scheduled from Wikidata or the Open Transport community yet.

Events in KDE Itinerary

For planning travel to events it’s helpful to have the event time and location data in Itineray, without having to enter all that manually. Besides supporting some commonly encountered registration/ticketing systems (e.g. Indico, Pretix) it has also been possible to import events by opening, pasting or dropping URLs to a corresponding Mobilizon or other ActivityPub-compatible source, as well as the URL of the event website directly.

For the latter to work, the website needs schema.org semantic annotations describing the event, as e.g. found on the Akademy website. Since a week ago the FOSS event aggregation site // foss.events also has such annotations, so you can easily import any event from there now as well.

FOSDEM 2024 event data imported from foss.events in Itinerary.

Looking forward to an exciting year and meeting many of you at events :)

Why KMines? #

Minesweeper is a tragically underrated puzzle game. While I recall examining the mysterious array of gray squares as a child, it wasn't until adulthood that I took the time to learn the rules of the game. Despite my late start, however, I still count minesweeper as a classic. These days, good minesweeper clones are hard to come by. I settled on GNOME's Mines for a while, but as the look of GTK applications on my QT-based KDE Plasma Desktop sets my teeth on edge, I ditched it for KMines in short order. While I enjoyed the game, I found the themes shipped with KMines a bit dated, so I thought I'd make my own.

The Clean Blue Dark KMines theme The Drama #

I didn't quite know what I was getting into when I started working on my themes. I had expected there'd be a simple way to add themes through the KMines settings menu, or by dropping an SVG somewhere in your file-system. If only it were so simple. Adding a theme to KMines requires setting up a full-on KDE development environment, re-compiling KMines from source each time you want to test it, and then, of course, submitting a merge request to the git repository. Thanks to the help of some very patient souls in various KDE Matrix channels, I was able to work through all of this, but I found the process so tricky that I submited a second merge request, this time to the repository for develop.kde.org, for a page documenting the process. Now I realise that some developers out there are going to read through this and wonder if I was dropped on my head as an infant, but in my defense, when it comes to software development, I'm a humble designer and Jamstack web developer. This is all very new to me, and I was expecting a much more streamlined process for what I saw as simple visual tweaks.

The Clean Blue Light KMines theme Why High Contrast #

When submitting my initial design, a KDE contributor who had been helping me via Matrix pointed out that they found the theme difficult to parse visually as the contrast was quite low. I hadn't considered contrast ratios here, my thinking being that I didn't need to; I was just making one theme among many, after all, and users could choose any theme that worked best for them. After some consideration, however, it dawned on me that my theme would likely be the only modern-looking theme in the release, so it would be ideal if it were as accessible as possible. With this in mind, thanks to the feedback of one helpful individual, instead of one pretty but low contrast theme, I decided to make two modern high contrast themes, one light and one dark, targeting the WCAG AAA standard for contrast.

Coming in Plasma 6! #

With thanks to those KDE contributors who helped make it happen, the merge request containing these two themes scraped by the skin of its teeth past the closing door of a feature-freeze and will be available with Plasma 6 this February!

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

Cat and Girl - 4000 of My Closest Friends

Tags: tech, copyright, law, art, ethics

How does it feel to just want to put something creative out there without being exploited? Very touching comic on the topic.

https://catandgirl.com/4000-of-my-closest-friends/

AI: the not-so-good parts - Xe Iaso

Tags: tech, ai, ethics

As an industry we definitely should think more often about the consequences of our actions. The incentives are indeed pushing us to go faster without much critical thinking.

https://xeiaso.net/talks/2024/prepare-unforeseen-consequences/

OpenAI Quietly Deletes Ban on Using ChatGPT for “Military and Warfare”

Tags: tech, gpt, war, ethics, business

Unsurprising move, they claim it’s for the betterment of mankind but in practice it’s mostly about capturing as much market share as possible.

https://theintercept.com/2024/01/12/open-ai-military-ban-chatgpt/

AI poisoning could turn open models into destructive “sleeper agents,” says Anthropic

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

The tone pointing at “open models” is wrong but the research is interesting. It still proves models can be poisoned (open or not) so traceability and secured supply-chains will become very important when using large language models.

https://arstechnica.com/information-technology/2024/01/ai-poisoning-could-turn-open-models-into-destructive-sleeper-agents-says-anthropic/

Will the new judicial ruling in the Vizio lawsuit strengthen the GPL?

Tags: tech, foss, law

Very interesting ruling, this opens the door to more parties being able to sue to enforce the GPL not just the authors.

https://blog.tidelift.com/will-the-new-judicial-ruling-in-the-vizio-lawsuit-strengthen-the-gpl

Unity’s Open-Source Double Standard: the ban of VLC - mfkl

Tags: tech, vlc, 3d, foss, business

This is a stupid move on Unity’s part… they’re built on LGPL but ban others in their store to have LGPL dependencies. Shame on them. Good move from Videolabs though, wish them lots of success.

https://mfkl.github.io/2024/01/10/unity-double-oss-standards.html

Pluralistic: The Cult of Mac

Tags: tech, apple, interoperability, security

Apple keep indeed attracting a bunch of cultists… and this allows them to keep abusing their other customers.

https://pluralistic.net/2024/01/12/youre-holding-it-wrong/#if-dishwashers-were-iphones

Each Facebook User is Monitored by Thousands of Companies – The Markup

Tags: tech, facebook, attention-economy, surveillance

Some more insights on the extent of the companies snitching to Facebook.

https://themarkup.org/privacy/2024/01/17/each-facebook-user-is-monitored-by-thousands-of-companies-study-indicates

Meta/Threads Interoperating in the Fediverse Data Dialogue Meeting yesterday

Tags: tech, fediverse, facebook

Interesting notes, there seems to be good faith on the Meta side for now… but this leaves more questions than answers still.

https://reb00ted.org/tech/20231208-meta-threads-data-dialogue/

Where is all of the fediverse?

Tags: tech, fediverse, self-hosting, infrastructure

Interesting stats, not that easy to gather. This gives a good overview of where the fediverse instances are hosted though.

https://blog.benjojo.co.uk/post/who-hosts-the-fediverse-instances

Making my website faster - Cliffle

Tags: tech, web, fonts, css, optimization

Nice set of tricks to optimize load and render time of webpages.

https://cliffle.com/blog/making-website-faster/

LeftoverLocals: Listening to LLM responses through leaked GPU local memory | Trail of Bits Blog

Tags: tech, gpu, machine-learning, security

Interesting vulnerability, not all vendors are impacted though. GPU memory leaks can have unforeseen impacts.

https://blog.trailofbits.com/2024/01/16/leftoverlocals-listening-to-llm-responses-through-leaked-gpu-local-memory/

Speedbump: TCP proxy for simulating variable, yet predictable network latency

Tags: tech, networking, tools

Looks like an interesting tool to simulate difficult network conditions.

https://github.com/kffl/speedbump

Willow Specifications

Tags: tech, protocols, data, networking, p2p

Looks like an interesting protocol for resilient peer to peer data stores. Let’s see how it spreads.

https://willowprotocol.org/

Beware of misleading GPU vs CPU benchmarks

Tags: tech, cpu, gpu, computation, economics

A good reminder that even though GPU tend to be faster, the added complexity and price might not be worth it in the end.

https://pythonspeed.com/articles/gpu-vs-cpu/

Using pre-commit hooks makes software development life easier

Tags: tech, git, craftsmanship, tools

Can definitely recommend. The pre-commit project also make managing those a breeze.

https://itnext.io/using-pre-commit-hooks-makes-software-development-life-easier-ef962827aa96

Using “will” and “should” in technical writing | James’ Coffee Blog

Tags: tech, documentation, writing

Pick your words wisely. If it does happen every time use “will”.

https://jamesg.blog/2024/01/17/will-should/

Everyday storytelling for engineers. The CAO Method.

Tags: tech, engineering, communication

Nice suggestion for talking about your work in various type of situations. Definitely worth trying to frame it like this.

https://tonyfreed.substack.com/p/everyday-storytelling-for-engineers

Does Working from Home Boost Productivity Growth? | San Francisco Fed

Tags: tech, remote-working, economics

Interesting report. Apparently so far a more widespread use of remote work doesn’t seem to boost of hinder productivity growth at large scale.

https://www.frbsf.org/economic-research/publications/economic-letter/2024/january/does-working-from-home-boost-productivity-growth/

The warrior culture of ancient Sparta did some weird things to their society.

Tags: history, politics

Or why nationalism and war mongering are unwelcome dead ends. I never understood this fascination for Sparta by some people… if you look at what it was without some misplaced romanticism, it definitely looked like an horrible and paranoid environment to live in.

https://slate.com/news-and-politics/2024/01/sparta-300-warriors-history-slavery.html

Bye for now!

Ruqola 2.1 Beta (2.0.81) is available for packaging and testing.

Ruqola is a chat app for Rocket.chat. This beta release will build with the current release candidate of KDE Frameworks 6 and KTextAddons allowing distros to start to move away from Qt 5.

URL: https://download.kde.org/unstable/ruqola/
SHA256: 2c4135c08acc31f846561b488aa24f1558d7533b502f9ba305be579d43f81b73

Signed by E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell [email protected]
https://jriddell.org/esk-riddell.gpg

Disclaimer: I am not one of KDE's masterminds or spokespersons. I am a mere bystander with few unimportant commits. I follow KDE's ecosystem and other developments in the free software world. In the following, I share some thoughts and my personal opinion.

Talks about new programming languagesWe already have a new programming language!Problems with C++ remainWhat can be done?Discuss our future

It’s a pleasure to be on the OpenUK New Year’s Honours list for 2024. There’s some impressive names on there such as Richard Hughes of Packagekit and other projects at Red Hat, Colin Watson who was at Ubuntu with me and I see is now freelance, Mike McQuaid was previously of KDE but is now trying a startup with Mac packager Workbrew for Homebrew.

OpenUK run various activities for open tech in UK countries and KDE currently needs some more helpers for a stall at their State of Open Con in London on Feb 6 and 7 February, if you can help do get in touch.

KDE’s 6th releases will happen next month bringing with it the refresh of code and people that a new major version number can bring, I think KDE’s software in the coming year will continue to impress.

My life fell apart after some family loss last year so I’ve run away to the end of the world at Finesterre in Galicia in Spain for now, let me know if you’re in the area.

The new year has just begun and we have six weeks left before the final release! The most noticeable change since my last post is obviously that we have decided on the wallpaper to be used in Plasma 6.0! But of course there’s more going on under the hood than just that.

My desktop isn’t usually that tidy

I actually spent most of my time in Qt Wayland rather than KDE code lately but more on that in an upcoming blog post once all my changes have been integrated. Nevertheless, there are still plenty of Wayland-related and other improvements on the Plasma, Frameworks, and KDE Gear side to talk about here.

XDG Foreign Everywhere

After my previous experience of revamping the KWin Window Killer and having learned how to use the XDG Foreign Protocol (a Wayland protocol for exporting a surface to enable a different process to attach to it), I looked at all the places we have a helper application show a window in another application. This is actually done a lot more often than I thought and thus I added API in KWindowSystem for both exporting and importing windows on Wayland.

Since the export side is only really needed on Wayland, I added (un)exportWindow(QWindow*) functions in KWaylandExtras (a utility namespace with Wayland-specific windowing system functionality) along with a windowExported signal once that has been performed. Setting a foreign parent windows can already be done by using KWindowSystem::setMainWindow or even just QWindow::fromWinId. Both of them take a WId (a long int usually) which means that a string-based handle received from the compositor doesn’t play well with the existing APIs.

In case of KWindowSystem I just added a QString overload. The clever part is that it also understands a long int in a string, thus you just feed a token received as a string from QCommandLineParser or stdin verbatim into the API (even supports using 0x and 0b prefixes) and have it do the right thing on all platforms. That way you only have to special-case the export part for Wayland but the importing side will “just work”. Lifetime of the objects is tied to the actual window and there’s no additional resource tracking logic needed on the application side besides calling those functions, pretty neat.

Both kdialog and keditfiletype support XDG Foreign handles for their relevant attach/parent argument now. It is important to have all “public” command-line tools adjusted for 6.0, thereby knowing it’s a Qt 6 build is enough to tell whether it will understand the string or refuse to start on being unable to parse it as a number. If you know of any other tools that might need adjustment, please do tell. The KAuth Framework for executing privileged tasks as well as the KDE PolicyKit agent also learned how to create and understand those handles. This ensures the password prompt is attached to the window it came from (e.g. when changing settings). There’s still plenty of places where KAuth is used without setting a parent window on the executed action but at least the infrastructure is all there now.

More fractional scaling goodness

Of course I accomplished a few more fixes for fractional scaling. The pixmap created by Item.grabToImage now captures it with the proper scale factor. I also made a fix for then using that grab result in a Drag handler (not merged yet). Together with another fix for Plasma’s Folder View and a KWin change I did a while ago we should finally have crisp pixmaps when dragging icons on the desktop. That was a lot more entangled than I anticipated with the scale factor discarded at pretty much every opportunity along the way.

Left to right: Original item, original blurry capture, fixed rendering (salmon for illustration)

TextInput and TextEdit also re-render themselves immediately when the scale factor changes. This fixes sticky notes on the desktop being blurry until interacted with as well as spin boxes and other editable controls in apps like System Settings. The issue was addressed for labels some time ago but similar treatment was needed for input fields, too.

I talked about Dolphin’s icon rendering in September and now file thumbnails are properly rendered with fractional scaling, too, both in the main file view and the information sidebar. Méven Car worked on high-dpi support for thumbnailers previously and the switch to Frameworks 6 was a good opportunity to change the wire-format used for communication between app and thumbnailer to use a floating-point number for the scale factor instead of an integer. While at it, I also fixed the “tick” icon to accept input on the address bar. Furthermore, mouse cursor theme previews in System Settings are also scaled smoothly. Incidentally, KWin’s bouncing cursor (startup feedback) is scaled according to the cursor size on Wayland, too.

Speaking of Dolphin, the Places sidebar no longer lets you drag one place into another one. While I found that Windows also lets you do that (macOS doesn’t), I don’t really see the point, unless you want to drag your Documents folder to an external hard drive directly? More importantly, though, it makes re-arranging places very finicky since the drop area in-between places is very small. Obviously, it is still possible to drag files and folders from the main view and elsewhere onto an entry in the Places panel to copy/move/link it to the folder or hard drive in question.

In order to fix KWin’s screen edge triggering inadvertently while selecting text in an application and nudging the corner of the screen, I disabled them completely when a mouse cursor is pressed. However, I wasn’t entirely happy with this (and people in the comments weren’t either) and now it’s possible to drag a file into a screen edge and peek at the desktop to drop it there. Making the new overview effects work with drag and drop is going to be a lot more work, so it’s left for a later time. I’d also love to be able to switch virtual desktops while dragging a file, just like we do when touching the screen edge while dragging a window.

That irksome Konsole font bug finally squashed!

On the subject of broken rendering, I also found a way to improve font rendering in Konsole after the removal of QFont::ForceIntegerMetrics in Qt 6. From what I can tell Konsole entirely relies on the fact that all characters are the same width. Apparently, even with a Monospace font under certain conditions thanks to Hinting and Kerning this may not be entirely the case. Forcing full hinting on the font used seems to ensure that no such trickery is going on. If you still see broken fonts when text is highlighted or selecting it, check that your distribution doesn’t force any particular font settings here.

Anything else Okular’s annotation bar now showing proper page numbers and annotation contents

As a heavy user of Okular’s fantastic annotation feature where you can add labels, sticky notes, shapes, lines, and all sorts of other markers to a (PDF) document, I slightly improved the Annotation sidebar: Custom page numbers are now displayed (pages in a PDF aren’t necessarily strictly numbered but there can be Roman numerals for the index, for example, just like in a real book) and the textual content of the annotation, if any, is shown as well to more easily identify which item is which.

Libksysguard learned SI prefixes for Ampere, Volt, Watt, and Watt-hour units. Should I ever upgrade to a Petawatt solar installation, System Monitor has got me covered. KMessageDialog gained a beep function for playing the relevant notification sound (warning, error, etc), for applications that implement a custom message box and already depend on KWidgetsAddons but don’t want to pull in KNotification just for this. It is now used by Kate’s “Save?” dialog which looks like a message box when saving a single file but because it may also display a list of files is a custom implementation. I also had a look at how to make Qt’s own QMessageBox play the KDE sounds but this is routed though the Qt accessibility framework and I wasn’t sure how to hook into that without jeopardizing more important components of it like the AT-SPI interface.

Do you want to install updates or what?

With the prevalence of Offline Updates (i.e. restarting the system and installing updates in a minimal environment) there’s now a dedicated “Reboot & Install Updates” button on the logout screen to skip installing updates and just reboot. This could surely be extended in the future, e.g. shut down without installing updates or install them now instead of on next boot and so on but at least you can now easily reboot the system without installing updates if you want to.

One of the first changes exclusive to Plasma 6.1: WiFi channel display.

Finally, even though we’re all busy squashing any remaining bugs for the 6.0 release, it has been branched off into the “stable” release branch and the repositories are again open for gentle feature development (which includes anything that needs new translations). I just merged a tiny change exclusive to Plasma 6.1: displaying the WiFi channel number next to its frequency in connection details.

Discuss this post on KDE Discuss.