Planet KDE

Let’s go for my web review for the week 2024-14. I will be vacationing next week, so I might skip next week post. We’ll see.

German state moving 30,000 PCs to LibreOffice

Tags: tech, foss

Well done LibreOffice! I’d love to see many more announcements like this one.

https://blog.documentfoundation.org/blog/2024/04/04/german-state-moving-30000-pcs-to-libreoffice/

oss-security - backdoor in upstream xz/liblzma leading to ssh server compromise

Tags: tech, ssh, security, supply-chain

Good analysis of the backdoor recently discovered in xz. Really a bad situation. Luckily it was probably detected before it could do any real damage. What’s especially striking is the amount of patience it required, it’s really been put in place over a long stretch of time to reduce chances of detection.

https://www.openwall.com/lists/oss-security/2024/03/29/4

A Microcosm of the interactions in Open Source projects

Tags: tech, foss, community, security

Excellent post showing unhealthy consumer/maintainer dynamics in FOSS projects. This particular example was instrumental in getting the xz backdoor in place.

https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/

Bullying in Open Source Software Is a Massive Security Vulnerability

Tags: tech, foss, security, burnout

You think the xz vulnerability was a one time event? Think again, this kind of bullying with ulterior motives happen regularly to critical projects.

https://www.404media.co/xz-backdoor-bullying-in-open-source-software-is-a-massive-security-vulnerability/

OSQI

Tags: tech, foss, sustainability, quality, security

Definitely a good idea, we’d need several such institutes across the world. Would governments be willing to try this?

https://www.tbray.org/ongoing/When/202x/2024/04/01/OSQI

Keeping your data from Apple is harder than expected | Aalto University

Tags: tech, apple, privacy

Can we let the myth of Apple being a proper steward with data privacy to rest please? I don’t know why people took their claims for granted to start… with so much opacity, it’s not a claim you could trust.

https://www.aalto.fi/en/news/keeping-your-data-from-apple-is-harder-than-expected

A ‘Law Firm’ of AI Generated Lawyers Is Sending Fake Threats as an SEO Scam

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

AI supercharged scam. I guess we’ll see more of those.

https://www.404media.co/a-law-firm-of-ai-generated-lawyers-is-sending-fake-threats-as-an-seo-scam/

AI bots hallucinate software packages and devs download them • The Register

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

You should be mindful of the dependencies you add. Even more so when the name of the dependency has been proposed by a coding assistant.

https://www.theregister.com/2024/03/28/ai_bots_hallucinate_software_packages/

Towards 1-bit Machine Learning Models

Tags: tech, ai, machine-learning, power, energy

Smaller models with smarter architectures and low-bit quantized models are two venues for more efficient use. I’m really curious how far they’ll go. This article focuses on low-bit quantized models and the prospects are interesting.

https://mobiusml.github.io/1bit_blog/

LLaMA Now Goes Faster on CPUs

Tags: tech, ai, machine-learning, gpt, llama, optimization, performance, cpu

Excellent work to improve Llama execution speed on CPU. It probably has all the tricks of the trade to accelerate this compute kernel.

https://justine.lol/matmul/

Zoomer Tries RSS: In Praise of Yarr - tudor’s website

Tags: tech, rss, social-media

More people turning to RSS as a substitute for social media. There’s hope.

https://tudorr.ro/blog/zoomer-tries-rss/

KDE6 release: D-Bus and Polkit Galore | SUSE Security Team Blog

Tags: tech, processes, dbus, kde, security

Interesting article, shows quite well the complexities of D-Bus and Polkit. Unsurprisingly such complexity easily leads to mistakes which can compromise security. This then hints to interesting things to keep in mind when you have to deal with D-Bus and Polkit.

https://security.opensuse.org/2024/04/02/kde6-dbus-polkit.html

NTP Pool - The Internet Timekeeper | RIPE Labs

Tags: tech, ntp, dns, time

Fascinating article which explores the behavior of the NTP Pool. If you wondered how it gives you an NTP server to query, you’ll know the answer. It also covers the consequences of its restrictive approach. This even raises security concerns. Still even though it’s not perfect this keeps being an essential service mostly run by volunteers.

https://labs.ripe.net/author/giovane_moura/ntp-pool-the-internet-timekeeper/

Fast Development In Rust, Part One

Tags: tech, rust, performance, refactoring, type-systems, memory

Nice balanced view on some of Rust characteristics. This is much less naive than some of the “Rust is great” posts out there.

https://blog.sdf.com/p/fast-development-in-rust-part-one

On Garbage Collection

Tags: tech, memory, system

This is indeed a more interesting way to perceive garbage collection. This also lead to proper questions to explore on the topic.

https://xorvoid.com/on_garbage_collection.html

Optimizing SQLite for servers

Tags: tech, databases, sqlite, server, performance, complexity

With some tuning SQLite can go a long way, even for server type workloads. There are still a few caveats but in some case this can reduce complexity and cost quite a bit.

https://kerkour.com/sqlite-for-servers

Enforcing conventions in Django projects with introspection - lukeplant.me.uk

Tags: tech, craftsmanship, developer-experience, django, python

Another example of enforcing conventions using automated checks. This time using Python and Django tricks.

https://lukeplant.me.uk/blog/posts/enforcing-conventions-in-django-projects-with-introspection/

A proposal to add signals to JavaScript.

Tags: tech, javascript, web, frontend

A proposal for data bindings as first class citizens in JavaScript? This could be a good thing indeed.

https://github.com/proposal-signals/proposal-signals

Git as debugging tool - Lucas Seiki Oshiro

Tags: tech, git, version-control

Or why a clean commit history can help quite a lot to find how and why a bug was introduced. This shows a few nice tricks around git log to speed up the process.

https://lucasoshiro.github.io/posts-en/2023-02-13-git-debug/

Improvements to static analysis in the GCC 14 compiler | Red Hat Developer

Tags: tech, c, memory, static-analyzer, compiler

Improved static analysis for C straight from GCC. This is definitely welcome.

https://developers.redhat.com/articles/2024/04/03/improvements-static-analysis-gcc-14-compiler#

On Invariance and Inconsistency

Tags: tech, programming, safety, logic, mathematics

On the importance of invariants and consistent requirements in our trade. Admittedly it’s a long demonstration but it show the point well.

https://www.hansdieterhiep.nl/blog/on-invariance-and-inconsistency/

TDD’s Missing Skill: Behavioral Composition - by Kent Beck

Tags: tech, tests, tdd, design

This is indeed too often overlooked. Producing a test list and picking the tests in the right order is definitely a crucial skill to practice TDD. It goes hand in hand with software design skills.

https://tidyfirst.substack.com/p/tdds-missing-skill-behavioral-composition

Basic Things

Tags: tech, organization, community, craftsmanship

Lots of good advices of course. It goes a long way to improve the quality of the project and the ease to on-board people. This is quite some initial work though.

https://matklad.github.io/2024/03/22/basic-things.html

Programming Apprenticeships

Tags: tech, teaching, learning, pairing

Funny experiment. This shows what you can achieve in terms of teaching and learning during pair programming setups. Shadowing someone is a powerful approach.

https://two-wrongs.com/programming-apprenticeships.html

Mentorship, coaching, sponsorship: three different — and equally important — tools for developing talent - Jacob Kaplan-Moss

Tags: management, coaching, mentoring

This is a nice way to frame the three activities. They help people progress but in different ways.

https://jacobian.org/2024/apr/1/mentorship-coaching-sponsorship/

Ping Me, Please!

Tags: tech, remote-working, asynchronous, communication

When you’re distributed, this is all about asynchronous communication. You can’t walk to a person desk (and you should probably avoid it anyway if colocated).

https://www.yegor256.com/2024/04/01/ping-me-please.html

Bye for now!

With the Qt WebEngine module, Qt makes it possible to embed a webview component inside an otherwise native application. Under the hood, Qt WebEngine uses the Chromium browser engine, currently the de facto standard engine for such use cases.

While the task of writing a brand new standard-compliant browser engine is infamous as being almost unachievable nowadays (and certainly so with Chromium coming in at 31 million lines of code), the Rust ecosystem has been brewing up a new web rendering engine called Servo. Initially created by Mozilla in 2012, Servo is still being developed today, now under the stewardship of the Linux Foundation.

With the browser inherently being exposed to the internet, it is usually the biggest attack vector on a system. Naturally this makes Servo very attractive as an alternative browser engine, given that it is written in a memory-safe language.

A Servo WebView

At KDAB we managed to embed the Servo web engine inside Qt, by using our CXX-Qt library as a bridge between Rust and C++. This means that we can now use Servo as an alternative to Chromium for webviews in Qt applications.

From a QML perspective this component is similar to the Chromium WebView, such as providing canGoBack, canGoForward, loading, title, url properties and goBack, goForward methods. The QML item itself acts in the same way with the contents being rendered to match its size.

import QtQuick import QtQuick.Window import com.kdab.servo Window { height: 720 width: 1280 title: webView.title visible: true ServoWebView { id: webView anchors.fill: parent url: "https://servo.org/" } }

The screenshot below shows a basic QML application with a toolbar containing back, forward, go buttons and an address bar. We use CXX-Qt to define Qt properties, invokables, and event handlers (e.g. touch events) in Rust and trigger events in the Servo engine. Then any update requests from Servo can trigger an update of the Qt side via the Qt event loop.

As we move towards stabilising CXX-Qt at KDAB, investigating real world use cases, such as exposing Servo to Qt, allows us to identify potential missing functionality and explore what is possible when joining the Rust and Qt ecosystems together.

Technical details

Under the hood most of the heavy lifting is done by our CXX-Qt bindings, which already bridges the obvious gap between the Rust and Qt/C++ worlds. However, some further glue is needed to connect the rendering contexts of Servo to being able to render the surfaces into the actual Qt application. Internally, Servo uses surfman, a Rust library to manage rendering surfaces. At the time of writing, surfman supports OpenGL and Metal, with support for Vulkan being planned.

We use surfman to create a new OpenGL context, that Servo then uses for rendering. To render the result into the QtQuick scene, we borrow the surface from Servo, create a new framebuffer object and blit the framebuffer into a QQuickFrameBufferObject on the Qt side.

Future possibilities

Servo development is active again after a period of less activity, therefore the API is evolving and there is work to improve the API for embedders. This could result in a simpler and documented process for integrating Servo into apps. Also as part of the Tauri and Servo collaboration, a backend for WRY could become available. All of these result in many possible changes for the bridge to Qt, as currently this demo directly constructs Servo components (similar to servoshell) but could instead use a shared library or WRY instead.

On the Qt side, there are areas that could be improved or investigated further. For example, currently we are using a framebuffer object which forces use of the OpenGL backend, but with RHI, developers might want to use other backends. A way to solve this for QML would be to change the implementation to instead use a custom Qt Scene Graph node, which can then have implementations for Vulkan, OpenGL etc and read from the Servo engine.

Alternatively Qt 6.7 has introduced a new QQuickRhiItem element, which is currently a technical preview, but can be used as a rendering API-agnostic alternative to QQuickFrameBufferObject.

If this sounds interesting to your use case or you would like to collaborate with us, the code for this tech demo is available on GitHub under KDABLabs/cxx-qt-servo-webview or contact KDAB directly. We also have a Zulip chat if you want to discuss any parts of bridging Servo or CXX-Qt with us.

Come and see us at Embedded World 2024 where we will have the Servo demo and others on display!

 

The post Embedding the Servo Web Engine in Qt appeared first on KDAB.

Recently news went around about explicit sync being merged into Wayland protocols, and in the wake of that I saw a lot of people having questions about it, and why it was such a big deal… So here’s a short-ish explanation of what it is, why it’s needed and what the benefits are over the old model.

Why is synchronization needed?

When applications “render” things, that rendering doesn’t happen immediately. Instead, they effectively record a list of commands with OpenGL or Vulkan for the GPU to execute, and that list then gets handed to the GPU to execute at its own pace.

This is needed for performance reasons: If the CPU had to wait for the GPU to execute each command one by one, both CPU and GPU would often sit around, doing nothing except waiting for the other one to finish its task. By executing commands on the GPU while the CPU does other things, like preparing new commands for the GPU, both can do a lot more work in the same time.

However, in practice, rendering commands don’t stand alone on their own. You might be running one task to render an image, and another one to process the result into something else, or to read it back to the CPU, so that it can be saved as a file on disk. If you do that without synchronization, you might be reading from the image in the middle of rendering, or even before the GPU has started to work on the buffer at all.

The “old” model: Implicit sync

Traditionally with graphics APIs like OpenGL, the necessary synchronization has been done implicitly, without the application’s involvement. This means that the kernel and/or the userspace graphics driver look at the commands the application is sending to the GPU, check which images the commands are using, which previous tasks have to be completed before it, and potentially make the application wait until the dependencies of the commands it wants to execute are resolved.

The so-called dma buffer infrastructure that the Linux graphics stack uses for exchanging images between applications - like Wayland apps and the compositor - also uses the same model. When the render commands from the compositor try to read from an app’s buffer, the kernel will delay the command’s execution until the app has completed its rendering to the buffer.

This model makes it easy for application developers to write correctly working applications, but it can also cause issues. The most relevant of them for Wayland is that the application isn’t aware of which tasks it’s synchronizing to, and it can happen that you accidentally and unknowingly synchronize to GPU commands that don’t have any relevance to your task.

This has been a problem that Wayland compositors have been affected by for a long time: When presenting application images to the screen, compositors picked the latest image that the application has provided, which could still have GPU tasks running on it, instead of an earlier image that’s actually ready for presentation. This meant that sometimes presentation was delayed by the kernel, and you’d see a frame be dropped entirely, instead of just a slightly older image. This issue has been solved for most compositors in the last two years using the kernel’s implicit-explicit sync interop mechanism1; I won’t explain the details of that here, but you can read Michel Dänzer’s blog post about it instead.

The “new” model: Explicit sync

The name already suggests exactly what it does: Instead of the driver or the kernel doing potentially unexpected things in the background, the application explicitly tells the relevant components (driver / kernel / compositor / other apps) when rendering is complete and what tasks to synchronize to in the first place, using various synchronization primitives.

On the application side, explicit sync is used in Vulkan, and the Wayland protocol specifically is used internally by OpenGL and Vulkan drivers to synchronize with the Wayland compositor.

This explicit way of synchronizing GPU commands doesn’t just help avoid accidental synchronizations, it also helps improve performance by reducing the work drivers have to do. Instead of having to figure out the dependencies of tasks from a relatively opaque list of commands, apps just tell them directly.

An important thing to mention here is that we already had a protocol for explicit sync, zwp_linux_explicit_synchronization_unstable_v1, but it shared a limitation with implicit sync: In order to get a synchronization primitive, it still required the GPU commands to be first submitted to the kernel. The new protocol in contrast allows to create and share synchronization primitives without submitting work to the GPU first, which - at least in theory - will allow applications to squeeze a little bit more performance out of your hardware in the future.

Do keep in mind though that these performance improvements are minor. While there may be some special cases where implicit sync between app and compositor was the bottleneck before, you’re unlikely to notice the individual difference between implicit and explicit sync at all.

Why the big fuzz then?

If we already have most of the compositor-side problems with implicit sync solved, and explicit sync doesn’t bring major performance improvements for everyone, why is it such big news then?

The answer is simple: The proprietary NVidia driver doesn’t support implicit sync at all, and neither commonly used compositors nor the NVidia driver support the first explicit sync protocol, which means on Wayland you get significant flickering and frame pacing issues. The driver also ships with some workarounds, but they don’t exactly fix the problem either:

• it delays Wayland commits until rendering is completed, but it goes against how graphics APIs work on Wayland and can cause serious issues, even crash apps in extreme cases
• it delays X11 presentation until rendering is completed, but as Xwayland copies window contents sometimes, that still often causes glitches if Xwayland is also using the NVidia GPU for those copies

There’s been a lot of discussions around the internet between people experiencing the issues constantly, and others not seeing any, and now you should know why it doesn’t seem to affect everyone: It’s not a deterministic “this doesn’t work” problem but a lack of synchronization, which means that a lot of factors - like the apps you use, the CPU and GPU you have, the driver version, the kernel, compositor and so on - decide whether or not you actually see the issue.

With the explicit sync protocol being implemented in compositors and very soon in Xwayland and the proprietary NVidia driver, all those problems will finally be a thing of the past, and the biggest remaining blocker for NVidia users to switch to Wayland will be gone.

Developing embedded software is notoriously difficult – how can we simplify the process? Fortunately, there are lots of techniques you can use daily to help streamline your development.

Embracing Automation

The specialized nature of embedded systems extends the ramp-up time for developers and necessitates a higher level of expertise. Automating hardware-specific tasks, such as deploying applications to boards, initializing debuggers, and resetting systems, can significantly reduce the time penalties that embedded developers face. Using automation to streamline setup for new engineers, everyday development routines, and testing workflows not only speeds up development but also ensures consistency.

Prototyping is Vital

Prototyping is an indispensable part of embedded software development. Given the high cost and complexity associated with changes to software and hardware later in a project, early detection of potential issues is invaluable. Embedded prototypes need not be elaborate; rather, they should precisely address specific aspects such as hardware selection, software performance, integration strategies, and user interface design.

Prototyping serves multiple purposes, from assessing hardware performance metrics to conducting preliminary user-interface tests. Importantly, prototypes can also help pre-empt critical issues, form the basis of future test scaffolding, avoid the need to discard early code iterations, and even lay the groundwork for initial development.

Integrate Early and Often

Integration represents a critical phase in development, one that brings together disparate pieces of the software puzzle. This includes various internal components developed by separate teams — like the middleware stack, user interface, and backend services — as well as third-party software. While the temptation might be to delay this challenging step, early and regular integration is the wiser approach. This proactive strategy facilitates the early identification and resolution of issues that are not evident in unit testing, helping to avoid last-minute crises.

Optimize, but Carefully

The famous caution against premature optimization, coined by Donald Knuth in the 1960s, remains relevant today, especially where the interplay between hardware and software leads to complex performance issues in embedded systems. The key is not to avoid optimization but rather approach it with a thorough understanding of your application’s specific performance bottlenecks. Optimizing is both a time-consuming activity and a source of potential bugs, so optimize only when you need to and when you can show it can have a substantial impact. Use tools like perf, hotspot, and various other memory profilers to accurately diagnose performance problems. Once you have a clear understanding of the issues at hand, you can formulate an effective optimization strategy and establish benchmarks to maintain performance standards.

Byte-Wise, Megabyte-Foolish: A Cautionary Tale

It’s important not to lose sight of the forest for the trees. We learned this firsthand when helping a client who optimized their application’s search functionality to an impressive degree, only to overlook a major memory drain caused by an inefficient background image file format. This oversight led to unnecessary memory consumption that eclipsed the benefits gained by optimizing their search feature’s memory use – a reminder to consider the broader implications before optimizing.

Best Practices

For those looking to delve deeper into the intricacies of embedded system design, our guides, Designing Your First Embedded Linux Device and Best Practices: Embedded Development provide insights and a wealth of detailed best practices to ensure your project begins and stays on a solid foundation.

If you want to learn more about embedded Linux, come talk to us at Embedded World 2024 (9th-11th April) in Nürnberg: KDAB at EW24.

The post Streamlining Strategies for Embedded Software Development appeared first on KDAB.

If you have used a moderately complex application there are chances that you have interacted with what is called a “modal” dialog. A modal dialog is a dialog that requires you to close/address it before you can continue interacting with the main application window. This can be implemented by the application in a straightforward manner but compositor didn’t know if a dialog was modal or not.

That is until now the new xdg-dialog-v1 protocol allows applications to mark their dialogs as modal or not modal. This allows the compositor to adapt its behavior according to this hint. For example when trying to activate the main window it can activate the modal dialog instead. It also enables KWin to use the darkening effect on the parent window on Wayland.

I implemented support for the protocol into KWin and Qt which will be part of the Plasma 6.1 and Qt 6.8 releases respectively. The protocol was created from functionality in GTK and Mutter by Carlos Garnacho and I am happy seeing the overall Wayland eco-system now being able to benefit from it.

Welcome to the latest development and community news curated for you by the Krita-promo team.

Development report

Official Recap of February’s Online Development Meeting

Last month we provided highlights of the video meeting led by Halla, Krita’s Maintainer. She has since published a post on Krita.org presenting the challenges and opportunities that came out of that meeting.

One of the largest projects this year is porting Krita from Qt5 to Qt6 (Qt is the framework upon which Krita is built). This is a major change and will require serious development time. We invite you to read more about the considerations of this project as well as other ideas the Krita team is currently discussing and changes that have taken place within Krita’s development team. You can access it here.

Highlights of this month

• YRH tackled a feature request to prevent the canvas from shifting position when toggling canvas-only mode. Deif_Lou assisted by also merging a fix addressing a jump in canvas position.

• Grum999 identified an opportunity to improve grids and guides management such that settings are now saved in Krita documents. The grid offset on/off toggle was improved so that user settings are retained. Isometric grids may now be measured more accurately (Note: the original code was preserved and is now called “Isometric Legacy” to ensure compatibility with older documents).

• The most recent text tool merge from Wolthera for 5.3 means Krita can now store units (relative units for letter spacing and font size). Wolthera reports that about half the properties are now implemented.

  There should have been a video here but your browser does not seem to support it. (Video created by Wolthera)

• Stable and unstable nightly builds are back following the migration to GitLab CI, with the exception of macOS which is being worked on. On Android, Krita will no longer be built for the 32-bit x86 architecture.

Community report March 2024 Monthly Art Challenge

Krita-Artists members outdid themselves by creating 41 images for Mythmaker’s challenge: Marvellous Metal. The quality and calibre of the entries made it tough to choose only two when it was time to vote. Elixiah emerged the winner with these two images:

Vintage Forgotten Ford by elixiah Wildkat-Engine by elixiah

Elixiah asked MangooSalade and jimplex, who tied for second place, to choose the April challenge and they have come up with a good one! Our new topic is Animal Curiosity and this time there is an additional challenge. Read all about it here.

We’re Asking for Ideas

Mythmaker started a very positive conversation about improving the way images are selected for the featured artwork banner on krita-artists.org website. We have had nomination processes in place for some time which have been somewhat effective (and you’ll see the results of our first featured artwork poll in the next section) but we haven’t landed on a system that makes it easy to nominate artwork and is manageable administratively. Take a glance at some of the proposed ideas – something in there might trigger a new idea for you to share.

Featured artwork

We held our very first monthly poll for the Krita-Artists featured artwork banner. Five images were added to the banner so thank you for nominating and voting. Dragon Courier by desenhunos was the #1 pick.

The March/April nomination thread will be open until April 10, 2024. Here’s how you can participate.

Noteworthy plugin

HCL Sliders by Lucifer “HCL Sliders is a color slider plugin with various hue/colorfulness/lightness models for use with the sRGB color profile and its linear counterpart.” More details about the plugin’s capabilities can be found in Lucifer’s post.

Tutorial of the month

Wrap Around Mode by David Revoy In just two minutes, you’ll learn what makes this feature so powerful.

Notable changes in code

This section has been compiled by freyalupen. Mar 6 - Mar 31, 2024

Stable branch (5.2.2+):

Bugfixes:

• File Formats: PNG - Fix lines in export of 32-bit CMYK images to PNG, by preventing multiple color conversions. (BUG:475737) (merge request, Rasyuqa A H (Kampidh))
• Usability - Fix a jump in canvas position when panning after going to Canvas-Only mode. (commit, Deif Lou)
• Linux: KDE Plasma - Fix Krita's menu not appearing in Plasma's global menu. (BUG:483170) (merge request, Halla Rempt)
• Text Tool - Fix a crash when pasting font family name into rich text editor and saving changes without hitting enter first. (BUG:484066) (merge request, Igor Danilets)

Features:

• General - Tweak the Welcome Page. New/Open File labels moved beside the icons. Recent file thumbnails have a tinted background. (merge request, Agata Cacko)
• General - Remove the development fund banner from the Welcome Page, as it was ineffective. (commit, Halla Rempt)

Unstable branch (5.3.0-prealpha):

Features:

• Text - Allow keeping track of relative font units (em). (merge request, Wolthera van Hövell)
• Enclose and Fill Tool - Support gap closing in the Enclose and Fill tool. (commit, Deif Lou)
• Enclose and Fill Tool - Add "Include contour regions" option to the "All regions" method in the Enclose and Fill tool. (commit, Deif Lou)
• Vector Layers - Add an option to disable/enable anti-aliasing on Vector Layers. (merge request 1, merge request 2, Grum 999)
• Grids and Guides Docker - Various improvements to Grid and Guides. Grid and Guide properties are now saved into .kra files. New type of isometric grid that ensures the cell lengths match. (merge request, Grum 999)
• Animation Dockers - Add Lock Docker button to animation dockers. (merge request, reinold rojas)
• Scripting - Add various methods to Scratchpad API related to fill, zoom, and pan. (merge request, Grum 999)

Bugfixes:

• Layer Stack- Fix a crash when using color labeled layers as a reference for selection if color label includes a mask. (BUG:480601) (commit, Deif Lou)
• SVG - Fix saving 'paint-order' tag for non-text shapes. (commit, Dmitry Kazakov)
• Wide Gamut Color Selector- Fix Wide Gamut Color Selector shortcut popup closing immediately if the cursor is moving while triggering it. (merge request, reinold rojas)
• Usability - When switching to and from Canvas Only mode, keep the canvas in the same position. (merge request, Maciej Jesionowski)

These changes are made available for testing in the following builds:

• Stable "Krita Plus" (5.2.2+): Linux - Windows - Android (arm64-v8a / arm32-v7a / x86_64)
• Unstable "Krita Next" (5.3.0-prealpha): Linux - Windows - Android (arm64-v8a / arm32-v7a / x86_64)

(macOS builds will be available in the future.)

We are happy to announce the release of Qt Creator 13!

We’re thrilled to announce that due to the incredible engagement and enthusiasm from our community, the Kubuntu Council has decided to extend the submission deadline for the Kubuntu Brand Graphic Design Contest! Originally set to close at 23:59 on March 31, 2024, we’re giving you more time to unleash your creativity and submit your designs. The new deadline is now set for 23:59 on Saturday, 6th April 2024.

The decision comes in response to multiple requests from community members who are keen on participating but needed a bit more time to polish their submissions. We’ve been overwhelmed by the vibrant community response so far and are eager to see more of your innovative designs that embody the spirit of Kubuntu.

New Timeline:

• Extended Submission Deadline: 23:59, Saturday, 6th April 2024
• Review by Kubuntu Council: Sunday, 7th April 2024
• Announcement of Results: Monday, 8th April 2024, at 20:00 UTC

The results will be announced via an update on the Kubuntu website, so stay tuned!

This extension is our way of saying thank you for the incredible effort and participation from the Kubuntu community. We want to ensure that everyone who wishes to contribute has the opportunity to do so. Whether you’re putting the finishing touches on your design or just getting started, now is your chance to be part of shaping the visual future of Kubuntu.

We look forward to seeing your creative concepts and designs. Let’s make this contest a showcase of the talent and passion that defines our community. Good luck to all participants, and thank you for making Kubuntu not just a powerful Linux distribution, but a vibrant community as well.

For contest details, submission guidelines, and to submit your work, visit the official Kubuntu Brand Graphic Design Contest page on our website. Let’s create something amazing together!

The Kubuntu Council

Additional Information may be found in the original Kubuntu Graphic Design Contest Post

Apply now: Contest Page

Qt 6.7 is out with lots of large and small improvements for all of us who like to have fun when building modern applications and user experiences.

Introduction

Hi! I’m Krish, an undergraduate student at the University of Rochester studying Computer Science and this KDE Season of Code I’m working on implementing package management features from RKWard into Cantor via a GUI. I’m being mentored by Alexander Semke.

In an effort to improve usability and functionality, this project seeks to strengthen Cantor's capabilities as a scientific computing platform by incorporating package management tools modeled after those found in RKWard and RStudio. The goal is to create an intuitive graphical interface within Cantor for managing packages in R, Octave, Julia, and other languages.

Set up development environment for Cantor

• Used virt-manager to setup an “Kubuntu” virtual machine
• Installed dependencies for Cantor
• Open a terminal emulator and in your favorite shell:

Digging into RKWard's package management system

RKWard, an open-source, cross-platform integrated development environment for the R programming language, implements package management using R's built-in package management system and provides a GUI to simplify package installation, updating, and removal. This writeup will discuss the technical aspects of package management in RKWard.

Broadly, RKWard leverages R's built-in package management functions, such as install.packages(), update.packages(), and remove.packages(), to handle package management tasks. These functions interact with R's package repository (CRAN by default) and local package libraries to perform package-related operations.

RKWard's package management GUI is built on top of these R functions, allowing users to perform package management tasks without directly interacting with the command-line interface. The GUI provides a more user-friendly experience and enables users to manage packages with just a few clicks.

When a user requests to install or update a package, RKWard performs the following technical steps:

• Dependency resolution: RKWard checks for dependencies required by the package and resolves them using R's available.packages() and installed.packages() functions. If dependencies are not satisfied, RKWard prompts the user to install them automatically.
• CMake Configuration: The FindR.cmake script is used during the compilation of RKWard to locate the R installation and its components, including the R library directory. This information is necessary for RKWard to interface with R and manage packages.
• Package download and installation: RKWard downloads package source code or binary files from CRAN or other repositories using R's download.file() function. The packages are then installed using install.packages() with appropriate options, such as specifying the library directory and installing dependencies.
• Package library management: RKWard installs packages in the R library directory, which is typically located in the user's home folder. The library directory can be configured in RKWard's settings. RKWard ensures that packages are installed in the correct library directory, depending on the user's R version and operating system.
• Integration with R Console: RKWard includes an embedded R console, which allows users to see the output of package management commands and interact with them directly if needed. Error Handling: RKWard provides error messages and troubleshooting advice if package installation or loading fails. This can include issues like missing dependencies, compilation errors, or permissions problems.
• Package loading: After installation, RKWard loads the package into the current R session using R's library() or require() functions, making its functions and datasets available for use.
• RKWard supports package management on various platforms, including Windows, macOS, and Linux. On Windows and macOS, RKWard typically installs packages as pre-compiled binaries for improved performance and ease of installation. On Linux, RKWard installs packages from source, which may require additional development libraries or tools to be installed on the user's system.

RKWard also supports installing packages from local files, Git repositories, and other sources by providing options to specify custom package repositories or URLs. This flexibility allows users to manage their R packages according to their specific needs.

In summary, RKWard implements package management using R's built-in package management functions and provides a user-friendly GUI to simplify package installation, updating, and removal. By leveraging R's package management system, RKWard enables users to manage their R packages efficiently and effectively, regardless of their operating system or R version.

Next Steps

• Begin implementing package management features in Cantor.
• Focus on creating a consistent and user-friendly interface for package management.

Marknote 1.1.0 is out! Marknote is the new WYSIWYG note-taking application from KDE. Despite the latest release being just a few days ago, we have been hard at work and added a few new features and, more importantly, fixed some bugs.

Marknote now boasts broader Markdown support, and can now display images and task lists in the editor. And once you are done editing your notes, you can export them to various formats, including PDF, HTML and ODT.

Export to PDF, HTML and ODT

Marknote’s interface now seamlessly integrates the colors assigned to your notebooks, enhancing its visual coherence and making it easier to distinguish one notebook from another. Additionally, your notebooks remember the last opened note, automatically reopening it upon selection.

Accent color in list delegate

We’ve also introduced a convenient command bar similar to the one in Merkuro. This provides quick access to essential actions within Marknote. Currently it only creates a new notebook and note, but we plan to make more actions available in the future. Finally we have reworked all the dialogs in Markdown to use the newly introduced FormCardDialog from KirigamiAddons.

Command bar

We have created a small feature roadmap with features we would like to add in the future. Contributions are welcome!

Packager section

You can find the package on download.kde.org and it has been signed with my GPG key.

Note that this release introduce a new recommanded dependencies: md4c and require the latest Kirigami Addons release (published a few hours ago).

It’s again time for a new Kirigami Addons release. Kirigami Addons is a collection of helpful components for your QML and Kirigami applications.

FormCard

I added a new FormCard delegate: FormColorDelegate which allow to select a color and a new delegate container: FormCardDialog which is a new type of dialog.

FormCardDialog containing a FormColorDelegate in Marknote

Aside from these new components, Joshua fixed a newline bug in the AboutKDE component and I updated the code examples in the API documentation.

TableView

This new component is intended to provide a powerful table view on top of the barebone one provided by QtQuick and similar to the one we have in our QtWidgets application.

This was contributed by Evgeny Chesnokov. Thanks!

TableView with resizable and sortable columns

Other components

The default size of MessageDialog was decreased and is now more appropriate.

MessageDialog new default size

James Graham fixed the autoplay of the video delegate for the maximized album component.

Packager section

You can find the package on download.kde.org and it has been signed with my GPG key.

While everyone is busy analyzing the highly complex technical details of the recently discovered xz-utils compromise that is currently rocking the internet, it is worth looking at the underlying non-technical problems that make such a compromise possible. A very good write-up can be found on the blog of Rob Mensching...

"A Microcosm of the interactions in Open Source projects"

Μαζί με το openSUSE, το Arch και το Debian, το Fedora είναι μία από τις «τέσσερεις μεγάλες» διανομές Linux. Ανάγεται η καταγωγή του στο Red Hat Linux, την αρχική διανομή που βασίζεται σε RPM.

Το Fedora είναι γνωστό για τις τεχνολογίες αιχμής, το πιο πρόσφατο λογισμικό και τις συχνές ενημερώσεις. Είναι επίσης μια από τις λίγες μεγάλες διανομές που αγκαλιάζουν το GNOME vanilla. Τον τελευταίο καιρό, η διανομή έχει γίνει πιο φιλική προς το χρήστη, με οθόνη καλωσορίσματος, υποστήριξη Flatpak και δυνατότητα ενεργοποίησης αποθετηρίων τρίτων κατά τη ρύθμιση.

Ιστορία του Fedora Η ιστορία του Fedora είναι παράλληλη από την ιστορία του Red Hat. Η διανομή ήταν αρχικά γνωστή ως "Fedora Linux", στη συνέχεια "Fedora Core", πριν τελικά καταλήξει στο Fedora.

Το Fedora Linux ήταν ένα αποθετήριο τρίτου κατασκευαστή για το αρχικό Red Hat Linux, ενώ το Fedora Core ήταν μια δωρεάν έκδοση του Red Hat Enterprise Linux που διατηρείται από την κοινότητα. Σήμερα, το Fedora είναι upstream για το Red Hat Enterprise Linux και χρησιμεύει ως μια καλή προεπισκόπηση του τι πρόκειται να γίνει στην "πληρωμένη" έκδοση Workstation.

Ενώ είναι κοινοτικό έργο, το Fedora προφανώς χρηματοδοτείται από τη Red Hat, η οποία ανήκει πλέον στην IBM.

Αξιοσημείωτα χαρακτηριστικά του Fedora Με μια τόσο μακρά ιστορία, τα επιτεύγματα του Fedora είναι αμέτρητα. Ευτυχώς, αυτή η διανομή έχει πολλά πράγματα αυτή τη στιγμή, επομένως δεν υπάρχει λόγος να επιστρέψουμε στην αρχαία ιστορία για τα κυριότερα σημεία.

1. Κυκλοφορεί με το αυθεντικό GNOME ως προεπιλογή Ένα από τα μεγαλύτερα πλεονεκτήματα του Fedora είναι η κυκλοφορία του με το αυθεντικό GNOME.

Θα νομίζατε ότι επειδή το GNOME είναι ένα από τα "δύο μεγάλα" περιβάλλοντα επιφάνειας εργασίας Linux και είναι τόσες πολλές διανομές που το χρησιμοποιούν, ότι το GNOME θα ήταν κοινό για όλους, αλλά όχι. Σήμερα, οι περισσότερες διανομές που κυκλοφορούν με το GNOME περιλαμβάνουν πολλές τροποποιήσεις που προσπαθούν να κάνουν το GNOME να συμμορφώνεται με τις συμβάσεις GUI της δεκαετίας του '90.

Το Fedora δεν το κάνει αυτό. Αντίθετα, παρέχει ένα από τα πιο "καθαρά" και πιο ενημερωμένα παραδείγματα του GNOME.

2. Φιλικό προς το χρήστη Ενώ πολλές διανομές ξεπερνούν τα όρια για να βοηθήσουν τους νέους χρήστες με προγράμματα εγκατάστασης γραφικών και οθόνες καλωσορίσματος, κανείς δεν περίμενε πραγματικά να κάνει κάτι αντίστοιχο το Fedora. Αλλά το έκανε. Το Fedora υποστηρίζει το Flatpak out-of-the-box εκτός από τα αρχεία RPM.

Επιπλέον, μπορείτε να ενεργοποιήσετε τα αποθετήρια τρίτων κατά τη διάρκεια της εγκατάστασης. Κατά την εγκατάσταση, σας υποδέχεται μια χρήσιμη, γραμμική οθόνη καλωσορίσματος που εξηγεί τα βασικά στοιχεία της διεπαφής χρήστη, τις χειρονομίες και τις συντομεύσεις.

3. Προσφέρει λογισμικό αιχμής Το Fedora ενημερώνεται κάθε έξι μήνες, δεν έχει έκδοση LTS, ώστε να λαμβάνετε πάντα τις πιο πρόσφατες ενημερώσεις και η πιο πρόσφατη έκδοση είναι πάντα η κορυφαία έκδοση.

Πέρα από τις συχνές αναβαθμίσεις, το Fedora κερδίζει τους περισσότερους αντιπάλους του στη κυκλοφορία ως προεπιλεγμένο λογισμικό αιχμής, ανοιχτού κώδικα. Ήταν η πρώτη μεγάλη διανομή που άλλαξε από το X11 στο Wayland και από το PulseAudio στο PipeWire.

4. Το Fedora είναι αξιόπιστο Δεν βλέπετε συχνά μια διανομή να είναι ταυτόχρονα αξιόπιστη με λογισμικό αιχμής.

Όταν το Fedora εισάγει θεμελιώδεις αλλαγές, όπως τα παραπάνω παραδείγματα, είναι καλό σημάδι ότι αυτές οι τεχνολογίες είναι επιτέλους ώριμες. Τότε βλέπετε άλλες διανομές που ακολουθούν αργά.

Αν θέλετε να ζείτε στα άκρα, υπάρχουν εκδόσεις ανάπτυξης του Fedora όπως το Rawhide.

Εκδόσεις Fedora Το Fedora προσφέρει τρεις κανονικές εκδόσεις και τρεις επίσημες "αναδυόμενες εκδόσεις". Ωστόσο, μόνο δύο από αυτά τα έξι είναι για καθημερινή χρήση από έναν τελικό χρήστη. Θα παραλείψουμε τις "γεύσεις" που εστιάζονται σε διακομιστή και σε IoT.

1. Workstation Το Fedora Workstation είναι η κορυφαία έκδοση του έργου. Διαθέτει την τελευταία τρέχουσα σταθερή έκδοση GNOME και υποστήριξη Flatpak out-of-the-box.

Λήψη: Workstation Fedora (δωρεάν & ανοιχτού κώδικα)

2. Silverblue Η αναδυόμενη έκδοση Fedora Silverblue είναι μια "αμετάβλητη" παραλλαγή του Fedora Workstation. Η κύρια διαφορά είναι ότι οι χρήστες είναι πιθανό να αντιμετωπίσουν προβλήματα με την εγκατάσταση RPM, καθώς το Flatpak είναι η εγγενής μορφή πακέτου του Silverblue.

Λήψη: Fedora Silverblue (δωρεάν & ανοιχτού κώδικα)

3. Kinoite Το Kinoite είναι μια ανερχόμενη έκδοση του Fedora που δεν εμφανίζεται ακόμα στην αρχική σελίδα. Το Kinoite είναι απλώς μια εναλλακτική λύση με "γεύση" KDE Plasma εναλλακτικό του Silverblue.

Λήψη: Fedora Kinoite (δωρεάν & ανοιχτού κώδικα)

4. Sericea Ο δημοφιλής διαχειριστής παραθύρων πλακιδίων Sway προσφέρεται από τη Fedora Sericea με "αμετάβλητο" τρόπο. Κάνει το Sway προσιτό και ενδιαφέρον τόσο στους νέους όσο και στους έμπειρους χρήστες που προτιμούν να μην αλληλεπιδρούν με το περιβάλλον τους μέσω ποντικιού, επιφάνειας αφής ή άλλης συσκευής κατάδειξης. Το Fedora Sericea προσφέρει μια ολοκληρωμένη εμπειρία με μια απλή διεπαφή χρήστη και περιλαμβάνει ελαφριές εφαρμογές για περιήγηση στο web, σύνταξη κειμένου και αναπαραγωγή πολυμέσων.

Λήψη: Fedora Kinoite (δωρεάν & ανοιχτού κώδικα)

Fedora Spins Όπως πολλές διανομές, το Fedora προσφέρει μια ποικιλία εναλλακτικών λύσεων με μια ποικιλία περιβαλλόντων επιφάνειας εργασίας. Το Fedora ονομάζει αυτές τις παραλλαγές "Spins".

1. KDE Plasma Desktop Το KDE Plasma Spin του Fedora αφήνει ανέπαφες τις περισσότερες προεπιλογές του KDE, αλλάζοντας μόνο την ταπετσαρία και το εικονίδιο εκκίνησης εφαρμογών και επιτρέποντας το διπλό κλικ για άνοιγμα/εκκίνηση.

Λήψη: Fedora KDE Plasma Desktop Spin (δωρεάν & ανοιχτού κώδικα)

2. XFCE Desktop Το Fedora XFCE Spin χρησιμοποιεί την παραδοσιακή διάταξη διεπαφής τύπου BSD/Mac. Φαίνεται πολύ ωραίο για ένα ελαφρύ περιβάλλον επιφάνειας εργασίας.

Λήψη: Fedora XFCE Desktop Spin (δωρεάν & ανοιχτού κώδικα)

3. Cinnamon Desktop Παραδόξως, το Fedora προσφέρει το Cinnamon, ένα προϊόν του Linux Mint.

Εδώ το Cinnamon διαθέτει την επωνυμία Fedora, μπλε χρώμα με έμφαση, λεπτή γραμμή εργασιών και λείπει κυρίως τα XApps του Mint. Παρά αυτές τις αλλαγές, είναι αναζωογονητικό να βλέπεις το Cinnamon να χρησιμοποιείται διαφορετικά από ό,τι στο Linux Mint.

Λήψη: Fedora Cinnamon Desktop Spin (δωρεάν & ανοιχτού κώδικα)

4. MATE-Compiz Desktop Κολλημένοι στο χρόνο; Το Fedora MATE-Compiz Spin είναι τέλειο για όσους λαχταρούν τις μέρες δόξας του GNOME 2 Ubuntu και τα εντυπωσιακά εφέ επιφάνειας εργασίας.

Λήψη: Fedora MATE-Compiz Desktop Spin (δωρεάν & ανοιχτού κώδικα)

5. i3 Tiling Window Manager Ναι, το Fedora έχει ακόμη και ένα tiling window manager spin, οπότε τώρα μπορείτε και εσείς να δημοσιεύετε στο r/unixporn. Πέρα από την πλάκα, το i3 είναι ένα από τα πιο δημοφιλή WM για πλακάκια και ένα τέλειο σημείο εκκίνησης για να μπείτε στον κόσμο των tiling WM που βασίζονται σε πληκτρολόγιο.

Αυτή η κατηγορία υπολογιστών προσφέρει ανώτερη απόδοση οθόνης, χαμηλότερο κόστος συστήματος και αυξημένη ταχύτητα αλληλεπίδρασης με τον χρήστη μέσω συντομεύσεων που βασίζονται στο πληκτρολόγιο.

Λήψη: Fedora i3 Tiling WM Spin (δωρεάν & ανοιχτού κώδικα)

6. Sway Tiling Window Manager Το Fedora Sway Spin παρέχει τον δημοφιλές διαχειριστή παραθύρου πλακιδίων Sway. Κάνει το Sway προσβάσιμο και ελκυστικό τόσο για αρχάριους όσο και για προχωρημένους χρήστες που προτιμούν να μην χρησιμοποιούν το ποντίκι, την επιφάνεια αφής ή άλλη συσκευή κατάδειξης για να αλληλεπιδρούν με το περιβάλλον τους. Διαθέτει ελαφριές εφαρμογές για περιήγηση στον Ιστό, επεξεργασία κειμένου και αναπαραγωγή πολυμέσων, το Fedora Sway Spin προσφέρει μια ολοκληρωμένη εμπειρία με ένα μινιμαλιστικό περιβάλλον χρήστη.

Λήψη: Fedora Sway Tiling WM Spin (δωρεάν & ανοιχτού κώδικα)

7. LXQt Desktop Χωρίς να σταματά στα "μεγάλα τρία" περιβάλλοντα επιφάνειας εργασίας, το Fedora προσφέρει επίσης το LXQt. Αυτή η εναλλακτική λύση του LXDE που βασίζεται σε Qt παρέχει μια απλή εμπειρία που μοιάζει με τα Windows XP.

Λήψη: Fedora LXQt Desktop Spin (δωρεάν & ανοιχτού κώδικα)

8. Budgie Desktop Το Fedora Budgie Spin παρουσιάζει το Budgie Desktop, μια πλούσια σε χαρακτηριστικά, μοντέρνα επιφάνεια εργασίας. Αυτό το Spin έχει σχεδιαστεί για να ευθυγραμμίζεται στενά με το upstream Budgie Desktop, παρέχοντας μια εμπειρία σχεδόν βανίλια με ένα επιλεγμένο σύνολο προεπιλεγμένων εφαρμογών που ταιριάζουν καλύτερα με το Budgie.

Λήψη: Fedora Budgie Desktop Spin (δωρεάν & ανοιχτού κώδικα)

9. SOAS (Sugar on a Stick) Αφού εξαντλήθηκαν όλα τα περιβάλλοντα επιφάνειας εργασίας που έχετε ακούσει, το Fedora συνεχίζει να εντυπωσιάζει με το Fedora spin SOAS. Ίσως το γνωρίζετε καλύτερα ως Sugar on a Stick, το οποίο όπως υποδηλώνει το όνομά του είναι Sugar on a bootable USB stick.

Το περιβάλλον επιτραπέζιου υπολογιστή πρώιμης εκμάθησης έγινε ευρέως γνωστό όταν επιλέχθηκε ως το λειτουργικό σύστημα για το έργο OLPC (Ένας φορητός υπολογιστής ανά παιδί). Λήψη: Fedora SOAS Spin (δωρεάν & ανοιχτού κώδικα)

10. Phosh Το Phosh spin παρέχει μια φιλική διεπαφή προς κινητά, βασισμένη στην αφή της οθόνης. Είναι κατασκευασμένο για φορητές συσκευές όπως τηλέφωνα και tablet, αλλά και φορητούς υπολογιστές με οθόνες αφής.

Το Phosh σάς επιτρέπει να χρησιμοποιείτε μια συσκευή που βασίζεται στην αφή για γρήγορη εκκίνηση και εναλλαγή εφαρμογών, καθώς και εύχρηστες ρυθμίσεις όπως το επίπεδο της μπαταρίας και η ισχύς του σήματος χαμηλής τάσης.

Πίσω από αυτήν την επιφάνεια εργασίας βρίσκεται ολόκληρη η συλλογή πακέτων Fedora τα οποία μπορείτε να εγκαταστήσετε και να χρησιμοποιήσετε όπως σας ταιριάζει. Το Phosh είναι χτισμένο σε wayland και άλλες σύγχρονες τεχνολογίες επιτραπέζιων υπολογιστών gnome.

Λήψη: Fedora Phosh Spin (δωρεάν & ανοιχτού κώδικα)

Σε ποιον απευθύνεται το Fedora; Το Fedora δεν είναι μόνο μια πρωτότυπη διανομή, αλλά έχει γίνει και αρκετά φιλικό προς τον χρήστη τα τελευταία χρόνια. Αυτός είναι ένας σπάνιος συνδυασμός, καθώς το Arch αναμφισβήτητα δεν είναι φιλικό προς το χρήστη και το Debian μόλις πρόσθεσε ένα πρόγραμμα εγκατάστασης γραφικών πριν από μερικά χρόνια.

Εάν είστε λάτρης του GNOME, το Fedora είναι η μόνη μεγάλη διανομή που στέλνει μια ενημερωμένη έκδοση του GNOME vanilla. Οι χρήστες Mac και οι νεότεροι που μεγάλωσαν με κινητές συσκευές μπορεί επίσης να εκτιμήσουν το GNOME. Και οι χρήστες φορητών υπολογιστών θα ερωτευτούν τις χειρονομίες της επιφάνειας αφής Wayland για έλεγχο του χώρου εργασίας.

I'm bit late to the train of Plasma 6 related posts... But anyway. I will go through some things I did.

For me working on Plasma 6 was pretty fun, I learned a lot of new things and fixed bunch of bugs and crashes.

The most resourceful ones can find my merge requests, but I am too lazy to link them all.

Things I did

Most of the things I did were a lot more in the background. I hunted down a lot of bugs and crashes, and tried to fix them myself or helped others fix them, in various projects, such as:

• Dolphin
• Plasmashell
• Kwin
• KNS
• And probably a lot of more I have already forgot... :D

But there was A LOT stuff: Around 100 merge requests in total! Pretty much all of them got in, thanks to all the reviews and education other KDE developers provided to me! :)

Again, thanks to everyone who has helped me to work on KDE projects! Thanks for your patience with me and all the knowledge you have parted to me. ❤️ I'll keep doing my best helping KDE projects, be it bug hunting or feature creation.

I have to say my software testing background has been very useful when it comes down to hunting down bugs, and I've learned a lot of things about Qt, C++ and QML. Still got much more to learn though, but that's what makes me so excited about programming!

I think one of the most useful things I've learned is how to use GDB. I can't provide anyone a crash course (at least in this blog post) but it is essential when hunting down weird bugs in plasmashell for example. I love debuggers integrated to editors like using LLDB-DAP in Kate, but sometimes GDB in terminal is all you can use, so it's good idea to learn to use it!

One big thing I worked on with others was fractional scaling related stuff: I didn't do any of the Kwin stuff around it, but I hunted down some weird bugs with window decorations having some weird gaps in them when windows are specific size. Hunting down all these bugs and weirdness took long time, and we're still looking into it, since it seems to be different in every system.. Floating point numbers and computers are very weird combo.

Another more visible thing I did was unifying separator colors and other items, you can find an issue about it here: Frame and outline color consistency and high-contrast setting changes. I have been bothered by the random differences between some elements, which can be especially noticeable in darker colorschemes, so I finally sat down and combed through related codebases. There's likely more to fix though, but there is now easy way for us to add high-contrast support for outlining elements! It just needs doing, and I haven't had the time.. Yet. :)

Things I learned

• GDB is a life saver
• Write down notes. All the time.
  • Journaling is a good idea!
• Working in open source is a lot about the social aspects!
  • Be nice to people! Duh!
  • But also don't let people walk over you!
  • Listen to others, and don't be afraid to share your opinion.
  • Ask many questions and write down the answers.
• Be patient
• Bug triaging is tough, but very important!
• Remember to rest (I'm bad at this)

Things I will do in future

I will continue hunting down various bugs and crashes and fixing them whenever I spot some, or something is raised to me as "hey this looks like something you could do."

I have also started working on couple things related to remote desktop:

• rdp: Proxy and Gateway settings
• Simple KCM for KRDP

Last but not least, I have looked into facelifting our dear Breeze theme, just a lil bit. Nothing drastic, some tell me they don't see any change and some do. But hopefully it would make Breeze look just a lil bit "softer" and "friendlier." :) You can see them here: Slightly rounder elements, slightly lighter outlines

All in all I am very happy with my current job working on KDE projects, fixing bugs and creating new cool things. I also kind of enjoy being a jack-of-all-trades (master of none), since I get to do a lot of different kinds of stuff, from something more "background" like KWin and plasmashell to something more visible like Breeze and Dolphin. Maybe eventually I will specialize around something, but for now I am bit all over the place which is fine by me lol.

I hope that some of my work has helped you as well. :)

I'll keep doing my best and learning more. (And hopefully write more blogposts.. lol.)

Thanks for reading!

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

Google Ordered To Identify Who Watched Certain YouTube Videos

Tags: tech, google, law, surveillance

This is a worrying trend we see in law enforcement a bit everywhere. It’s a bit too convenient to make such requests even though it is unconstitutional.

https://www.forbes.com/sites/thomasbrewster/2024/03/22/feds-ordered-google-to-unmask-certain-youtube-users-critics-say-its-terrifying/

Redis Renamed to Redict - Andrew Kelley

Tags: tech, redis, foss, licensing, community

Indeed, time to leave Redis behind in favor of Redict. It’s not like one can expect new things to come out to such a project.

https://andrewkelley.me/post/redis-renamed-to-redict.html

A Return to Blu-ray as Streaming Value Evaporates | Audioholics

Tags: tech, streaming, movie, copyright, economics

Interesting, with the price hikes and bundles to come, we might indeed see a resurgence in physical media. It will stay niche for sure, but looks like demand is about to grow.

https://www.audioholics.com/news/a-return-to-blu-ray-as-streaming-value-evaporates

How People Create and Destroy Value with Generative AI | BCG

Tags: tech, ai, gpt, creativity, quality

Interesting study on the impact generative AI can have on people performances in business settings. There are a few nuggets in there. In particular anything related to problem solving people do worse with generative AI tools than without. And even worse than that when they’ve been trained (probably due to overconfidence). The place where it seems to help is for more creativity related tasks… at the individual level, but at the collective level creativity decreases due to homogenization. Definitely things to keep in mind.

https://www.bcg.com/publications/2023/how-people-create-and-destroy-value-with-gen-ai?ref=wheresyoured.at

Have We Reached Peak AI?

Tags: tech, ai, gpt, criticism, communication, copyright, law

Very interesting piece. The chances that it is another bubble are high. It’s currently surviving on a lot of wishful thinking and hypothetical. This really feels like borrowed time… I wonder what useful will remain once it all collapses. Coding assistants are very likely to survive. Clearly there could be interesting uses in a more sober approach.

https://www.wheresyoured.at/peakai/

Models All The Way Down

Tags: tech, ai, machine-learning, statistics, bias

Wondering where some of the biases of AI models generating images come from? This is an excellent deep dive into one of the most successful data sets used to train said models. And they’ve been curated by… statistical models, not humans. This unsurprisingly amplifies biases all the way to the final models.

This is an excellent piece, I highly recommend reading it.

https://knowingmachines.org/models-all-the-way#section5

Mozilla fixes two Firefox zero-day bugs exploited at Pwn2Own

Tags: tech, mozilla, browser, security

Those were nasty, good they’ve been patched already.

https://www.bleepingcomputer.com/news/security/mozilla-fixes-two-firefox-zero-day-bugs-exploited-at-pwn2own/

Hotel hotspot hijinks - P.T.C.

Tags: tech, web, automation, wifi

Some captive portals are indeed stupid. Why not automating going through them?

https://peateasea.de/hotel-hotspot-hijinks/

Why x86 Doesn’t Need to Die – Chips and Cheese

Tags: tech, cpu, hardware

Good exploration of the CPU architectures we have nowadays, and why the RISC vs CISC debate doesn’t make sense anymore.

https://chipsandcheese.com/2024/03/27/why-x86-doesnt-need-to-die/

Bump Allocation: Up or Down? • Core Dumped

Tags: tech, memory

Making your own allocator? This is definitely something to consider and measure.

https://coredumped.dev/2024/03/25/bump-allocation-up-or-down/

Why choose async/await over threads? – notgull – The world’s number one source of notgull

Tags: tech, rust, multithreading, coroutine

In which case you want one or the other? This is illustrated in the Rust case which has its own struggles, but the question applies more largely in my opinion.

https://notgull.net/why-not-threads/

Linux Crisis Tools

Tags: tech, production, linux, tools

Good reminder that you want the diagnosis tools in place and working before you get an actual problem in production.

https://www.brendangregg.com/blog/2024-03-24/linux-crisis-tools.html

shelmet 0.6.0

Tags: tech, python, processes, filesystem

Interesting API for running subprocesses and interact with files.

https://shelmet.readthedocs.io/en/latest/

ASON AltScript – Write Data Not Code

Tags: tech, data, json

Might be a good alternative to JSON in some cases.

https://altscript.com/

3D DOM viewer, copy-paste this into your console to visualise the DOM topographically

Tags: tech, web, browser, debugging, frontend

Interesting debug tool for web frontend code. It’d be nice as a browser extension.

https://gist.github.com/OrionReed/4c3778ebc2b5026d2354359ca49077ca

TDD: You’re Probably Doing It Just Fine - The Code Whisperer

Tags: tech, tdd, craftsmanship

All good points. Can we improve? Sure. Does it means we do it bad? No. Just do it more when it makes sense.

https://blog.thecodewhisperer.com/permalink/tdd-youre-probably-doing-it-just-fine

On Tech Debt: My Rust Library is now a CDO

Tags: tech, supply-chain, maintenance, complexity

This is about a Rust library but equally applies to any ecosystem which allows to easily pull a dependency. As soon as you pull them, you need to monitor their health for the sake of your own project.

https://lucumr.pocoo.org/2024/3/26/rust-cdo/

Two open source projects with great documentation

Tags: tech, documentation, architecture

Of course documentation, especially one presenting the architecture, shouldn’t be neglected. It takes time and skills of course.

https://johnjago.com/great-docs/

Bye for now!

Last week I attended this year’s FOSSGIS Konferenz in Hamburg, Germany, focusing especially on topics around indoor navigation and public transport.

Photo by FOSSGIS e.V., CC-BY-SA Indoor Navigation

Tobias Knerr and I hosted an Indoor OSM user meeting which was mainly intended for connecting people working on various aspects of that subject. We ended up overrunning our timeslot by 40 minutes until we were kicked out of the room, I count that as a success.

For continuing this, there’s the quarterly OSM indoor online meetup on June 5th at 18:00 CEST.

Particularly interesting topics for me:

• The multi-floor route visualization and routing profile configuration approaches from the OPENER next team. Their focus is also train stations, so there is a lot of inspiration for KDE Itinerary there.
• Getting the latest update from indoor localization research. Besides Wi-Fi, Bluetooth, UWP, Lidar and IMU-based approaches there’s now also a project using optical SLAM (which is interesting as it doesn’t need special hardware), but much of this isn’t available as FOSS (yet) unfortunately.
• Seeing the progress on the BIM to OSM conversion work and subsequent discussions with train station operators on what it would take to provide/publish (partial) BIM data.

And just because this is called “indoor” data doesn’t mean there is no field work involved. With Hamburg being by far not as flat as one might think, both the venue itself and the nearby city provided some nice examples for tricky to model and visualize vertical structures, which helps a lot with the otherwise often very abstract discussions on how to best represent this in OSM.

• The TUHH campus is built into a hillside, with ground-level entrance on one side being several floors below those on the other side, which makes visualizing the surroundings tricky.
• Hamburg Harburg station is seamlessly connected to a two-story outside pedestrian area, which challenges the current definition of OSM’s level tag.
• The southerns concourse of Hamburg central station is a slightly inclined area starting on the ground floor on the eastern side but connecting to an underground area on the western side. Both our visualization and our router get utterly confused by this at the moment, having seen this myself in person I now at least understand why.
• And if that wouldn’t be enough already, the Landungsbrücken subway/rapid transit station basically combines all of the above.

Public Transport

The other set of topics I was especially interested in was anything regarding public transport and routing, as that could be relevant for Transitous.

• Contact with the openrouteservice team, as we are still missing an OSM router for Transitous to enable full intermodal routing in MOTIS.
• Multiple talks and sessions about improving bike routing, covering OSM-based cycleway quality data analysis and ways on how such data could be used in routing. While we don’t have any (bike) routing in Transitous at all yet, this shows what future expectations for this might look like.
• Research on public transport connectivity, needing higher quality GTFS data as well.

There were also a few opportunities to promote the Open Transport Meetup, to connect more people working in that area as well.

Public administration and Open Data

There increasing regulation requiring public administration to publish data unless there’s a valid reason against that. That’s great of course, but it’s not enough. Data needs to be available in standardized formats and automatically discoverable as well.

A city publishing the location of their street lamps as a spreadsheet is just the first step. It’s of little help as such if for example your usecase is taking lighting into account when doing nighttime pedestrian routing. City- or region-specific apps are not the solution for this, that doesn’t scale and isn’t sustainable.

Instead such information would ideally be jointly maintained in globally unified database, such as OSM or Wikidata. That would also help with the data quality issues often found in official datasets, as lacking a way to upstream fixes also limits their value.

Public administration and Free Software

One of the ideas behind the eco-certifying KDE software was that eco-certification is an established procurement criteria in the public sector for many other products already. Therefore I was happy to see KDE’s Okular mentioned in a panel discussion on public procurement as the first Blue Angel certified application (without anyone from KDE being on that panel).

Another noteworthy aspect for me here was for the first time seeing someone from the public administration questioning the Github monopoly and the risks involved with that. For organisations like KDE and GNOME who run their own infrastructure for exactly that reason this isn’t news, but outside of that bubble this is rarely something people are even aware of.

Conference

And of course I can’t attend a conference without looking for ideas to “steal” for KDE’s Akademy:

• As part of signing up for the event attendees got two 20% discount vouchers for Deutsche Bahn for travel to/from the event (and unlike similar offers at other events those actually applied on top of all other discounts). I yet have to figure out how to obtain that as an event organizer, with Akademy in Germany this year that is of course particularly interesting.
• Lanyards and name badge holders were collected at the end for reuse at the next event.
• Talks were streamed and chat input was considered during the Q&A part as it’s common at many events by now. For BoFs/meetings there was new equipment though which seemed to fare much better in the typical university seminar rooms, “Meeting Owl”. Those seem significantly more expensive than the Jabra conference microphones we used previously though.

Cross-community collaboration

In a session about marketing/promotion of OSM Maik said something along the lines of “we are seen every day in Germany’s prime time news broadcast, yet hardly anyone knows who we are”, which is not much different from the situation for KDE. Our code is in the majority of web browsers, yet hardly anyone using those knows about us. Similarly, the discussion about sustainable funding and moving towards hiring people seemed very familiar.

And there’s likely even more subjects that affect OSM, KDE and any other FOSS/Open Data organisation of that scale, where all of us might benefit from more knowledge exchange and collaboration. Probably also something to discuss after congratulating our friends at GNOME for their new release at next week’s release event in Berlin :)

Marknote, KDE's WYSIWYG note-taking application, is finally ready for it's first release. Marknote lets you create rich text notes and easily organise them into notebooks. You can personalise your notebooks by choosing an icon and accent color for each one, making it easy to distinguish between them and keep your notes at your fingertips.

Personal:

As many of you know, I lost my beloved son March 9th. This has hit me really hard, but I am staying strong and holding on to all the wonderful memories I have. He grew up to be an amazing man, devoted christian and wonderful father. He was loved by everyone who knew him and will be truly missed by us all. I have had folks ask me how they can help. He left behind his 7 year old son Mason. Mason was Billy’s world and I would like to make sure Mason is taken care of. I have set up a gofundme for Mason and all proceeds will go to the future care of him.

https://gofund.me/25dbff0c

Work report

Kubuntu:

Bug bashing! I am triaging allthebugs for Plasma which can be seen here:

https://bugs.launchpad.net/plasma-5.27/+bug/2053125

I am happy to report many of the remaining bugs have been fixed in the latest bug fix release 5.27.11.

I prepared https://kde.org/announcements/plasma/5/5.27.11/ and Rik uploaded to archive, thank you. Unfortunately, this and several other key fixes are stuck in transition do to the time_t64 transition, which you can read about here: https://wiki.debian.org/ReleaseGoals/64bit-time . It is the biggest transition in Debian/Ubuntu history and it couldn’t come at a worst time. We are aware our ISO installer is currently broken, calamares is one of those things stuck in this transition. There is a workaround in the comments of the bug report: https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/2054795

Fixed an issue with plasma-welcome.

Found the fix for emojis and Aaron has kindly moved this forward with the fontconfig maintainer. Thanks!

I have received an https://kfocus.org/spec/spec-ir14.html laptop and it is truly a great machine and is now my daily driver. A big thank you to the Kfocus team! I can’t wait to show it off at https://linuxfestnorthwest.org/.

KDE Snaps:

You will see the activity in this ramp back up as the KDEneon Core project is finally a go! I will participate in the project with part time status and get everyone in the Enokia team up to speed with my snap knowledge, help prepare the qt6/kf6 transition, package plasma, and most importantly I will focus on documentation for future contributors.

I have created the ( now split ) qt6 with KDE patchset support and KDE frameworks 6 SDK and runtime snaps. I have made the kde-neon-6 extension and the PR is in: https://github.com/canonical/snapcraft/pull/4698 . Future work on the extension will include multiple versions track support and core24 support.

I have successfully created our first qt6/kf6 snap ark. They will show showing up in the store once all the required bits have been merged and published.

Thank you for stopping by.

~Scarlett

KEcoLab

Sustainability has been one of three goals at KDE over the past 2 years. One aspect of this goal is to measure the energy consumption of KDE software. To do this, it is necessary to access the lab in KDAB, Berlin, which can now be done remotely using KEcoLab.

KEcoLab (remote-eco-lab) is a KDE Eco project aimed at enabling remote energy consumption measurements for your software using Gitlab's CI/CD pipeline. By automating the measurement process and integrating with the OSCAR statistics tool, developers can make informed decisions about improving code efficiency and obtain software eco-certification with the Blue Angel. This project came to being as part of GSoC 2023 under the mentorship of Volker Krause, Benson Muite, Nicolas Fella and Joseph P. De Veaugh-Geiss. Karanjot Singh is its original developer.

One of the main aims of Season of KDE 2024 is to integrate KEcoLab into Okular's pipeline. Okular is KDE's popular multi-platform PDF reader and universal document viewer. In 2022, Okular was awarded the Blue Angel ecolabel, the first ever eco-certified computer program. You can learn more about KDE Eco here and the process of measuring energy consumption in the KDE Eco handbook.

Deliverables Of The SoK24 Project

1. Integrate KEcoLab into Okular's pipeline.
2. Integrate KEcoLab's pipeline with E2E tests or integration tests.
3. Usage scenario scripts with KdeEcoTest.
4. Bug squashing.

I have been working together with Sarthak Negi for this Season of KDE.

Integrating KEcoLab Into Okular's Pipeline

As mentioned, the main aim for this mentorship is to integrate KEcoLab into Okular's pipeline. Okular, being a Blue Angel certified project, will benefit from having its energy consumption measured either for every release automatically or for specific merge requests via a manual trigger. In this way it is possible to track Okular's energy consumption and make necessary changes to adhere to Blue Angel specifications.

I have had discussions with the Okular team regarding the integration of KEcoLab into their pipeline. This was necessary to make sure that the new addition won't change their existing workflow rules, i.e., there would be no manual work required on their end to trigger the pipeline on every release. At the same time, we wanted to make sure it is possible to manually trigger the measurement process on a case-by-case basis. I'll go into further details below. The email exchange can be accessed here.

I have been testing the pipeline on a test-repo for the past few weeks, which can be accessed here.

The pipeline was tested for the following contexts:

1. Triggering KEcoLab's pipeline for energy measurement:

   a) using Web UI.

   b) pushing the tag through Git.

2. Pipeline runs on triggering it manually through the Web UI.

3. Pipeline does not run on merge request.

4. Prevent pipeline from running on every commit push.

The above was achieved by making use of a combination of GitLab's workflow: rules and GitLab's predefined CI/CD variables. There were several difficulties I faced during this time, notably preventing the pipeline from running on every release and rather restricting it to only major releases. During one of the monthly meetings, however, Volker thought this would not be necessary since there is only one release per month, i.e, for the time being it is not important to cherry pick the release candidates. As it is now, the measurement process will therefore be triggered on every release of Okular. This may change at a later date, and so I will document here some thoughts I had on how to this.

I initially thought about making use of a global variable which would be updated in the .pre stage depending on a comparison between the last and second-to-last tag to determine whether it's a major or minor release. This would be achieved by making use of a regex rule to identify the difference. The way this would work is by adding a rule under every job to check for the value of the variable. However, since the value wasn't persistent, I took a different approach by making use of artefacts which would contain the value required to determine if it's a major or a minor release version. When a measurement should be triggered, and when not, looks something like this:

• v1.8.3 -> v2.0.8 # Pipeline should run

• v2.2.3 -> v2.6.8 # Pipeline should not run

The code looked something like this:

Once I started testing it, I realised that the value of the updated global variable did not persist across jobs. Therefore, using the variable to determine whether the job should run or not was not viable. Additionally, I realized that this approach would still cause the pipeline to run and in any case it would result in a failed pipeline if all the jobs did not run. Since we decided the measurement process can run on every release, I abandoned trying to implement this.

Currently the pipeline is being tested on my fork of Okular here. It's almost ready, we just need to add the test scripts under 'remote-eco-lab/scripts/test-scripts/org.kde.okular' for which this patch has been made.

Bug Squashing

This includes the following:

Updating The Test Script To Comply With The Latest Kate Version (Issue !23)

Kate was one of the first application that KEcoLab had test scripts for. Even though we made use of as many shortcuts as possible, we were still using tabs to navigate around the user interface. This caused a problem: the previous script was made on Kate v21, and with Kate v24 being released the script needed to be updated accordingly. Also, testing the script across different distros highlighted a shortcoming of a bash-script approach: on Ubuntu the file was not being saved as intended, whereas on Fedora the file was being saved. In other words, small differences had potentially significant impacts which could make the script fail. In fact, it is one of the more fragile aspects of this approach to usage scenario scripting, which a semantics-based tool like Selenium doesn't have.

Helping Debug A Test Script On The Remote Lab PC (Issue !29)

There is a usage scenario script that is failing on the System Under Test. Worse yet, we do not know why and currently have no way to visually monitor the issue. This is a real pain point, mainly because we are unsure what may be the underlying problem. The script simulating user behavior doesn't seem to exit after completion, resulting in the lab being stuck in an endless loop. It is only exited when the GitLab runner times out. Since we don't yet have visual output of what is happening on the System Under Test, we are setting up a VNC to monitor what is happening. If anyone is interested in helping debug this, take a look at the remote eco lab job here. Also, check out the discussion at this issue regarding the visual monitoring of what is happening on the remote lab PC.

Test Out And Update The SUS Scripts For Okular In The FEEP Repository (Issue !52)

This mainly involved testing the script and cross-checking everything works. In this case, the shortcuts defined at the very top weren't consistent with the shortcuts used by the script.

Looking To The Future Of KEcoLab

1. Usage scenario scripts with KdeEcoTest. Since KdeEcoTest now supports Wayland thanks to Athul Raj and runs on Windows thanks to Amartya Chakraborty, we can utilize this tool to further enhance the remote lab. The current bash scripts are based on xdotool, which only supports X11 and not Wayland and does not run on Windows. With Plasma 6 now supporting Wayland by default, and many KDE apps being available on Windows, including Okular, this seems to be the right next step for KEcoLab tooling.

2. Setting up a VNC to monitor scripts visually. The problems faced by us have put further emphasis on the need to be able to monitor what is or is not happening on the remote System Under Test. This was also previously considered. From Joseph's notes, based on work done by Nicolas Fella during one of the lab setup sprints, the following approach can be utilized:

# VNC/remote desktop access ## Server Install - apt install tigervnc-standalone-server - echo "kwin_x11 &" >> .vnc/xstartup - echo "konsole" >> .vnc/xstartup ## Start Server - tigervncserver -geometry 1920x1080 ## Client create SSH tunnel: - ssh -N -L 5900:localhost:5901 kde@INSERT_IP_HERE In VNC client, e.g. KRDC: - connect to localhost:5900 It will start a single Konsole window. Use this to start other stuff

If this doesn't work, we may want to reference x11vnc. If anyone has successfully setup VNC before, feel free to reach out as we would appreciate your help!

Interested in Contributing?

If you are interested in contributing to KEcoLab, you can join the matrix channels Energy Measurement Lab and KDE Energy Efficiency and introduce yourself. KEcoLab is hosted here. Thank you to Karan and Joseph as well as the whole KDE e.V. and the wonderful KDE community for helping out with this project. You can also reach out to me via email or on Matrix