I write this in the wake of a personal attack against my work and a project that is near and dear to me. Instead of spreading vile rumors and hearsay, talk to me. I am not known to be ‘hard to talk to’ and am wide open for productive communication. I am disheartened and would like to share some thoughts of the importance of communication. Thanks for listening.

Open source development thrives on collaboration, shared knowledge, and mutual respect. Yet sometimes, the very passion that drives us to contribute can lead to misunderstandings and conflicts that harm both individuals and the projects we care about. As contributors, maintainers, and community members, we have a responsibility to foster environments where constructive dialogue flourishes.

The Foundation of Healthy Open Source Communities

At its core, open source is about people coming together to build something greater than what any individual could create alone. This collaborative spirit requires more than just technical skills—it demands emotional intelligence, empathy, and a commitment to treating one another with dignity and respect.

When disagreements arise—and they inevitably will—the manner in which we handle them defines the character of our community. Technical debates should focus on the merits of ideas, implementations, and approaches, not on personal attacks or character assassinations conducted behind closed doors.

The Importance of Direct Communication

One of the most damaging patterns in any community is when criticism travels through indirect channels while bypassing the person who could actually address the concerns. When we have legitimate technical disagreements or concerns about someone’s work, the constructive path forward is always direct, respectful communication.

Consider these approaches:

• Address concerns directly: If you have technical objections to someone’s work, engage with them directly through appropriate channels
• Focus on specifics: Critique implementations, documentation, or processes—not the person behind them
• Assume good intentions: Most contributors are doing their best with the time and resources available to them
• Offer solutions: Instead of just pointing out problems, suggest constructive alternatives

Supporting Contributors Through Challenges

Open source contributors often juggle their community involvement with work, family, and personal challenges. Many are volunteers giving their time freely, while others may be going through difficult periods in their lives—job searching, dealing with health issues, or facing other personal struggles.

During these times, our response as a community matters enormously. A word of encouragement can sustain someone through tough periods, while harsh criticism delivered thoughtlessly can drive away valuable contributors permanently.

Building Resilient Communities

Strong open source communities are built on several key principles:

Transparency in Communication: Discussions about technical decisions should happen in public forums where all stakeholders can participate and learn from the discourse.

Constructive Feedback Culture: Criticism should be specific, actionable, and delivered with the intent to improve rather than to tear down.

Recognition of Contribution: Every contribution, whether it’s code, documentation, bug reports, or community support, has value and deserves acknowledgment.

Conflict Resolution Processes: Clear, fair procedures for handling disputes help prevent minor disagreements from escalating into community-damaging conflicts.

The Long View

Many successful open source projects span decades, with contributors coming and going as their life circumstances change. The relationships we build and the culture we create today will determine whether these projects continue to attract and retain the diverse talent they need to thrive.

When we invest in treating each other well—even during disagreements—we’re investing in the long-term health of our projects and communities. We’re creating spaces where innovation can flourish because people feel safe to experiment, learn from mistakes, and grow together.

Moving Forward Constructively

If you find yourself in conflict with another community member, consider these steps:

1. Take a breath: Strong emotions rarely lead to productive outcomes
2. Seek to understand: What are the underlying concerns or motivations?
3. Communicate directly: Reach out privately first, then publicly if necessary
4. Focus on solutions: How can the situation be improved for everyone involved?
5. Know when to step back: Sometimes the healthiest choice is to disengage from unproductive conflicts

A Call for Better

Open source has given us incredible tools, technologies, and opportunities. The least we can do in return is treat each other with the respect and kindness that makes these collaborative achievements possible.

Every contributor—whether they’re packaging software, writing documentation, fixing bugs, or supporting users—is helping to build something remarkable. Let’s make sure our communities are places where that work can continue to flourish, supported by constructive communication and mutual respect.

The next time you encounter work you disagree with, ask yourself: How can I make this better? How can I help this contributor grow? How can I model the kind of community interaction I want to see?

Our projects are only as strong as the communities that support them. Let’s build communities worthy of the amazing software we create together.

https://gofund.me/506c910c

Tellico 4.1.3 is available, with a few fixes.

Improvements

• Updated SRU fetcher to allow POST requests (Bug 507265).
• Updated SRU fetcher to recognize alternate Dublin Core schema.
• Updated OpenLibrary source to fetch work author (Bug 504586).
• Fixed a bug with reporting correct image location.

You click a link in your chat app, your browser with a hundred tabs comes to the front and opens that page. How hard can it be? Well, you probably know by now that Wayland, unlike X, doesn’t let one application force its idiot wishes on everyone else. In order for an application to bring its window to the front, it needs to make use of the XDG Activation protocol.

In essence, an application cannot take focus, it can only receive focus. In the example above, your chat app would request an XDG Activation token from the compositor. It then asks the system to open the given URL (typically launching the web browser) and sends along the token. The browser can then use this token to activate its window.

This token is just a magic string, it doesn’t matter how it gets from one application to another. Typically, a new application is launched with the XDG_ACTIVATION_TOKEN variable in its environment. When activating an existing one, an activation-token property is added to the platform_data dict sent via DBus. There’s also older protocols that weren’t designed with this in mind, such as Notifications, StatusNotifierItem (tray icons), or PolKit requests where we cannot change the existing method signatures. Here we instead added some way to set a token just before the actual call.

However, just because you have a token doesn’t mean you can raise your window! The compositor can invalidate your token at any time and reject your activation request. The idea is that the compositor gets enough information to decide whether the request is genuine or some application popping up a dialog in the middle of you typing something. A token request can include the surface that requests the activation, the input serial from the focus or mouse event that resulted in this request, and/or the application ID of the application that should be activated. While all of this is optional (and there can be valid reasons why you don’t have a particular piece of information at this time), the compositor is more likely to decline activation if the information is incomplete or doesn’t match what the requesting application provided.

A lot of places in Qt, KDE Frameworks, and other toolkits and applications have already been adjusted to this workflow and work seamlessly. For example, calling requestActivate on a QWindow will check if there is an XDG_ACTIVATION_TOKEN in the environment and use it, otherwise request one. Qt also does this automatically when the window opens to match the behavior of other platforms. Likewise, things like ApplicationLauncherJob and OpenUrlJob will automatically request a token before proceeding. On the other hand, KDBusService (for implementing single instance applications) automatically sets the corresponding environment variable when it received a token via DBus. Together this makes sure that most KDE applications just work out of the box.

You might be wondering: didn’t KWin-X11 have “focus stealing prevention”? It sure does. There’s a complicated set of heuristics based on _NET_WM_USER_TIME to judge whether the new window appeared as a result of explicit user interaction or is unsolicited. Remember how back in ye olde days, KWin’s focus stealing prevention would keep the Adobe Flash Player fullscreen window from showing ontop of the YouTube video you’re watching? Yeah, it’s not perfect. KWin can also only react on things that have already happened. For instance, when an application uses XSetInputFocus on a window from a different application, KWin will detect that and consider it a malicious request and restore previous focus but for a split second focus did change. If you want to know more, there’s a 200+ lines comment in activation.cpp in KWin’s git repo that explains it all. But then again the application could just do whatever it wants and bypass all of this.

Unfortunately, there’s still a few places that don’t do XDG Activation correctly. It didn’t matter much under X – in doubt we could just forceActiveWindow – but now we have to fix those scenarios properly! In order to test whether your application is well-behaved, use the latest git master branch of KWin and set “Focus Stealing Prevention” in Window Management settings to “Extreme”. This will make KWin activate a window if and only if it requests activation with a valid token.

Using this, over the past couple of days Xaver Hugl of KWin fame and I fixed a bunch of issues, including but not limited to:

• Dolphin threw away its token before activating its main window when launching a new instance (activating an existing one worked fine)
• KRunner, Kickoff, and other Plasmoid popups did not request activation at all
• LayerShell-Qt now requests activation on show (to match Qt behavior)
• LayerShell-Qt didn’t read the XDG_ACTIVATION_TOKEN from the environment when provided
• Privileged clients, like Plasma and KGlobalAccel, were unable to request tokens in some situations
• Modifier key presses no longer count towards focus stealing prevention: they’re often used as part of a global keyboard shortcut and don’t necessarily mean the user is interacting with the active window

Furthermore, the DBusRunner specification gained a SetActivationToken method which is called just before Run. Baloo (desktop search) runner now uses this to ensure opening files in an existing application window works. Likewise for the KClock runner bringing KClock to the front properly. I further improved the recent documents runner and places runner to send the file type to the OpenUrlJob so it doesn’t have to determine it again. This makes the job much quicker and avoids KRunner closing before the activation token is requested by the job. However, we have yet to find a proper solution for this in KRunner.

With all of this in place, we’ll likely switch on KWin’s focus stealing on Wayland at a low level and make it gradually stricter as applications are being fixed.

Intro

After adding the ability to drag and reposition the Selection Action Bar on the canvas last week, I spent this week improving that interaction. I tackled the issue where users could drag the toolbar completely off-screen, making it inaccessible. This week was all about keeping the toolbar within the canvas boundaries.

Side note: This week I also updated the UI to resemble the mockup concept provided from the community.

Obstacles to Implementation

During testing I noticed that without boundaries, the draggable toolbar could end up hidden and inaccessible especially after window or sidebar resizing. This would make it frustrating for users because they would have to find the missing toolbar or toggle the feature off and back on just to relocate it. I wanted to make the toolbar's positioning restricted to canvas boundaries to keep the toolbar within users' vision.

Find Canvas Boundaries

Looking into the code, I found that the canvasWidget had a property QRect rect() which holds the dimensions of the canvas. We can use these values as the boundaries.

Add Boundaries to Drag Event

With canvasBounds defined, we can limit the drag operation to stay within the canvas dimensions. Based on the current canvas dimensions and during a drag event, we update the horizontal and vertical limits of the toolbar position with the use of qBound which provides an upper and lower boundary for a value. So if the coordinates of the toolbar were to go past the boundaries, qBound would return the defined upper or lower boundary value. On top of canvas boundaries, it is important to include the dimensions of the toolbar and buffer room in the calculation to make sure the UI elements are accessible.

// updated drag event with canvas boundaries
QPoint newPos = mouseEvent->pos() - d->dragStartOffset;

 QRect canvasBounds = canvasWidget->rect();
 int actionBarWidth = 125;
 int actionBarHeight = 25;
 int bufferSpace = 5;
 newPos.setX(qBound(canvasBounds.left() + bufferSpace, newPos.x(), canvasBounds.right() - actionBarWidth - bufferSpace));
 newPos.setY(qBound(canvasBounds.top() + bufferSpace, newPos.y(), canvasBounds.bottom() - actionBarHeight - bufferSpace));

 d->dragRectPosition = newPos;
 canvasWidget->update();
 return true;

Conclusion

This week was focused on improving the user experience and accessibility of the Selection Action Bar. I learned about some great Qt tools, like the properties of QWidget and Qt helper functions like qBound to help solve my problem! In the coming final weeks, I'll continue adding action buttons based on the list provided by the community.

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

Since the last update two months ago KDE Itinerary got support for manually added train and bus trips, a more flexible alternative connection search, a new departure details view and a better location search, among many other improvements.

New Features

Manual trip entry

Being able to manually enter train or bus trips rather than selecting them from timetable data has been often requested and is now finally available.

For all modes of transportation there’s now two modes, manually entered data where you can freely change departure and arrival locations and times, and schedule-backed data for trips added from public transport searches where you can change the departure and arrival stops only based on what’s actually in the schedule.

The latter is now also available for ferry trips.

The the various add and import actions have also been consolidated in a single menu on the trip page. Importing backups remains available on the My Data page.

Generalized alternative connection search

The alternative connection search is no longer limited to just trains and busses either, it now can also be applied to ferry trips and flights. Likewise all modes of transportation in the result can be added that way, that is also ferries and flights.

Additionally, the alternative connection search now allows to select any transfer stop as the destination, unlike previously being limited to just the first or the last one.

New public transport departures view

There’s also an entirely new and much more detailed public transport departures view. You’ll find that behind the new context menu on locations in the details pages.

The departure list now automatically updates when looking at current departures. Also, you can select an individual entry to get a whole set of additional information where available:

• Service notes and alerts.
• Occupancy levels.
• The full trip run in a schedule view and and as a map.
• The exact departure location on an indoor station map.

Events

Earlier this month we had the first Transitous Hack Weekend covering many topics relevant for Itinerary as well, ranging from making Transitous long-term sustainable over improving the data coverage and quality to expanding the routing capabilities.

There’s two important upcoming events:

• KDE Akademy 2025, September 6-11, Berlin, Germany.

• Open Transport Community Conference 2025, October 17-18, Vienna, Austria.

Infrastructure Work

Everything mentioned in this section also benefits KTrip.

Geocoding

Geocoding is the process that happens behind the location search for journey planning. That produced some confusing and undesired results in the past, and should noticeably improve with the 25.08 release.

• MOTIS, Transitous and KPublicTransport gained support for geographic bias areas for geocoding queries. That’s used in the location search based on the selected country. With this you should now always have results from the right country at the top, while still not having a hard filter which can be inconvenient in border areas.

• Improved automatic backend selection for geocoding. This should fix the issue that in some countries locations were only searched in a few small regions rather than the entire area. Italy and the US were affected by this for example.

• The city, region and country a result is in are now display in more cases in a second line under the address or station name. This should further help to disambiguate results.

Online updates for public transport backend configurations

Access to public transport data still depends on over 70 operator services, besides Transitous. Many of those aren’t really meant for 3rd party use and thus have no proper change management, which means they can randomly change their URL, need a new custom certificate, need new or changed parameters or just disappear entirely.

Adapting to a lot of that is merely a matter of changing configuration files part of KPublicTransport, but so far it would take up to a month for those changes to reach users of release packages.

As this can severely impact the functionality we now have the infrastructure to update the KPublicTransport backend configuration files as well as supporting data such as the coverage information without waiting for the next software update.

This is meant to happen automatically eventually, while we are still testing this it’s available as a context action in the public transport backend configuration page.

Pickup/dropoff constraints

Another new feature in MOTIS and Transitous are pickup and dropoff constraints. That is, a way to describe that you cannot board or cannot alight from a vehicle at a given stop. While that isn’t all that common, it can be quite important to know.

KPublicTransport also gained support for this, besides MOTIS also for OpenTripPlanner and Hafas backends. In the UI you can see this in a few places then:

• Changing the departure or arrival stop when editing only allows to select those stops that actually allow boaring/alighting respectively.
• Stops that allow neither boarding nor alighting are shown as such in the journey overview. This sometimes occurs for border crossings or Switzerland advertising significant rail infrastructure.

Fixes & Improvements

Travel document extractor

• Added or improved travel document extractors for Amadeus, Arriva, BlablaBus, booking.com, DB, Deutscher Alpenverein, DJH, DSB, Easyjet, Eurostar, Finnair, Flixbus, Globtour, Gopass, hostelworld, Leo Express, LeShuttle, MÁV, Opodo, Ouigo ES, Reenio, SNCB, SCNF, tickets.ua and Tito.
• Improved matching and merging of bound and unbound train/bus trips.
• Improved matching and merging of seat reservations with seats listed in different orders.

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

Public transport data

• New or fixed backend configurations for KVB, South Tyrol, ZKS and the Varsinais-Suomen OpenTripPlanner instance.
• Onboard API support for XiamenAir.
• Fix parsing of bike carriage and wheelchair accessibility capabilities from OpenTripPlanner.
• Fix parsing of flight numbers from Entur.
• Support for more vehicle features from DB.
• Correctly update country coverage list in the stop picker when enabling/disabling backends.
• Filter out journey results with implausibly long detours. This gets rid of the “creative” connections between the major stations in Paris by backends that can’t do local transport routing there.
• Fix parsing of operator names from EFA.

Train station maps

• Support for more OSM tagging schemes for elevators, tram infrastructure and platform sections.
• Improved matching of platform names when faced with language specific leading abbreviations.
• Cancel ongoing tile downloads before starting a new map load.
• Better recovery from OSM level range tagging mistakes.
• Better recovery from failed tile downloads.

Itinerary app

• Added several more export options: Wallet passes, program memberships and standalone passes can now also be exported, and single reservations can be exported as GPX file.
• Reworked journey progress display, which is now active in all journey views and should be much more reliable especially in the timeline view.
• Standalone Wallet passes can now also be updated explicitly when containing an online update URL.
• Improved default zoom in the journey and trip map views.
• Fixed display of addresses with unresolved ISO 3166-2 region codes.
• Determine a correct trip end time in more cases.
• Fixed price display when there’s no home country configured.
• Also show notes/service alerts in the stop info dialog on the journey map.
• Fixed handling of Wallet passes with a case-sensitive identifier.

How you can help

Feedback and travel document samples are very much welcome, as are all other forms of contributions. Feel free to join us in the KDE Itinerary Matrix channel.

See also the recent posts on how you can add public transport data to Transitous and do OSM indoor mapping.

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 something was merged for Plasma 6.5 that a lot of people have been wanting for a long time: automatic day/night theme switching! And that's not all; we’ve got more visual customizability on offer too, plus a bunch more UI improvements and bug fixes. Check it all out here:

Notable New Features

Plasma 6.5.0

You can now have Plasma automatically switch to a different Global Theme at night! (Vlad Zahorodnii, link)

You can now choose which Global Themes are shown on System Settings’ Quick Settings page, and turn on automatic day/night switching from there, too! (Vlad Zahorodnii, link)

You can now choose to always see the light or dark variants of wallpapers that include both. Now there should be enough options for anyone: you can set dynamic wallpaper coloration to be based on the color scheme, based on the time of day, always light, or always dark. (David Redondo, link)

Notable UI Improvements

Plasma 6.4.4

If you’re a person who prefers to drag things to your panel itself rather than to a Task Manager widget, those panel icons are now removable via their context menus. (Niccolò Venerandi, link)

Plasma 6.5.0

On Wayland, files opened from KRunner in an already-running app now raise that app’s window as expected. (Kai Uwe Broulik, link)

On Wayland, the Orca screen reader now reads out changes to the Caps Lock state. (Nicolas Fella, link)

Moved System Settings’ Screen Edges pages into the Display & Monitor group, because it feels more natural to group it with screens than with the type of input device used to trigger its features. (Nate Graham, link)

If your system is set up for hibernation, you can now hibernate from the SDDM login screen. (Tobias Leupold, link)

Clicking “Connect” on a network in the Networks popup now closes any other open password fields for other networks, so there’s only one visible at a time. (Arnav Rawat, link)

Re-phrased the sorting/alignment options in Plasma’s desktop icon configuration window to make it clearer what they do. (Akseli Lahtinen, link)

Notable Bug Fixes

Plasma 6.4.4

Fixed a bug that could cause Plasma to freeze when spammed with many notifications containing images. (Paul Geerken, link)

Fixed a bug that could cause Plasma to crash while loading stuff. (Nicolas Fella, link)

Fixed a bug in Plasma’s desktop that prevented dragging-and-dropping things inside folders while the desktop was scrollable. (Akseli Lahtinen, link)

Fixed a bug that caused panel editing via drag-and-drop to break in hilarious/awful ways when using a right-to-left language like Arabic or Hebrew. (Niccolò Venerandi, link)

Fixed several bugs in Plasma’s desktop that would cause icons to shift around on their own due to changing the screen arrangement or having certain combinations of panel and desktop file alignment settings. (Akseli Lahtinen, link)

Fixed a bug in Discover that caused it to get confused about which version of a Flatpak app was considered unstable or outdated when the system has multiple Flatpak remotes set up. (Nicolas Fella, link)

Fixed two bugs involving renaming desktop files: one that made it impossible to rename symlinks to desktop files installed at the system level or generally without write permission, and another one that made rename jobs sometimes just kind of fail. (Akseli Lahtinen, link 1 and link 2)

Fixed a bug that prevented Plasma widget configuration windows from restoring their saved sizes as expected. (David Redondo, link)

Fixed a bug that caused you to have to leave System Settings’ Colors page and then go back to it after creating a copy of a color scheme, because it didn’t show up immediately. (Akseli Lahtinen, link)

Plasma 6.5.0

Fixed two cases where Plasma could crash in Activities-related functionality. (Daniel Hast, link 1 and link 2)

Fixed a bug in the free space checker that would cause it to inappropriately try to mount unmounted network shares defined in /etc/fstab, which could lead to hangs when there was no network connectivity. (Niccolò Venerandi, link)

Fixed a bug in System Settings’ Region & Language page that caused a visual glitch when using the system with a right-to-left language like Arabic or Hebrew. (Nate Graham, link)

Frameworks 6.17

Fixed a regression that made it impossible to drag files from Plasma’s desktop on one screen to another one. The fix for this also fixed some bugs in Dolphin, too. (Akseli Lahtinen, link 1 and link 2)

Qt 6.8.4

Fixed a Qt bug that caused KWin on X11 to sometimes consume excessive CPU resources when locking or turning off the screen. (Vlad Zahorodnii, link)

Other bug information of note:

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

Notable in Performance & Technical

Plasma 6.5.0

Fixed a bug that could cause the plasmawindowed developer tool to crash when viewing the System Tray widget. (Chris Xiong, 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.

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 🎉

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 Plasma) 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!

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.

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

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

Intro

This week I focused on making the Selection Action Bar draggable directly on the canvas. This would let the user reposition the toolbar that is best for their workflow.

Obstacles to Implementation

Up to this point adding elements on Krita using Qt was straightforward however making these elements interact and respond to mouse click events needed some deeper diving. The goal of this part of the Selection Action Bar was to allow users to click and drag the tool to reposition it anywhere within the canvas. In order to implement this I asked myself some questions: Where does Qt handle click events? How can the UI elements dynamically update their position?

Event Filters and Mouse Events

Documentation Links https://doc.qt.io/qt-6/eventsandfilters.html
https://doc.qt.io/qt-5.15/events.html
https://doc.qt.io/qt-5/qobject.html#installEventFilter

My research led me to Qt’s event system. One of the key concepts I learned about was event filters. Event filters are able to intercept events that are sent to another object. In our case, we can intercept the click events that are sent to the canvas and process that event to update the positions of our floating toolbar.

Since canvas was passed in through the KisSelectionAssistantsDecoration class, we can install an event filter on the canvas object, specifically the canvasWidget to intercept the mouse events.

// install event filter on canvasWidget, so KisSelectionAssistantsDecoration class (aka 'this') can look at event first
canvasWidget->installEventFilter(this);

After learning about event filters, I needed to learn how to handle the mouse events. By distinguishing user inputs of MouseButtonPress, MouseMove, and MouseButtonRelease, I was able to update the position of the floating bar. To keep things simple, imagine a rectangle on a 2D grid. Between the top left point of the rectangle and a point we click inside the rectangle is called an offset. This offset is to make sure that when we click and drag from within the rectangle, we are updating the position of the rectangle. Get offset = mouse position (click) - rectangle position
Update rectangle position = mouse position (click + drag) - offset
Mouse button release = stop updating rectangle

Working concept

With this major change, the Selection Action Bar is starting to feel like a full feature. Currently, we are able to activate selection actions, move the toolbar to a desirable position on canvas, and toggle it on and off via Krita settings.

Conclusion

This week really pushed me to explore how to handle events and how to make elements move in Krita! As I continue building out the Selection Action Bar every week, I start to understand how complex a ‘simple’ change could be. Next week I plan to improve on the movement of the toolbar by restricting its dragging area within the canvas.

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