It's been almost two years since my last update on this project, what changed? And if you aren't familiar with what I've been working on, here's a quick recap.

The hardware

Here is a graphics tablet I bought a few years ago now, the XP-Pen Artist 22R Pro:

It has a fatal flaw that a lot of non-Wacom tablets share though, it doesn't work that well on Linux! To be more specific, it "works" but has a few problems:

• You can't rebind the pad buttons easily, because it starts in a "compatibility mode" that can only send pre-defined keyboard buttons.
• Using the second stylus button prevents further stylus input. (Before I fixed that, I would train myself not to press that button 🙈)
• The two dials do not function, and if they did they aren't rebindable anyway.

That is not great, especially since it's not the cheapest graphics tablet on the market. So it really sucks that artists can't take advantage of all of it's features on the best operating system. You can achieve some parity with Windows if you use XP-Pen's proprietary user-space driver (which works on Wayland BTW.) This solution isn't satisfying though - I want this thing to work out of the box, using open-source software ❤️

Linux

I have completed the patch for the kernel to add support for this specific tablet. After sitting it on it for a while (due to being busy with other things.) I'm happy to announce it's merged and should be generally available in the upcoming Linux 6.17 release 🎉

(It's technically sitting in linux-next, Linus hasn't merged the HID subsystem yet but I couldn't wait!)

Thank you to the original author Aren Villanueva who wrote the original DIGImend kernel driver. I took his work, rebased it on top of the existing uclogic driver and changed how the many keys and dials were handled among other changes. Some of this work was covered in previous entries in this series, if you're interested.

What this means is regardless of your desktop environment, this tablet is properly initialized and all of the flaws listed in the hardware section will be fixed.

libwacom

I added a descriptor to libwacom for this tablet, which means it shows the correct configuration options under KDE Plasma and GNOME. For example, it will show that the pen has two buttons and not three (which is the fallback):

libinput

I added support for tablet dials in libinput. In layman terms, this means desktop environments like GNOME and KDE are now aware of this feature on your tablet. This has huge implications outside of this specific tablet, for example certain HUION devices also benefit from this. More information on how KDE Plasma uses this is explained in a later section.

Wayland

Thanks to work by Peter Hutterer, the Tablet protocol in Wayland now has support for tablet dials. What this means is that applications can now read tablet dial input and do whatever they want with it, like making it zoom in and out of a canvas.

KDE Plasma

Thanks to work by Nicolas Fella, KWin (the compositor in KDE Plamsa) is now dial-aware and can send them to Wayland-enabled applications beginning in Plasma 6.4. Because of the aformentioned lack of application support however, I added a feature in KDE Plasma 6.5 to rebind dials to custom user actions:

The XP-PEN software allows you to do this too, so having a built-in solution in KDE Plasma would be great! I did just that, and added support for rebinding dials which will show up in the upcoming KDE Plasma 6.5 release. Making them user configurable is meant as a "bridge", as I'm not aware of any applications supporting dials yet.

With this final piece - from top-to-bottom - the entire Linux graphics tablet stack can now take advantage of relative dials like any other hardware feature 🎉

Conclusion

I want to make it clear (especially if you don't know me) that this isn't some hack, or a rushed driver. This is thanks to years of effort, and from multiple parties and ecosystems. I also literally use this driver and KDE Plasma for my hobbies every day, I know it works first-hand.

I also hope this series showcases that the graphics tablet infrastructure in Linux is not stagnant, but actively being worked on by super-talented people every day. In a theoretical future distribution release that has Linux 6.17 and KDE Plasma 6.5, this tablet will work out-of-the-box. (And for other hardware, it's only a matter of time!) We can make the Linux desktop not just usable for artists, but we can executing it better than anything else out there. No more crappy driver software, tablets will work out of the box on an operating system that actually respects you ❤️

To Nicolas, Peter and Aren - you can redeem a beer or drink of choice at your earliest convenience 🍻

If this series has been fascinating for you, then I highly suggest making plans to watch my Akademy 2025 talk in Berlin or online about bridging the gap for artists using Linux and KDE Plasma. I'm going to be covering the amazing progress - especially in our KDE Plasma 6.x series - that's relevant to artists big and small, and also discuss plans for the long road ahead. You also need to follow the KDE account on Mastodon and Bluesky if you haven't already, where we post announcements and sometimes call-to-actions like our recent push to contribute data about graphics tablet hardware!

I also want to remind everyone that one of KDE's current goals is about input, and as it's Goal Champion I've been volunteering and organizing to fix issues like the ones seen above. If you are having trouble with your graphics tablet on the KDE Plasma Wayland session (and it's our fault) then we want to know! Or if you're super happy with KDE and nothing is wrong, we wouldn't mind hearing about that was well 🐸

If you're still addicted to me hearing me talk about improving stuff, here is a sneak peek of the hardware I'm testing in KDE Plasma next:

But that's for another time!

30 Jul 2025 12:00am GMT

Do you want to save your mental energy on solving complex coding challenges instead of fixing syntax issues in code generated by Gen AI? The Qt AI Assistant is the world's first coding assistant that seamlessly embeds a QML linter agent for the prompts you write. The latest release also comes with the ability to configure your LLM.

29 Jul 2025 8:08am GMT

Intro

Apart from setting up a new open source project, it is important to understand how the application works in order to make the changes you need. In this blog I will go over how I find code, understand the application, and my progress so far with the Selection Action Bar.

Searching code

One Stop Shop for Searching

Command Line

grep -rn "<string_to_search>"

QTCreator

ctrl + f
crtl + shift + f

Debug in C++ code

qDebug() << "[Debug] <string_to_display_for_debugger> << <additional_parameters>;

Krita's codebase is massive, so don't expect to understand everything in one day. What is important is knowing how to find code you need to make the improvements you want. Above are some tools I use when looking for code. I would use the command line or QTCreator search functionality to reverse search strings that are displayed in Krita. This helps me find buttons, dropdowns, and tools. When I want to understand the functionality of the application, I will add qDebug in the code. This allows me to perform an action when Krtia is running and display debug information about the functions I added qDebug to.

Progress

Through the use of the the useful tools above, I was able to make the base UI of the floating toolbar in Krita by identifying QPainter class that created the Assistant Tool. I wanted to use Assistant tool as a reference and recreate a similar UI look. For quick learning purposes and proof of concept, when an Assistant Tool widget is active, the floating toolbar is also generated on screen.

Below is a proof of concept for the Selection Action Bar. I used QPainter to 'draw' onto the KisCanvas2 class. This is like using a paintbrush (QPainter) and painting on a canvas (KisCanvas2). There will still need to be some more UI clean up, however I wanted to present my learnings so far.

Conclusion

Making changes in Krita can be challenging, but by using a few simple tools it can make hours turn into minutes for searching what you need. Again, "the hardest part is finding the resources to be successful". I hope this blog post helps whoever is in need of searching Krita or any C++ codebase.

Contact

To anyone reading this, please feel free to reach out to me. I'm always open to suggestions and thoughts on how to improve as a developer and as a person.
Email: ross.erosales@gmail.com
Matrix: @rossr:matrix.org

29 Jul 2025 12:00am GMT

Dear friends, family, and community,

I'm reaching out during a challenging time in my life to ask for your support. This year has been particularly difficult as I've been out of work for most of it due to a broken arm and a serious MRSA infection that required extensive treatment and recovery time.

Current Situation

While I've been recovering, I've been actively working to maintain and improve my professional skills by contributing to open source software projects. These contributions help me stay current with industry trends and demonstrate my ongoing commitment to my field, but unfortunately, they don't provide the income I need to cover my basic living expenses.

Despite my efforts, I'm still struggling to secure employment, and I'm falling behind on essential bills including:

• Rent/mortgage payments
• Utilities
• Medical expenses
• Basic living costs

How You Can Help

Any financial assistance, no matter the amount, would make a meaningful difference in helping me stay afloat during this job search. Your support would allow me to:

• Keep my housing stable
• Maintain essential services
• Focus fully on finding employment without the constant stress of unpaid bills
• Continue contributing to the open source community

Moving Forward

I'm actively job searching and interviewing, and I'm confident that I'll be back on my feet soon. Your temporary support during this difficult period would mean the world to me and help bridge the gap until I can secure stable employment.

If you're able to contribute, GoFundMe . If you're unable to donate, I completely understand, and sharing this request with others who might be able to help would be greatly appreciated.

Thank you for taking the time to read this and for considering helping me during this challenging time.

With gratitude, Scarlett

28 Jul 2025 1:51pm GMT

🎉 Clazy Now Integrates with Clang-Tidy!

I am excited to announce a major improvement to the Clazy project: Clazy now integrates seamlessly with Clang-Tidy!

🧩 One Toolchain, All the Checks

Clazy now provides a plugin (on Unix ClazyClangTidy.so) that allows all its checks to run inside clang-tidy, unifying your static analysis workflow. You no longer need to run two separate tools - just configure Clazy's checks through clang-tidy itself.

This change needed quite a few refactorings to make the existing Clazy codebase more adaptable. In total, changes were spread out to 9 different pull requests to gradually implement the needed changes. Besides implementing the functionality, the testsuite was also adapted to ensure Clazy's clang-tidy provides proper results.

✅ How to Use

To load the plugin:

clang-tidy -load=ClazyClangTidy.so ...

🔒 If the plugin isn't in a standard library path, either add it to your LD_LIBRARY_PATH or provide an absolute path to the plugin file.

Unfortunately, Clang-Tidy needs to have Clazy checks enabled explicitly and does not have a concept of "levels" to group checks. While wildcards like clazy-* would also work, it enables all manual-level checks. Those have more false positives and can hurt performance.

As a helper, you can export environment variables containing the check names to concatenate the desired combination:

export CLAZY_LEVEL0=clazy-overloaded-signal,clazy-connect-by-name,clazy-connect-non-signal,clazy-qstring-comparison-to-implicit-char,clazy-wrong-qevent-cast,clazy-lambda-in-connect,clazy-lambda-unique-connection,clazy-qdatetime-utc,clazy-qgetenv,clazy-qstring-insensitive-allocation,clazy-fully-qualified-moc-types,clazy-unused-non-trivial-variable,clazy-connect-not-normalized,clazy-mutable-container-key,clazy-qenums,clazy-qmap-with-pointer-key,clazy-qstring-ref,clazy-strict-iterators,clazy-writing-to-temporary,clazy-container-anti-pattern,clazy-qcolor-from-literal,clazy-qfileinfo-exists,clazy-qstring-arg,clazy-empty-qstringliteral,clazy-qt-macros,clazy-temporary-iterator,clazy-wrong-qglobalstatic,clazy-lowercase-qml-type-name,clazy-no-module-include,clazy-use-static-qregularexpression
export CLAZY_LEVEL1=clazy-auto-unexpected-qstringbuilder,clazy-connect-3arg-lambda,clazy-const-signal-or-slot,clazy-detaching-temporary,clazy-foreach,clazy-incorrect-emit,clazy-install-event-filter,clazy-non-pod-global-static,clazy-post-event,clazy-qdeleteall,clazy-qlatin1string-non-ascii,clazy-qproperty-without-notify,clazy-qstring-left,clazy-range-loop-detach,clazy-range-loop-reference,clazy-returning-data-from-temporary,clazy-rule-of-two-soft,clazy-child-event-qobject-cast,clazy-virtual-signal,clazy-overridden-signal,clazy-qhash-namespace,clazy-skipped-base-method,clazy-readlock-detaching
export CLAZY_LEVEL2=clazy-ctor-missing-parent-argument,clazy-base-class-event,clazy-copyable-polymorphic,clazy-function-args-by-ref,clazy-function-args-by-value,clazy-global-const-char-pointer,clazy-implicit-casts,clazy-missing-qobject-macro,clazy-missing-typeinfo,clazy-old-style-connect,clazy-qstring-allocations,clazy-returning-void-expression,clazy-rule-of-three,clazy-virtual-call-ctor,clazy-static-pmf

Checks in Clang-Tidy can be disabled when prefixing them with "-", whereas Clazy uses "no-" prefixes. An example clang-tidy command to use all level0 checks, with overloaded-signal being disabled and the qt-keywords manual check being enabled:

clang-tidy -load=ClazyClangTidy.so \
-checks="$CLAZY_LEVEL0,-overloaded-signal,qt-keywords" \
-p my_build_dir mydir/**.cpp

In case you want to speed up linting in the project, run-clang-tidy can be used for parallel execution.

🚧✨ Limitations & Tricks

Unlike using Clazy directly, clang-tidy has its own filter mechanism to only emit warnings from files that were provided as an input. This means if a warning is emitted from a header file and not the ".cpp" file you provide as an input, Clang-Tidy will suppress it. To see those warnings -header-filter=".*" can be added to the command.

💡💬 Getting it & Feedback

The Clang-Tidy plugin is currently not released, and some additional development on various checks is happening. For trying it out, one has to compile the project from source. It is just a simple CMake setup - promise ;) See the instructions for more details: https://invent.kde.org/sdk/clazy/#build-instructions

Any feedback and contributions are appreciated - let's make Clazy better together 😎. Please report bugs or suggestions on https://bugs.kde.org/enter_bug.cgi?product=clazy or https://invent.kde.org/sdk/clazy/-/issues.

27 Jul 2025 12:00am GMT

Welcome to a new issue of This Week in Plasma!

Every week we cover the highlights of what's happening in the world of KDE Plasma and its associated apps like Discover, System Monitor, and more.

This week UI and feature work for Plasma 6.5 continued to progress, along with a bunch of nice technical changes and bug fixes. Have a look:

Notable New Features

Plasma 6.5.0

For supported printers, plasma now tells you when the printer is low on ink! (Mike Noe, link)

Notable UI Improvements

Plasma 6.4.4

Notifications marked as "low priority" or that you've manually configured to now show up in the history now selectively ignore that, and do show up in the history when they arrived during Do Not Disturb mode. The reason for this is that otherwise these notifications would simply vanish, and you'd never get a chance to see them at all. (Niccolò Venerandi, link)

The hitboxes for items on the desktop now match the visual styling; no more clicking in an empty-looking place and getting a file or folder selected despite no hover effect! (Niccolò Venerandi, link)

Plasma 6.5.0

Key repeat has been disabled for a number of global shortcuts that could trigger rapid full-screen flashing if you held down the shortcut, because this risks causing seizures in photosensitive people. Affected actions include toggling Overview, full screen mode, maximize/de-maximize, and inverting the screen colors. (Ritchie Frodomar, link 1, link 2, and link 3)

The "Someone started sharing this screen" notification now appears only after the connection has been fully established and screen sharing has actually begun, rather than at the moment when the connection was initiated. (David Edmundson, link)

The "Confirm deleting network connection" dialog now uses standard KDE styling. (Renner 03, link)

The spacing between menu items in the Global Menu widget is now more consistent with menus in individual windows. (Rebecca Bee, link)

Notable Bug Fixes

Soon

Plasma Browser Integration's browser plugin no longer breaks random features or various known video conferencing websites when its enhanced media controls setting is active. (Kai Uwe Broulik, link)

Plasma 6.4.4

Fixed a bug that caused KWin to crash on the next login when you enable the magnifier effect but don't use it to zoom in at all before logging out. (Xaver Hugl, link)

Fixed a bug that caused KWin to crash on login when run in a QEMU virtual machine using the Bochs video driver. (Xaver Hugl, link)

Fixed the Global Menu widget's single-button mode for X11 users too. (Kishore Gopalakrishnan, link)

The search field in the Wayland version of the Global Menu widget once again works. (Niccolò Venerandi, link)

Fixed a bug in the KDE's implementation of the Global Shortcuts XDG portal that confused apps into thinking they had no shortcuts after you accepted the dialog to make some changes. (David Redondo, link)

Fixed a bug causing notifications in the history view to not appear in sequential order. In case you remember this previously being advertised as fixed, it was, because we worked around a Qt bug that was causing the issue. Well, that Qt bug got fixed, causing our workaround to re-introduce the bug! Software development is hard. (Kai Uwe Broulik, link)

Plasma Browser Integration's built-in Share feature once again works. (Kai Uwe Broulik, link)

Plasma 6.5.0

Cross-app window activation/raising now works more reliably in a couple cases, and also now works for files opened from KRunner-powered searches except for the Recent Documents runner, which is also being worked on. (Kai Uwe Broulik and Xaver Hugl, link 1, link 2, and link 3)

Fixed a bug that prevented the virtual keyboard from being able to enter text into the Application Dashboard widget's search field. (Arnav Rawat, link)

Fixed a layout bug that caused the contents of the "Set up a printer connection" page to visually overflow when opened from the "New printer detected" notification. (Mike Noe, link)

When accessed from Plasma (not System Settings), wallpaper grid items now follow the Plasma color scheme, rather than the app color scheme. This is relevant when using a mixed light/dark Global Theme like Breeze Twilight. (David Redondo, link)

Frameworks 6.17

KRunner-powered search results once again take into account frequency of use. (Nate Graham, link)

Other bug information of note:

• 4 very high priority Plasma bugs (same as last week). Current list of bugs
• 28 15-minute Plasma bugs (down from 32 last week). Current list of bugs

Notable in Performance & Technical

Plasma 6.4.4

Fixed a source of inotify leaks caused by reconfiguring the Plasma Desktop or the Folder View widget to show a different folder. (Harald Sitter, link)

Plasma 6.5.0

Implemented support the the pointer_warp_v1 ("Pointer Warp") Wayland protocol that allows apps to ask the compositor to move the pointer. (Xaver Hugl, link)

XDG portal-using apps can now explicitly request a screencast or remote desktop session of a new virtual output. (David Redondo, link 1 and link 2)

Added some more autotests for basic Plasma widget loading functionality. (Nicolas Fella, link)

The clipboard configuration window's size and position are now stored in the state config file, not the settings config file. (Nicolas Fella, link)

How You Can Help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

You can help KDE by becoming an active community member and getting involved somehow. Each contributor makes a huge difference in KDE - you are not a number or a cog in a machine! You don't have to be a programmer, either; many other opportunities exist!

You can also help us by making a donation! A monetary contribution of any size will help us cover operational costs, salaries, travel expenses for contributors, and in general just keep KDE bringing Free Software to the world.

To get a new Plasma feature or a bugfix mentioned here, feel free to push a commit to the relevant merge request on invent.kde.org.

26 Jul 2025 12:08am GMT

And since I'm back from my vacations, it's time to get back into good habits. Let's go for my web review for the week 2025-30.

Linux's Ascendancy: Charting the Open-Source Surge in the Desktop OS Arena

Tags: tech, linux, desktop, foss

It's a very important threshold to cross. Let's hope this momentum stays long enough.

https://www.linuxjournal.com/content/linuxs-ascendancy-charting-open-source-surge-desktop-os-arena

You MUST listen to RFC 2119

Tags: tech, standard, documentation, funny

OK… This is weird and funny. I definitely like the idea of an actor reading this important RFC aloud.

https://ericwbailey.website/published/you-must-listen-to-rfc-2119/

PNG is back!

Tags: tech, graphics, standard

Excellent news on the PNG standard front!

https://www.programmax.net/articles/png-is-back/

X-Clacks-Overhead

Tags: tech, http, history, literature, funny

This is a lovely idea I think. Good way to pay homage to lost ones.

https://xclacksoverhead.org/

A language model built for the public good

Tags: tech, ai, machine-learning, llm, ethics, ecology, research

ETH Zurich spearheading an effort for more ethical and cleaner open models. That's good research, looking forward to the results.

https://ethz.ch/en/news-and-events/eth-news/news/2025/07/a-language-model-built-for-the-public-good.html

How to run an LLM on your laptop

Tags: tech, ai, machine-learning, gpt, foss, vendor-lockin

Running interesting models locally gets more and more accessible.

https://www.technologyreview.com/2025/07/17/1120391/how-to-run-an-llm-on-your-laptop/

Yet another ZIP trick

Tags: tech, archive, compression, security

Better not trust ZIP files you receive…

https://hackarcana.com/article/yet-another-zip-trick

How we discovered, and recovered from, Postgres corruption on the matrix.org homeserver

Tags: tech, postgresql, failure, databases

Wow, this was a really bad index corruption indeed.

https://matrix.org/blog/2025/07/postgres-corruption-postmortem/

The most mysterious bug I solved at work

Tags: tech, debugging, pdf

Very interesting bug hunt prompted by some mysterious character in some strings and leading all the way to PDF viewers.

https://cadence.moe/blog/2025-07-02-the-most-mysterious-bug-i-solved-at-work

Graphite | Free online vector editor & procedural design tool

Tags: tech, 2d, graphics, tools, foss

Looks like an interesting vector editor.

https://graphite.rs/

Getting decent error reports in Bash when you're using 'set -e'

Tags: tech, shell, scripting

Nice way to improve the set -e output. I guess I'll use it in my next scripts.

https://utcc.utoronto.ca/~cks/space/blog/programming/BashGoodSetEReports

On Error Handling in Rust

Tags: tech, rust, safety, type-systems

There are indeed other options beyond the model with "one enum with all the errors".

https://felix-knorr.net/posts/2025-06-29-rust-error-handling.html

Alternative Blanket Implementations for a Single Rust Trait

Tags: tech, rust, type-systems, pattern

Nice pattern to workaround limitations of the Rust trait system preventing blanket implementations.

https://www.greyblake.com/blog/alternative-blanket-implementations-for-single-rust-trait/

The scary and surprisingly deep rabbit hole of Rust's temporaries

Tags: tech, rust, memory, type-systems

Dealing with temporaries is always complicated it seems, whatever the language.

https://taping-memory.dev/temporaries-rabbit-hole/

The JavaScript Date Quiz

Tags: tech, javascript, date

A good reminder that the JavaScript Date API is very error prone.

https://jsdate.wtf/

This Overly Long Variable Name Could Have Been a Comment

Tags: tech, programming

If it's too complicated to find a good name, use a comment indeed. As simple as that.

https://jonathan-frere.com/posts/names-vs-comments/

Most RESTful APIs aren't really RESTful

Tags: tech, web, services, architecture, rest, api

And it's not necessarily a problem. It all depends on the goal and context of the API you're building.

https://florian-kraemer.net//software-architecture/2025/07/07/Most-RESTful-APIs-are-not-really-RESTful.html

Caching is an Abstraction, not an Optimization

Tags: tech, caching

It's indeed another possible point of view about caching.

https://buttondown.com/jaffray/archive/caching-is-an-abstraction-not-an-optimization/

Expert Generalists

Tags: tech, organization, team, learning, complexity

Interesting article about expert generalists (also called "paint drip people" by Kent Beck). This is definitely a skill to foster in teams. The article is long enough that I'm not in agreement with everything in it. That being said there's a lot of food for thought here.

https://martinfowler.com/articles/expert-generalist.html

Agile Was Never Your Problem Pt ¹⁄₂

Tags: tech, agile, project-management

Hear, hear! If you go through rituals without understanding the values and principles… It's not Agile anymore so stop pretending. Another certification isn't going to save you at this point.

https://thecynical.dev/posts/agile-was-never-your-problem/

Agile That Doesn't Suck Pt ²⁄₂

Tags: tech, agile, criticism

So, you derailed and the joy is long gone in your team. This second part shows a possible way forward. Although it's probably not widely applicable (YMMV), the proposed end goal is what matters… If you stop fussing over labels but focus on what matters you're likely on the right track.

https://thecynical.dev/posts/agile-that-doesnt-suck/

Why measuring productivity is hard

Tags: tech, productivity, management

Indeed, it's hard. You need to put in the work but it's hard to predict where the real value will come from.

https://lemire.me/blog/2025/07/12/why-measuring-productivity-is-hard/

Underused Techniques for Effective Emails

Tags: tech, email, writing

Some of this is not new, but it looks like a dying practice. It doesn't need to be. This medium is more efficient than chat for some cases.

https://refactoringenglish.com/chapters/techniques-for-writing-emails/

Reading Neuromancer for the very first time in 2025

Tags: tech, scifi, literature

Neat piece about the reactions when reading this (IMHO) very important book for the first time in 2025. Made me want to read it again!

https://mbh4h.substack.com/p/neuromancer-2025-review-william-gibson

Why English doesn't use accents

Tags: linguistics, history

Very interesting article. Where diacritics come from? Why English doesn't have them?

https://www.deadlanguagesociety.com/p/why-english-doesnt-use-accents

How the alphabet began

Tags: history, linguistics

Interesting exploration about where the alphabet comes from. Interesting debate about the abjad vs alphabet classification in the comments as well.

https://www.deadlanguagesociety.com/p/how-the-alphabet-began

Bye for now!

25 Jul 2025 11:57am GMT

Kdenlive 25.08 Release Candidate is ready for testing. While this release focuses mostly on bug fixing, the dev team still managed to sneak in some cool features during the summer heat. Some highlights include:

• Optimized interface for lower resolution screens
• Project files are now properly recognized and can easily be opened by clicking them on MacOS
• Fix location of title templates on Windows
• Fix downloadable keyboard schemes
• Fix python 3.13 compatibility for Whisper
• Added power management support to prevent sleep while playing / rendering
• Support for start timecode
• Added option to display the markers of all clips in the project in the guides list
• Show thumbnails in the guides list
• Redesigned mixer

Download the binaries from below and give it a spin. Please share your feedback in the comments if you encounter any bugs or have a suggestion to help us polish the final release.

Pre-release binaries can be downloaded <a target="_blank" href="https://kdenlive.org/news/releases/25.07.90/#pre-release-binaries">here</a>.

24 Jul 2025 6:00pm GMT

23 Jul 2025 6:30pm GMT

Hello everyone! Midterm evaluations are here, and I wanted to share an update on my GSoC project. Here's what I've accomplished so far:

Progress So Far

Migration of Existing Fuzz Targets

The first step was migrating the existing build scripts and fuzz targets from the OSS-Fuzz repository into the respective KDE repositories. Maintaining them within the OSS-Fuzz repo added a bit of friction when making changes. Having them in KDE repos makes it easier to maintain and update them.

KArchive Fuzzer

Then I worked on KArchive fuzzer doing mainly two changes: First was to split the fuzzer into separate targets for each archive format (like zip, tar, 7z, etc.) to improve coverage. Second was to add libFuzzer dictionary files to guide the fuzzing process better. Here is an image showing the coverage after these changes:

This coverage was tested using a local corpus and it is pretty solid for just fuzzing the "reading" part. The coverage will increase on OSS-Fuzz by time as the corpus keeps growing. Splitting the fuzzer into multiple targets allows the fuzzer to focus on specific archive formats, which keeps the corpus size smaller and more efficient.

KMime Fuzzer

After that, I focused on KMime. I created a fuzz target for it, which focused on the just the MIME parsing functionality. The parsing part of KMime is critical as it handles untrusted input, such as, from emails (in KMail).

For KMime, I also added a libFuzzer-style dictionary file to help guide the fuzzing process. This helps the fuzzer generate more meaningful inputs, which can improve coverage and help the fuzzer reach deeper code paths.

KDE Thumbnailers Fuzzer

After KMime, I moved on to KDE Thumbnailers. I created a fuzzer for the thumbnailers that are used in KDE applications to generate previews of files. This is important as it handles untrusted input from various file formats, such as images, documents, etc. KDE has a lot of thumbnailers, I started with the thumbnailers in KIO-Extras repository, which includes thumbnailers for various file formats like images, videos, documents, etc.

KDE Thumbnailers were tricky to fuzz because they aren't standalone. They depend on KIO and KIOGui, which are pretty heavy and pull in a bunch of dependencies not required for thumbnailing. Building the full KIO stack inside OSS-Fuzz would have made the build process slow and complicated.

To avoid that, I wrote a custom build script that compiles just the thumbnailer source files and their direct dependencies. That keeps the fuzzers lightweight and focused only on the thumbnailing functionality.

For these thumbnailers, I also created a dictionary file for each thumbnailer separately for the same reason as KMime.

KFileMetaData Fuzzer

At last, I worked on KFileMetaData. This library is used to extract metadata from files, such as images, videos, documents, etc. Same as KDE Thumbnailers, it handles untrusted input from various file formats, so fuzzing it is important to ensure it can handle malformed or unexpected data gracefully.

Initially, I made a single fuzzer that used Qt plugin system to load metadata extractors and ran the extractors based on content mimetype. However, this required using dynamic libraries which is not great for OSS-Fuzz integration. So I split the fuzzer into multiple targets, one for each extractor, and compiled them statically. This way, each fuzzer is focused on a specific extractor and doesn't depend on dynamic linking.

The thumbnailers and kfilemetadata currently have the highest coverage among all the fuzzers I've created so far, which is great! The coverage will improve and reach closer to 100% for them as the corpus grows on OSS-Fuzz.

What's Next

There are still many more libraries that could benefit from OSS-Fuzz integration. Here are some that I plan to work on next:

More Thumbnailers

KDE maintains a large number of thumbnailer plugins, and I intend to integrate as many of them as possible. The next ones on my list (provided by Albert Astals Cid) include:

• Calligra Thumbnailer
• Itinerary Thumbnailer
• Qui Thumbnailer
• KDE Graphics Thumbnailers
• MLT Thumbnailer
• KDE SDK Thumbnailers
• WebArchive Thumbnailer
• Pala Thumbnailer
• Font Thumbnailer

Okular Generators & QMobipocket

QMobipocket is a library used by Okular for reading .mobi files. It parses Mobipocket documents and could benefit from fuzzing to identify edge cases and potential vulnerabilities.

Okular also includes several generators responsible for rendering various document formats. While most rely on third-party libraries, a few include custom code that has not yet been fuzzed. These components may be susceptible to bugs triggered by malformed files.

Fuzzing these generators is a bit tricky, since building the full Okular application and all its dependencies would slow down the build process and make its maintenance harder. To address this, I plan to build only the relevant generator source files and their minimal dependencies similar to the approach I used for KDE thumbnailers.

KContacts (VCard Parser)

KContacts is a KDE framework for handling contact data. It includes a VCard parser that reads .vcf files. Although the format is relatively simple, it supports multiple character encodings and codecs, making it an interesting candidate for fuzz testing.

Links

• Intro Blog post: azharmomin.me/posts/gsoc-2025-expanding-oss-fuzz-integration-across-kde-libraries

That's it for now. If you're working on/know a KDE library that touches untrusted input and could benefit from fuzzing, please let me know! You can reach me on Matrix or Email.

23 Jul 2025 2:30pm GMT

One of the biggest things you can do for KDE (that does not involve coding) is helping us organize Akademy.

In 2026, we are organizing a special edition of Akademy to celebrate KDE's 30th birthday. We want to make this occasion memorable by celebrating this important milestone with Akademy. The birthday edition of Akademy will not only bring together contributors, users, and partners but will also reflect on three decades of community, collaboration, innovation, and Free Software.

Now is your chance to become KDE champions and help make Akademy 2026 happen! We are looking to host Akademy 2026 during June, July, August, September, or October. Download the Call for Hosts guide and submit a proposal to host Akademy in your city to akademy-proposals@kde.org by October 1, 2025.

Do not hesitate to send us your questions and concerns! We are here to help you organize a successful event, and you can reach out at any time for advice, guidance, or any assistance you may need. We will support you and help you make Akademy 2026 an event to remember.

22 Jul 2025 6:21pm GMT

This year there was another "Display Next Hackfest", this time thanks to AMD organizing and hosting the event at their office in Markham, Toronto. Just like the last hackfests, there were other compositor developers and driver developers present, but in addition we had the color experts Charles Poynton and Keith Lee to pester with questions, which was very useful. In general, the event was very productive.

We discussed a lot of things, so this is just a summary of what I personally consider most important, not exhaustive notes on every topic. You can read the full notes on Harry's blog.

Commit Failure Feedback

Currently, when the compositor tries to commit changes to KMS and that fails, it almost always just gets -EINVAL as the response, in other words "something doesn't work". That's not just annoying to debug, but can lead to the compositor spending a lot of time with useless atomic tests in some situations, like for example when KWin tries to turn displays on - I've seen cases where we spend multiple seconds testing every possible configuration of outputs (while the screen is frozen!), just for the actual problem to be unfixable without turning one of the displays or some feature off.

So we discussed how to improve on that, and the result was basically that we just want something - really anything is better than the current situation. We found that there's a reserved field in the atomic ioctl, so we can even do this without introducing a completely new ioctl and just make that reserved field an optional pointer to another struct in which the kernel will write the feedback on what failed exactly. The most basic things we agreed to start with are to return

• some enum for common issues, like limited scanout/memory bandwidth, limited connector bandwidth, invalid API usage, things like that
• some string with possibly driver-specific information that the compositor can log, most important for debugging problems on user systems
• an optional array of KMS object IDs for what objects are related to the failure, for example for which connectors are hitting bandwidth limits

New Backlight API

The current backlight API on Linux is that the kernel exposes one or multiple backlight related files in sysfs, and userspace writes to one of them with root permissions. This requires heuristics for which one of the files is the correct one to use, this API can only control a single backlight, it can't be synchronized to the image a compositor presents, the firmware may or may not do animations, it may be linear or not, the minimum brightness is completely undefined (sometimes it's zero!), in summary it's a total mess.

Three years ago there was a proposal to add a backlight API to KMS instead, which however stalled as the author had to work on other tasks. We discussed on what exactly we want from that API:

• a backlight property per connector
• optional additional information about the mapping of backlight values to actual luminance (min/max values, linear/nonlinear curve)
• (where possible) no animations in the firmware
• (where possible) atomically update the backlight with the rest of the atomic commit, so we can properly synchronize content and light level for HDR on SDR displays

Adaptive Backlight Management

ABM is a feature on some AMD hardware, which reduces backlight intensity to save power and at the same time increases contrast of colors on the screen to compensate for that reduced backlight level. This is a bit of a controversial feature - on one hand it improves battery life, but on the other it messes with the colors on your screen, which to some people just doesn't look good but is really bad if you're trying to do color critical work.

Currently this feature is controlled through sysfs, which means power management daemons can mess up your colors without you being aware. Additionally it would be nice to automatically turn off the feature when you're profiling your screen with a colorimeter, and as the feature reduces the backlight, also in very bright environments to get that extra brightness… To improve on that situation, we'll get a KMS property to control the feature from the compositor side. I intend to make it off by default in Plasma, but users that want additional battery life will be able to easily opt into it in the display settings.

Autotests

We had three discussions about automatic tests - one about measuring power usage, one about testing KMS drivers, and one about testing compositors.

For power usage tests, we didn't really agree on the best way to get a standardized testing framework, but we found some possible approaches that can work now - tests can be automated to some degree by using compositor-specific APIs, the remote desktop portal or OpenQA.

For testing KMS drivers, we talked a bit about how the IGT test suite is useful for testing specific cases, but it doesn't really cover all the same bits that real world compositors use. The tests mostly use features in a somewhat self-contained manner, are mostly written by kernel developers, and thus test how they expect their APIs to be used, which is sometimes different from how compositors actually use it. A possible solution for that is for compositor developers to write automatic tests using their compositor, which run directly on KMS and execute some pre-programmed sequence of events, possibly requiring KMS features like color pipelines or overlay planes to be used successfully for the test to pass.

We still have to figure out the details, but if we can get compositors in DRM CI, that could help improve stability of both compositors and drivers.

Last but not least, for testing compositor's KMS usage, we can't really rely on our manual testing with actual hardware, and DRM CI tests will still be somewhat limited. Some compositors already use VKMS, a virtual KMS driver, for their automatic tests, and there are some pending kernel changes for configuring it to do a lot more than the rather simple and fixed setup we had so far. With the new API, we'll be able to configure it to have nearly arbitrary amounts of planes, add and remove connectors and even entire GPUs! I still have to wire up a KWin autotest for this, but it will be very useful both in development and to prevent regressions in releases.

Color and HDR

We of course also spent a lot of time talking about color management and HDR, and started that off with the current state of implementations. Things are looking really good!

In terms of Wayland protocols, all the important bits are in, namely the color management and color representation protocols. There may still be some smaller changes to the protocols, maybe some additions here and there, but the most important parts are done and used in practice. If you've read my previous blog posts, you might know that KWin's color management story is in a really good state, but other compositors are getting there as well. While Mutter is still lacking non-HDR color management bits, it now has basic HDR support, the Cosmic compositor has some preparations for it going on under the hood, and wlroots has basic HDR support as well.

On the application side, lots of applications are working on supporting it, like Qt, GTK, Godot and Firefox, or support it already, like Mesa, mpv and gamescope. Notably, Blender even has currently Wayland-exclusive HDR support!

We had a Q&A and some discussions with Charles Poynton and Keith Lee. For details you can look at the notes, but the most important thing I took from it was that we should adapt visuals to the user's viewing environment based on their absolute luminance too, not just the relative light levels. How to actually do that adjustment in practice isn't entirely figured out yet though, so that will be an interesting problem to solve.

We also talked a bit about the drm color pipeline API. I won't go into details about this one either, but I'll talk more about it my next blog post. TL;DR though is that this API allows us to use many more color operations that GPUs are capable of, to avoid compositing with shaders in more situations. I have a KWin implementation that proves the API works and by now the API and driver implementations basically just have to be merged into the kernel.

My "Favorite": Pageflip Timeouts

Judging by how often I come across this issue in bug triage, if you're reading this, chances aren't too terrible that you've heard of this one already, possibly even seen it yourself in the form of

kwin_wayland_drm: Pageflip timed out! This is a bug in the amdgpu kernel driver
kwin_wayland_drm: Please report this at https://gitlab.freedesktop.org/drm/amd/-/issues
kwin_wayland_drm: With the output of 'sudo dmesg' and 'journalctl --user-unit plasma-kwin_wayland --boot 0'

in your own system logs at some point. To be clear, this is just an example and it does not only affect amdgpu. I've seen the same with NVidia and Intel too, but as amdgpu's GPU resets have been a lot less reliable in the past, it's been a bigger issue for them.

Basically, pageflip timeouts are when the compositor does an atomic commit through KMS, and then waits for that to complete… forever. When this happens, the kernel literally doesn't allow the compositor to present to the screen anymore, so the screen is completely frozen forever, which is very bad, to state the obvious.

Fixing all the individual causes of the problem hasn't really worked out so well, and this is a bad enough situation that there should be a way out when it does happen. We discussed how to do this, and I'm happy to report that we figured out a way forward:

• we need a new callback in KMS that tells compositors when a pageflip failed and will never arrive
• drivers need to support resetting the display-driver bits of the GPU to recover it
• if the driver entirely fails to recover in the absolute worst case, it should send a device wedged event, which tells the compositor it should try to reload the entire driver / device

Scheduling Atomic Commits

When presenting images to a display, compositors try to get the absolute lowest possible latency achievable, without dropping frames of course. This is tricky enough with full information about everything, but it's even worse if information is missing.

Currently, KWin just tries to commit 1.5ms before vblank start of a refresh cycle. This number was figured out experimentally - on a lot of hardware, we could easily reduce latency by 500µs-1ms without any issues, and on some other hardware we'd even need more latency to never drop frames! The latter problem I kind of already fixed by measuring how long each commit takes, but that just measures the CPU time, and not when the hardware is actually done programming the next frame. We also don't know the deadline, on lots of hardware it is the start of vblank, but with some drivers it may be later or earlier.

We discussed how this could be solved, and concluded that we want

• a callback that gives us a timestamp for when the hardware finished programming the last commit
• information on when the deadline is, relative to the start of vblank

Variable Refresh Rate for the desktop

We want to use VRR to save power, not just to reduce stutter in games. However, for that we really want some additional APIs as well:

• the compositor should be able to set a min and max refresh rate, for example for low framerate compensation (LFC) and for flicker reduction
• the compositor should be able to do LFC instead of the driver having heuristics for that - so we need to be able to turn driver-side LFC off
• on the Wayland side, it would be nice for video players to be able to report their preferred refresh rate, so we can set the display to a multiple of the video. Should be a really simple Wayland protocol, in case anyone wants to do it before I get around to it ;)
• also on the Wayland side, a maximum desired refresh rate for games could be useful

Slow atomic commits

Amdgpu has some issues with atomic test commits being very slow, more specifically when it comes to significantly changing overlay plane state - on my desktop PC, enabling and resizing overlay planes regularly makes the test take tens of milliseconds. On my laptop it's a lot faster for some reason, where it's usually not noticeable, but even there a lot of tests take 1ms or more. We may need to do multiple atomic tests per frame, especially when you move the cursor… so that's still quite bad!

We can work around the problem in the compositor to some degree, by avoiding frequent changes to the overlay plane state - we'll certainly try to make it good enough to leave the feature on by default. Either way though, someone 'just' has to optimize this on the driver side, otherwise you might still see some stutter when enabling or disabling overlay planes.

Actual Hacking

It wouldn't be a proper hackfest without any hacking of course! Before the event, I was working on overlay plane support for a while, and added color pipeline support on top of my WIP code for that. In terms of KMS offloading, the only big feature that was still missing is underlay support… so I added that at the hackfest. Turns out, if you already have complete overlay plane support, adding underlays to the mix isn't actually all that difficult.

The code still need some cleaning up and not all of it is merged yet, but on my laptop it's now basically a challenge to get KWin to not put videos and games on hardware planes, and the result is amazing efficiency for video playback and improved latency and performance for gaming in windowed mode. This is a larger topic though and deserves its own blog post soon™, so I won't explain how it works here.

Tourist-y things

AMD invited us to go up the CN tower. It was a little bit foggy, but we still had a good view of the city:

I also visited Niagara Falls. It was a sight to behold!

Conclusion

Thanks again to AMD for hosting the event, it was really fun. There might not be another display hackfest next year, as most of the big topics are finally nearing conclusions, but I hope to see many of the other hackfest participants again at other events :)

22 Jul 2025 2:25pm GMT

In this blog you will learn how to set up clang-format with Qt Creator for consistent, automatic code formatting, including custom style files and exclusion rules for subdirectories.

Continue reading Using clang-format in Qt Creator at basysKom GmbH.

22 Jul 2025 7:35am GMT

This is an update of my Plasma & Kate on Wayland end of 2021 post from close to 4 years ago.

Wayland, what?

Since years (or let's say a decade now) Wayland based compositors are promoted as the successors to the venerable X.org X11 display server.

If you want to have some more high level overview about what is different to good old X11 see the Wayland Architecture overview.

But my Xeyes…

And yes, X11 will not just vanish in the next years and Xwayland will allow to run legacy applications for even longer without relying on the full low-level X11 stack.

But poor Xeyes will not be able to watch Wayland windows, evil security, I want my global key logger in no time!

My experience in 2025

Since my last post in 2021 I use Wayland more or less exclusive on all my private machines.

The latest newcomer to that is a M2 Macbook Air, even there it works just fine for me in general. For more details, here is my NixOS configuration for that machine, many thanks to the Asahi Linux team to make that feasible!

At work we use Arch Linux since some time and there Waylands works just fine for my needs, too.

I must confess I stay away from NVIDIA hardware and the AMD, Intel & Apple M2 GPUs I use work nicely with the open source drivers. Therefore, if you are a NVIDIA user, your mileage might vary.

Same if you are stuck on some older distribution, but as said, X11 is not gone. Before my 2021 switch I did keep using X11 due to driver issues, too, and I think that will still be feasible for years.

For day to day tasks I face no bugs that block me on either NixOS or Arch Linux.

For Kate itself, we had some persistent issues with bad parents of popups, that should now be fixed in the latest Frameworks 6 and some upcoming Qt 6.9.2 or higher patch release. That should remove the last logging spam on the terminal about Wayland issues like seen below.

qt.qpa.wayland: Creating a popup with a parent, QWidgetWindow(0x559ddf4cf3c0, name="MainWindow#1Window") which does not match the current topmost grabbing popup, QWidgetWindow(0x559de00644b0, name="goWindow") With some shell surface protocols, this is not allowed. The wayland QPA plugin is currently handling it by setting the parent to the topmost grabbing popup. Note, however, that this may cause positioning errors and popups closing unxpectedly. Please fix the transient parent of the popup.

The stuff did in principle work before, but that output still was unsettling and in rare cases could lead to totally misplaced popups or other issues with them.

One thing that I myself underestimated a lot in the past is, that Wayland is just a different thing than X11. It is a totally different platform in many aspects and just because stuff works as wanted on X11, if they are very low level, they might not work the same way on Wayland. Thankfully a lot of people helped to fix the issues we had!

All done?

No, naturally not. One could ask: but a lot of people worked on that a decade? How can that be?

Wayland is as said above really different to X11 in design (for good reasons, we no longer live in the 80ties and requirements have changed), it is expected that this will take time given the amount of code we have.

The currently known significant issues that still not work looks reasonable small to me. Naturally that might be different for others, one must be transparent that some stuff is working differently now and that some things still just not work (and some never will work by design).

My personal biggest issue I still have with Kate is the missing way to raise my existing windows if I open a new file via the terminal shell. All works fine if you do that via Dolphin and Co. as I get some activation token, that is at the moment just not feasible via the terminal with the shell.

With virtual desktops we miss some way to pick the right window or decide if we need to open a new one (even if we get a activation token from Dolphin), see bug 503519.

My current KDE Plasma Wayland session

Like in the last post, let's take a look at how my current session looks.

Try it out!

I can encourage all to give Wayland a try, if you are on some up-to-date distribution. To hunt the last bugs, we need more adopters. That more and more distributions default to Wayland naturally helps in that respect. But one must manage the expectations, the currently known issues will not just disappear over night.

Help out!

If you encounter issues, please report them as bug reports to the respective upstream projects. And naturally, any help in fixing them would be welcome, too. For Kate/KTextEditor beside the above mentioned window activation, I got all stuff that bothered me fixed. Naturally there will still be things that annoy others, patches welcome, scratch your own itch!

Feedback

You can provide feedback on the matching Reddit post.

20 Jul 2025 5:00pm GMT

KDE's Gitlab setup has a branch naming rule that I always forget about - branch names should start with work/ if you want the server to allow you to rebase and push rebased commits (that is, only work branches can be --force pushed to).

I had to abandon and open new PRs a few times now because of this.

Something like this is easy to check on the client side with pre-commit hooks. (a pre-push hook can also be used, but I like the check to be as early as possible)

A simple hook script that checks your branch name starts with work/YOUR_USER_NAME (I like to have the username in the branch name) is rather simple to write:

#!/bin/bash
REPO_URL=$(git remote get-url origin)
KDE_REPO_HOST="invent.kde.org"
if [[ "${REPO_URL}" == *"${KDE_REPO_HOST}"* ]]; then
BRANCH=$(git rev-parse --abbrev-ref HEAD)
BRANCH_REGEX="^work/$USER/.*$"
if ! [[ $BRANCH =~ $BRANCH_REGEX ]]; then
echo "Your commit was rejected due to its name '$BRANCH', should start with 'work/$USER'"
exit 1
fi
fi

It checks that the Git repository is on invent.kde.org, and if it is, it checks if the current branch follows the desired naming scheme.

KDEGitCommitHooks

But the question is where to put this script?

Saving it as .git/hooks/pre-commit in the cloned source directory would work in general, but there are two problems:

• Manually putting it into every single cloned KDE source directory on your system would be a pain;
• KDEGitCommitHooks, which is used by many KDE projects, will overwrite the custom pre-commit hook script you define.

The second issue is not a problem since a few hours ago. KDEGitCommitHooks (a part of the extra-cmake-modules framework) now generates a pre-commit hook that, additionally to what it used to do before, executes all the custom scripts you place in the .git/hooks/pre-commit.d/ directory.

So, if a project uses KDEGitCommitHooks you can save the aforementioned script as .git/hooks/pre-commit.d/kde-branches-should-start-with-work.sh and it should be automatically executed any time you create a new commit (after KDEGitCommitHooks updates the main pre-commit hook in your project).

For projects that do not use KDEGitCommitHooks, you will need to add a pre-commit hook that executes scripts in pre-commit.d, but more on that in a moment.

Git templates

The first problem remains - putting this into a few hundred local source directories is a pain and error-prone.

Fortunately, Git allows creating a template directory structure which will be reproduced for any repository you init or clone.

I placed my template files into ~/.git_templates_global and added these two lines to ~/.gitconfig:

[init]
templatedir = ~/.git_templates_global

I have two KDE-related hook scripts there.

The above one is saved as ~/.git_templates_global/hooks/pre-commit.d/kde-branches-should-start-with-work.

And the second file is the default main pre-commit (~/.git_templates_global/hooks/pre-commit) script:

#!/usr/bin/env bash
# If the user has custom commit hooks defined in pre-commit.d directory,
# execute them
PRE_COMMIT_D_DIR="$(dirname "$0")/pre-commit.d/"
if [ -d "$PRE_COMMIT_D_DIR" ]; then
for PRE_COMMIT_D_HOOK in "$PRE_COMMIT_D_DIR"/*; do
./"$PRE_COMMIT_D_HOOK"
RESULT=$?
if [ $RESULT != 0 ]; then
echo "$PRE_COMMIT_D_HOOK returned non-zero: $RESULT, commit aborted"
exit $RESULT
fi
done
fi
exit 0

It tries to run all the scripts in pre-commit.d and reports if any of them fail.

This default main pre-commit script will be used in projects that do not use KDEGitCommitHooks. In the projects that do, KDEGitCommitHooks will replace it with a script that executes everything in pre-commit.d same as this one does, but with a few extra steps.

19 Jul 2025 6:00pm GMT

I'm currently backpacking in the Balkans and, considering that it's been such a long time since I wrote a blog post on my blog, I figured it was a good idea to write about it.

As I am traveling, I am also field testing KDE Itinerary and sending patches as I buy new my tickets and reserve my hostels.

Ljubiana, Slovenia

My first stop was in the capital of Slovenia, Ljubljana. I went there by train from Berlin. I first took the night train to Graz and then an intercity train to Ljubljana. And while the connection was perfect and there was no delay, the whole journey took almost 19 hours.

I stayed only one night in Ljubljana in the party hostel Zzz and I enjoyed my time there quite a bit. Thanks to the Hostelworld app, it was super easy to find a group of fellow solo travelers to enjoy the evening with. We went to a food market and I had some delicious local pasta.

Rijeka, Croatia

My second stop was in Rijeka, the third biggest city in Croatia. I also took the train to get there. The city itself is very beautiful, same for the beaches. But I didn't really like that the city has a massive sea port splitting the city center from the beaches. The hostel experience was the most disapointing of the whole trip so far.

Split, Croatia

My next stop was in Split, the second largest city in Croatia. While there was a train connection from Rijeka to Split, I decided to take the bus as the train was significantly slower than the bus. I stayed at the Hostel Old Town.

I really had a blast in Split. The city is very old, with Greek, Roman, Byzantine, and Venetian influence. I met a cool group of American/Norwegian travelers in a hostel bar and got dragged to the Ultra festival, which was an amazing experience.

The day after, I went to a boat party which was equally a blast.

A script element has been removed to ensure Planet works properly. Please find it in the original post. A script element has been removed to ensure Planet works properly. Please find it in the original post.

19 Jul 2025 4:10pm GMT