With the Qt 6.7 release, Qt introduced a wide range of improvement for the text rendering and font shaping.

One element of this is that you can now configure OpenType font features.

Many of the 'new cool' programming fonts have such features integrated. That includes both free fonts like Cascadia Code or paid fonts like MonoLisa.

Let's use the features of Cascadia Code as an example, that is the stuff they promote on their GitHub page:

For example if you set the ss01 feature, you get some alternative italics. The same holds for MonoLisa, there that is the feature ss02. Already that shows: these feature are often not very usefully named and very font specific.

Thanks to Waqar and me, with the upcoming KF 6.6 release, one will be able to configure that in Kate and other KTextEditor based applications.

The generic KDE Frameworks font chooser allows now to configure that stuff and KTextEditor will keep these settings around.

See here enabled alternative italics in Kate with the enhanced font chooser still open (look at the SPDX markers in the code):

A remaining issue is how to best handle the configuration saving in a more generic way. Ideas how to add that to KConfig without breaking compatibility of the configuration files we write with older applications would be welcome. For KTextEditor we just add some extra key for just the features that will be ignored by old versions.

This year, I attended FrOScon for the first time . FrOScon is the biggest conference about free and open-source software in Germany. It takes place every year in Bonn/Siegburg (Germany) at the weekend and is free to attend.

For the first time, I was not at a conference to staff a KDE stand. My employer had a stand there, and it was a great occasion for me to meet some colleagues, fellow KDE, and Matrix contributors.

So I spent the majority of my time at the GnuPG stand and discussing many things with Volker, including KDE PIM and the future of KWallet.

I also meet many Matrix community members and am excited to attend the Matrix Conference next month.

All in one, it was a great conference and I hope to see more KDE people there next year and maybe even having out own KDE stand.

Haruna version 1.2.0 is out with a new footer style.

Availability of other package formats depends on your distro and the people who package Haruna.

Windows version:

• haruna-1.2.0-windows-gcc-x86_64.exe
• haruna-1.2.0-windows-gcc-x86_64.7z
• haruna-1.2.0-windows-gcc-x86_64-dbg.7z

If you like Haruna then support its development: GitHub Sponsors | Liberapay | PayPal

Feature requests and bugs should be posted on bugs.kde.org, but for bugs make sure to fill in the template and provide as much information as possible.

Changelog:

1.2.1

• Fixed thumbnail preview popup not resizing after disabling the previews
• Use the same volume component for both footer styles

1.2.0

• Added floating footer/bottom toolbar style with 2 ways to trigger it:
  • on every mouse movement of the video area
  • only when the mouse is in the lower part of the video area
• Removed the docbook and moved its content to tooltips
• Middle clicking the playlist scrolls to the playing item

Every two years, the KDE community selects three goals that serve as focal points for the entire community's efforts in the coming years. This cyclical process of goal-setting and community-wide focus is a great example of KDE's Cumulative Culture in action.

This concept, typically observed in human societies, refers to the ability to build upon previous knowledge and innovations to create increasingly complex and effective solutions. In KDE's case, each cycle of goals represents a new layer of accumulated wisdom, i.e. new features and more stability.

The First Cycle (2018-2020)

The first cycle of goals laid the groundwork with its focus on community growth, privacy, and usability.

• Streamlined Onboarding: Focused on attracting and retaining new contributors by making the onboarding process smoother and more engaging.
• Privacy Software: Prioritized user privacy and security, ensuring KDE software respects user data and complies with security standards.
• Usability & Productivity: Aimed to enhance the usability and productivity of KDE software, making it powerful yet easy to use.

The Second Cycle (2020-2022)

The second cycle tackled more complex challenges. Goals like Wayland implementation improvements (which layed the foundation for the Plasma 6 release), improving the app ecosystem, and ensuring consistency in design and functionality.

• Wayland: This task aimed at stabilizing Wayland support accross KDE apps.
• All About the Apps: Improved KDE's app infrastructure, enabling more efficient app delivery and better support services.
• Improve Consistency across the Board: Ensured uniformity in design and functionality across KDE software, improving usability and reducing redundancy.

The Third Cycle (2022-2024)

The third cycle, which is currently coming to an end, was about progress and adaptation. A focus to include environmental responsibility, operational efficiency, and inclusive design.

• Sustainable Software: Focused on making KDE software more energy-efficient and environmentally friendly by implementing practices that reduce resource consumption and ensure long-term sustainability.
• Automate and Systematize Internal Processes: Aimed to streamline KDE’s internal workflows by automating repetitive tasks, adding code tests across projects and creating a Quality Assurance team to name a few.
• KDE For All: Seeked to make KDE software accessible and inclusive for all users.

A New Cycle A Comin' (2024-2026)

Now, as we enter the fourth cycle of the KDE Goals, we see the full power of this cumulative process. Each goal, whether fully achieved or not, contributes to the collective knowledge and capability of the KDE community. Ideas and partial solutions from past cycles become a solid foundation of knowledge and experience that support future efforts.

The commmunity is currently voting on the following proposals for the next KDE Goals cycle that will guide our efforts and shape our focus for the coming years:

• Enhancing control and automation: integrate KDE Plasma (and apps) with Smart Home Ecosystems
• Freedom through Better Data and Workflow Organization and Management
• KDE Needs You! 🫵 - Formalise and boost KDE's processes for recruiting active contributors
• KDE-based Text Snippet Expansion
• Sandbox all the things!
• Plasma - A Beacon for Open Design
• Refining and Enriching KDE: Empowering Users with Convenient and Intuitive Features
• Streamlined Application Development Experience
• Unify the Plasma experience
• We care about your Input

KDE Goals at Akademy

The three most voted goals will be announced at Akademy, where there will also be a wrap-up talk about the achievements of the current goals. Also, there will be Birds-of-a-feather (BoF) sessions with the new goal champions.

Join the Matrix room and keep an eye on the website for the latest KDE Goals updates.

KDE's Okular is the first software which got awarded with the Blue Angel label for resource and energy-efficient software products. The certification was based on the first version of the criteria for this product criteria which were introduced in 2020. Now the criteria have been updated. What has changed and what does that mean for KDE?

The revised criteria are available as version 4 on the Blue Angel web site. Only the German version is currently available; the English version will follow shortly.

New software categories

The biggest change is the scope of the label. In the past it was limited to desktop software. With the updated version, the criteria also include software on mobile devices and server software or a combination of these categories, such as a web service with mobile and desktop clients.

The biggest challenge is the measurement of the energy and resource efficiency for these new categories, which requires a more flexible approach and must accommodate scenarios where the measurement cannot be done by inserting a meter in front of the power supply of a single device. The new criteria address this by defining applicable methods for the measurement of mobile and server applications.

The extended scope covers a much broader range of software. For KDE the desktop category is most relevant, but of course a lot of software also interacts with a server component, for example an email client like KMail, which could now be treated and assessed as a combined client-server system to give more realistic and relevant results.

More flexible measurement procedure

The expansion in scope requires an expanded view on the measurement of energy and resource efficiency as well. The first version of the criteria was quite strict and prescribed a very specific measurement procedure on specified reference systems. It was based on a comparison of measurements in a representative usage scenario and in idle mode. This gave a realistic impression of what the usage of a computer program meant in terms of energy consumption.

The new criteria allow for more variation in how the measurements are carried out. The original method is still there, but variations which lead to comparable results are possible as well. This change means that a new criterion was introduced to document the way measurements are done.

In addition to the measurement of the usage scenario, a new type of measurement was introduced. This measures total energy consumption of a production system over a longer period of time. This is particular useful for server applications, where this method can lead to more realistic numbers by averaging resource consumption over real-world usage of multiple users.

For mobile applications, the measurement also has to include the data volume transmitted during a standard usage scenario and the list of URLs it has accessed. This is based on the assumption that large volumes of data transfer imply a higher energy usage. It can also be used to assess if the application is using advertisements or is collecting tracking information. Both are forbidden under the revised Blue Angel criteria.

Ongoing assessment of energy and resource efficiency

The original criteria demanded that updates of the software still run on old reference systems and that the energy consumption does not increase more than 10%. They were not very clear in how exactly this should be proven and documented. Especially for software which is released very often, testing every individual update is impractical. For mobile and even more for server software, update cycles can be very short, up to multiple updates a day.

In the updated criteria there is a more precise way of handling updates. The general idea is still there that updated software run on old hardware and energy consumption not increase too much. But it's not tied to individual updates anymore. The required procedure is to do a measurement at least once a year and publish the results as part of the documentation of the software product. This includes documentation of the measurement setups and any changes to it as well as preserving the history of measurements, so that users can judge for themselves how much energy and resource usage is increasing over time.

This procedure clarifies the requirments and opens a pragmatic way of measuring updates. It implies a certain burden on updating documentation.

Consequences for KDE and Okular

KDE holds the Blue Angel label for its PDF viewer Okular. This is desktop software and the standard usage scenario doesn't include any network access. That means that the expanded scope does not change anything for the existing certification. The revised criteria open up the opportunity to apply for the Blue Angel label for mobile software, such as KDE Connect, and mixed scenarios which also include server components, but the eco-certification for Okular is covered as it was before.

The more flexible measurement criteria give us more leeway in how we are doing the measurements. We have set up KEcoLab for being able to regularly do measurements. This setup follows the procedure prescribed in the original criteria. As this is still valid, it also means no change for us, and our measurements still fulfill the criteria. However, it gives us more opportunities to improve the lab and doesn't strictly tie us to the original list of reference systems anymore. We might want to take advantage of that.

The documentation of the measurement system is something we have always done in a transparent way, so this also doesn't require any big changes on our side. We have to consider how to best convey this in the documentation of Okular, but this is mostly a question on how we communicate the existing content.

The ongoing assessment of energy and resource efficiency ties very well into how we handle software updates. We have a continuous release stream with frequent updates and incremental changes. This fits the model of the new criteria. We have to review how we include regular updates of the documentation and measurement data in releases, but this again is mostly a question of how we communicate the existing content.

Conclusion

The revised criteria provide a welcome expansion of the Blue Angel to more categories of software and a more flexible way to do energy and resource efficiency measurements. They continue to align well with how KDE develops software in general and Okular in particular, so we do not see any issues with continuing the Blue Angel certification for Okular.

We would be happy if the new version of the criteria would increase adoption of the Blue Angel ecolabel for resource and energy efficient software. Sustainable software is an important topic and the Blue Angel can be one way of making progress in this area more visible to a broad audience.

I finally took an evening to get NextCloudPi installed on a Raspberry Pi 5 with a large-ish NVMe drive. This was not a smooth ride. For your pleasure, this is how I got it working.

First, use Jeff Geerling’s guide to get the Pi booting from the NVMe drive.

Second, use this guide to move from Debian networking to systemd-networkd, but do not hold the avahi-daemon package.

Third, run the NextCloudPi curl install script.

Next up – the migration from my old instance. I have 1.5TB of files on a spin disk connected via USB that I need to move to the new NVMe storage – but that is for another night.

For the record – I do love NextCloud and NextCloudPi, so no finger pointing here, just sharing some frustration and how I got around the issue.

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

Unbundling Profile: MIT Libraries - SPARC

Tags: research, copyright, open-access

It’s good to see major institutions like this get out of contracts with scientific publishing companies. Those unfortunately became mostly parasitic. Open access should be the norm for research.

https://sparcopen.org/our-work/big-deal-knowledge-base/unbundling-profiles/mit-libraries/

Make Firefox Private Again

Tags: tech, mozilla, privacy

Since they unfortunately turned on private attribution by default (why? Mozilla, why?). Here is an easy automated way to turn it off.

https://make-firefox-private-again.com/

Being on The Semantic Web is easy, and, frankly, well worth the bother

Tags: tech, web, semantic

With all those bots and scripts crawling the Web, some of the semantic web vision got silently implemented.

https://csvbase.com/blog/13

Markov chains are funnier than LLMs

Tags: tech, ai, machine-learning, gpt, markov-chains, funny

Interesting musing. The predictability in tone doesn’t make for very funny content indeed. Also as a side-effect this might help people remember that Markov chain are a thing and much less expensive.

https://emnudge.dev/blog/markov-chains-are-funny/

ugh. I picked up a shitty NUC from ewaste…

Tags: tech, security

Scary thread… developers should know better than do this and ship it on devices around the world. Their data is now anyone for the taking and users’ privacy can’t be ensured.

https://digipres.club/@foone/112990331505043510

NetAlert X

Tags: tech, networking, security, tools

Looks like a nice tool to monitor your network.

https://netalertx.com/

Free, OpenSource IPv6 Textbook

Tags: tech, book, ip, networking

Looks like an interesting resource to learn about IPv6.

https://ipv6textbook.com/

Andries Brouwer on the OOM killer

Tags: tech, linux, kernel, memory

Funny musing about the OOM killer. With nice pointers if you want to dive further into the topic.

https://quuxplusone.github.io/blog/2024/08/22/overcommit/

The Closed-Loop Benchmark Trap

Tags: tech, benchmarking

Be sure to pick the right behavior model when you make a benchmark. Otherwise you might just measure the wrong thing.

https://buttondown.com/jaffray/archive/the-closed-loop-benchmark-trap/

What is std::ref?

Tags: tech, c++

A little refresher about std::ref and std::cref. They come in handy sometimes, but also if you don’t realize you need them you’ll generate more copies than necessary.

https://www.sandordargo.com/blog/2024/08/21/std-ref

SIMD Matters :: Box2D

Tags: tech, cpu, simd, performance, physics, simulation

SIMD is hard to use, not all problems can apply to it. But when they can, the performance gain can be great.

https://box2d.org/posts/2024/08/simd-matters/

uv: Unified Python packaging

Tags: tech, python, tools

Looks like there’s another contender for package management for Python. This is sooo fragmented now… this one is compelling though.

https://astral.sh/blog/uv-unified-python-packaging

Common Causes of Memory Leaks in JavaScript

Tags: tech, javascript, memory, leak

There are many ways to create a memory leak in Javascript. Here is a good list of the things to pay attention to.

https://www.trevorlasn.com/blog/common-causes-of-memory-leaks-in-javascript

Toasts are Bad UX – Max Schmitt

Tags: tech, web, frontend, ux

It’s better than no feedback. It’s a bit lazy and far from perfect though.

https://maxschmitt.me/posts/toasts-bad-ux

Reckoning

Tags: tech, web, frontend, ux, criticism

Interesting series about the rise of the javascript frontend framework, the bad practices which came with them and the very real impacts on the users. There are indeed better ways.

https://infrequently.org/series/reckoning/

Don’t Repeat Yourself and the Strong Law of Small Numbers - iRi

Tags: tech, design, programming

This is a good point. The DRY principle has value but the trick is finding the right time to apply it.

https://jerf.org/iri/post/2024/dry_strong/

Code review antipatterns

Tags: tech, codereview

Starts like a satire, but there’s a serious conclusion in the end. Indeed, mind the power dynamics in code reviews. Be nice, steer away from those antipatterns, especially since you might be on the receiving end the next time.

https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatterns/

Interview with Ron Jeffries

Tags: tech, agile, history, criticism

Very nice interview. This is an interesting reflection on the past 20+ years of Agile Software Development.

https://ronjeffries.com/articles/-x024/-v04/8/

Decision Logs

Tags: tech, product-management

Nice way to keep in check how and why behavior changes as the requests from various stakeholders come in.

https://buttondown.com/j2kun/archive/decision-logs/

Bug squash: An underrated interview question

Tags: tech, hr, interviews, debugging

This is indeed a nice way to approach technical interviews. Unfortunately it requires quite some effort to setup and maintain. You also have to find the right bugs to put in the interview and this is a rarity.

https://blog.jez.io/bugsquash/

Bye for now!

Since Plasma 5.18, nearly five years ago, Plasma has shipped with a "telemetry" system. It’s opt-in, allowing users to send a small amount of data back to us.

Was it useful or worth it? It's a question that comes up occasionally, and the answer is mixed. I believe it showed real potential, though the reality of our implementation was somewhat underwhelming and didn't really deliver. There are many lessons learned that are worth sharing with other projects that might face similar endeavours.

The good bits

Where we had data available for topics being discussed it worked. To give two concrete examples from memory:

• A developer claimed, "No one is using a screen smaller than 1024x768," while bumping the minimum size of a window. This was proved wrong; the number of users at 800x600 or even 640x480 is surprisingly high. Still low as an overall percentage, but higher than you would ever intuitively think. Presumably, it's the default for a lot of virtual machines.

• Four years ago, a developer claimed, "No one still uses only OpenGL2; we can change the code to do XYZ." A check of our user base showed it would have affected nearly 5% of our users, so the change was abandoned.

Interestingly, this last topic came up again very recently, as it held back colour management improvements, but in a narrower Wayland-only path and with a fallback. After checking metrics again, the usage was below 1%, so we went ahead with that merge request.

So, are metrics worth it just to stop developers and designers from making nonsense claims out of thin air? Absolutely! 90% of stats are just made up on the spot. Metrics are just as much about preventing changes as it is about sparking changes.

Indirect impact

The other important part is having a more general sense of the landscape. Currently, we have a lot of hard conversations about how quickly we push the move to Wayland. We have voices wanting to maintain support, and we have voices wanting to push quicker. These decisions shouldn't be made just by who can be the loudest. For every individual topic that came up in those discussions, I would always have in mind our current adoption value at the time.

Should we care about Nvidia? Knowing they make up about 25% of our user base makes the decision for us. I ran with an Nvidia card in one machine because of this, implementing Nvidia context loss handling and doing what we could during the Wayland transition
We don't test BSD while developing Plasma, but we also let it hold us back. Should we care about it more or less? My opinion matches exactly what the metrics say.

Some stats and graphs:

Another role of metrics is being a conversation starter—people will fawn over a graph. More topics on Reddit will be about our Wayland usage rather than the topic I'm trying to discuss. I'll focus on Wayland examples beacuse that's a topic close to me.

Wayland adoption over time

I keep tabs on what our metrics show here. We can see the slow increase from under 20% to around 45% over time, showing the progress as both we and the Wayland ecosystem evolved. At Plasma 6, we switched the defaults a small bump in the graph can be seen. but 45% still seemed rather disappointing.

Filtering on just Plasma 6 reveals the true story:

There's still 20% of users switching away, or using a distro with a different default, or having carried over presets, but it's more promising. Interestingly, we can see that the GPU vendor distribution differs between X11 and Wayland.

Problems and lessons learned

Ultimately, despite the positive parts it would be hard to call our telemetry a staggering success. For the handful of examples above, there are a hundreds of cases where we had no data to back anything up. The range of data points was pitiful and it wasn't often used

The viewing tool is really, really important!

Data collection without viewing it is meaningless. As shown above, we often need to drill down and cross-reference filters to extract conclusions.

The original plan was to use the existing UI provided by kuserfeedback, which did not scale at all and quickly fell over. It was designed for high-fidelity data for a small number of users, not what we had.

In a rush, we pivoted to using Grafana because there was already a setup hosted.

It worked—ish, but it’s not designed for this, especially combined with our data structure, which was a manual NoSQL in normal SQL. Every graph needed to be written by hand, and it felt very much like fighting the system rather than working with it. Combined with the limited access permissions granted, it wasn't used by many people.

It being used is the number one indicator of its usefulness!

We need to find a tool specifically designed for visualization and querying datasets (maybe Apache Superset?).

Time-based data just makes noise

Our system sent updates every N days with basically the same data every time. This made writing queries way messier than it should have been. It never added any value; I would always be interested in what the current stats are. As described in the Wayland usage graphs above, if I'm making a Wayland decision, it doesn't matter what most people are using; it matters what people on the latest release are using. We always ended up having to add filters to focus on just the latest version.

The upgrade story needs planning in advance

The amount of data we collected was tiny—some GPU information, screen information, language, and a few other fragments. The plan was to slowly add more and more stats over time, but we hit a wall. Our UX involved the user selecting to enable metrics and it being a fire-and-forget operation.

What do we do when we want to add more data? For example, whether you use an analog or digital clock. We would need to prompt the user and reset their settings in the meantime, which is at odds with it being a setting. The whole thing became such an ordeal that made it not worthwhile.

Wrap up

The project didn't fail, when we had data and it was used it worked, but overall our implementation falls short. I would like to open a discussion at Akademy on how we move forward with our current system potentially starting from scratch treating it more like a survey that we prompt to auto populate and submit each year.

Hello everyone! Time flies and now we’re already in the final week of GSoC. In this blog post I’ll be sharing the progress I’ve made since my last update, focusing primarily on subtitle styling.

Subtitle Editor

The first thing I did was to enhance the existing subtitle editor. The updated editor now serves as an interface for editing ASS events, which include various components. With the new subtitle editor, we can easily modify elements such as the event’s layer, style, margins, and more. I’ve also simplified the effects section, allowing us to control subtitle scrolling by simply adjusting checkboxes and combo boxes for speed, direction, and range.

However, the most significant change is the text field and the buttons above it. To better understand these changes, it’s important to first introduce the relationship between ASS styles and events. In ASS files, each event must be assigned a valid style that applies to the entire event text. Additionally, ASS override tags are special text blocks within events that allow precise control over the styles of different parts of the text, rather than the entire text. (There are some exceptions, like “Set Position.”)

The text field has been enhanced to assist users in inputting ASS override tags using the provided buttons. For instance, when a user clicks the “Toggle Bold” button, tags are automatically inserted or adjusted to toggle the bold style for either the selected text or the text following the cursor if nothing is selected. Additionally, the text field features a highlighter that renders different parts of the tags in distinct styles, making them more distinguishable, and an auto-completer that lists all valid presets as we start typing a tag name.

For those who prefer the previous subtitle editor, which only displays the rendered text, a “Simple Editor” is also available. This editor syncs with the normal editor but displays only the text without tags while rendering some basic tag effects. However, due to the complexities of ASS tag rules, style editing in the Simple Editor can sometimes behave unpredictably. So it’s best suited for simpler use cases before or after editing styles.

Subtitle Manager

Continuing from the previous improvements, the Subtitle Manager is now integrated with style management and has been divided into four sections: File, Event, Style, and Info, which correspond to the four main components of ASS subtitles. Each section, except for the File section, includes a sidebar for switching between different subtitle files. Additionally, when in the Style section, we can drag and drop a style item onto a subtitle file name in the sidebar to efficiently move or copy styles between files. The same functionality is available in the Event section, where we can move or copy an entire layer to another file.

Misc

Style Editor

A new widget, the Style Editor, was created to edit styles and provide a preview.

Convert Old Global Style

Old styles will now be automatically converted to the “Default” style in the new project. Font size, outline, and shadow will be scaled to maintain the original effects.

Different Default Styles for Layers

Now, we can assign different default styles to each layer, which will automatically be applied to a subtitle event when it’s created on the corresponding layer. This feature is especially useful for quickly building a subtitle file with multiple speakers, allowing each speaker to have a distinct style.

Summary

It has been a wonderful summer getting involved in the KDE community and contributing to Kdenlive! I may not be the best at coding, but I’ve learned a lot throughout this journey. Thanks for everyone who has gave me guidence — Eugen Mohr, Farid Abdelnour, and especially my mentor, Jean-Baptiste Mardelle. While GSoC is coming to an end, my journey with KDE is just beginning. After these updates, I plan to continue improving subtitle functions, including making it easier for users to input more ASS override tags and refining the UI and user experience. See you in my next blog :)