As of a couple days ago Filelight on Windows is performing its search many times faster than before. Go check it out!

https://apps.kde.org/filelight/

It’s shocking that it was slow to begin with… A few years ago I rewrote the Filelight file walking logic to use native API for Linux and Windows. I thought I did a pretty good job of it and speed wasn’t too shabby. You can imagine my surprise when a friend recently pointed out that a similar piece of software performed maybe even better. Obviously this couldn’t stand. I immediately went to profile the situation and indeed Filelight wasn’t as fast as expected.

It turns out there are multiple competing APIs for querying file information on Windows and depending on which gets used performance may not be what you would expect. There’s a good write-up at https://www.cppstories.com/2024/cpp-query-file-attribs-faster/ in case you care to read more.

Long story short: by not calling slow API, Filelight is now heaps faster than before. Scans that took multiple seconds before now finish in the blink of an eye.

In case you are wondering just how much faster it is:

New

Old

Enjoy!

Using the Qt Logger in Rust with CXX-Qt

let file = CString::new("main.rs").unwrap();  
let function = CString::new("main").unwrap();  
let category = CString::new("lib").unwrap();  
  
let context = QMessageLogContext::new(&file, 0, &function, &category);

qt_message_output(  
    QtMsgType::QtInfoMsg,  
    &context,  
    &QString::from("This is an informational message..."),  
);

lib: This is an informational message...

export QT_MESSAGE_PATTERN="[%{time yyyyMMdd h:mm:ss.zzz ttt} %{if-debug}D%{endif}%{if-info}I%{endif}%{if-warning}W%{endif}%{if-critical}C%{endif}%{if-fatal}F%{endif}] %{file}:%{line} - %{message}"

[20250314 8:56:45.033 EDT I] main.rs:0 - This is an informational message...

use std::fmt::Write; // needed for write_fmt

struct StringVisitor<'a> {
    string: &'a mut String,
}

impl tracing::field::Visit for StringVisitor<'_> {
    fn record_debug(&mut self, field: &tracing::field::Field, value: &dyn std::fmt::Debug) {
        write!(self.string, "{} = {:?} ", field.name(), value).unwrap();
    }
}

pub struct QtSubscriber {}

impl<S> tracing_subscriber::Layer<S> for QtSubscriber
    where
        S: tracing::Subscriber,
{
    fn on_event(
        &self,
        event: &tracing::Event<'_>,
        _ctx: tracing_subscriber::layer::Context<'_, S>,
    ) {
        let mut buffer: String = String::new();
        let mut visitor = StringVisitor {
            string: &mut buffer
        };
        event.record(&mut visitor);

        let msg_type = match *event.metadata().level() {
            tracing::Level::ERROR => QtMsgType::QtCriticalMsg,
            tracing::Level::WARN => QtMsgType::QtWarningMsg,
            tracing::Level::INFO => QtMsgType::QtInfoMsg,
            tracing::Level::DEBUG => QtMsgType::QtDebugMsg,
            tracing::Level::TRACE => QtMsgType::QtDebugMsg
        };

        let file = if let Some(file) = event.metadata().file() {
            CString::new(file).unwrap()
        } else {
            CString::default()
        };

        let line = if let Some(line) = event.metadata().line() {
            line as i32
        } else {
            0
        };
        
        let function = CString::default();  
        let category = CString::new("lib").unwrap();  

        let context = QMessageLogContext::new(&file, line, &function, &category);  

        qt_message_output(msg_type, &context, &QString::from(buffer));
    }
}

use tracing_subscriber::layer::SubscriberExt; // needed for with
use tracing_subscriber::util::SubscriberInitExt; // needed for init

tracing_subscriber::registry().with(QtSubscriber{}).init();

tracing::info!("This is an informational message... from tracing!")

[20250320 10:41:40.617 EDT I] examples/cargo_without_cmake/src/main.rs:104 - message = This is an informational message...

The post Using the Qt Logger in Rust with CXX-Qt appeared first on KDAB.

The other day I finally replaced my trusty Thinkpad T480s I bought 6½ years ago. Overall, I was still pretty happy with it and even gave it a little refresh early last year (RAM upgrade, bigger SSD, new keyboard) but the CPU was really starting to show its age when compiling. I’m almost as picky as Nate when it comes to laptops but the P14s Gen 5 AMD (what a mouthful) checked more boxes than most laptops I looked at in recent years.

The device shipped with Windows 11 and whenever I touch a Windows machine I’m baffled that people put up with this. I connected it to Wifi (beginner’s mistake apparently) since I wanted to install all firmware updates and salvage a couple of things from it before formatting the SSD (ICC profiles, Dolby audio presets, etc). The first run wizard asked me for my choice of locale, then went looking for updates. Once done, the system rebooted. After that it asked me to give the computer a name. Guess what? Another reboot, and more updates. And then the dreaded compulsory Microsoft account I had no intention of creating. You can open a terminal by pressing Shift+F10 but the old bypassnro trick just led to a reboot and it asking the same questions again. Just when I was about to give up, Bhushan showed me another trick how to create a local account. Indeed, after yet another reboot and clicking away like 10 individual nag screens about privacy and cloud stuff, I was able to log into the system.

This is the sort of usability nightmare and command line tinkering bullshit that people were mocking Linux users for back in the days! Compare that to my KDE neon “unstable” installation where I plugged in a USB stick (Secure Boot of course rejected “3rd party keys” by default), booted into the live system, had the entire drive formatted, and within 10 minutes or so ended up with a working sexy KDE Plasma setup. I’m still sometimes amazed how beautiful our default setup looks nowadays with the floating panel, frosted glass, and all. I don’t like dark mode but since that laptop has an OLED screen I opted for “Breeze Twilight” which combines light applications with a dark panel and wallpaper.

As with any new device, there’s a few surprises waiting for you. Like most recent laptops it has a stupid Copilot (“AI”) key. Unfortunately, rather than inventing a new key code, it emulates an actual key combination of Meta+Shift+Touchpad Off (F23 I heard, yes, there can be more than just F12). This makes it difficult to just remap the key to something useful (like a right Meta key). However, at least you should be able to use it as a global shortcut, right? Unfortunately, you weren’t able to assign it from GUI. I now fixed the Copilot key by allowing Shift be used in a shortcut in conjunction with “Touchpad Off”. It’s a kludge but at least you can now make it bring up KRunner or something.

Speaking of proprietary keys, it also has a “Phone Link” function key. It is recognized as such starting from Linux kernel 6.14 but there’s no support in Xkb or Qt yet. I just sent a pull request to libxkbcommon to add it and once that lands, I’ll look into adding it to Qt. How cool would it be if under Plasma the Phone Link button would instead open KDE Connect?!

The suspend-to-idle stuff is both a great opportunity and a little scary. Modern laptops don’t do “proper” S3 suspend anymore but only S2 which works more like on a smartphone where it can wake up anytime and fast. Right now even plugging in the charger or touching the touchpad causes the machine to wake up. Luckily, if KWin detects the lid is shut and no monitor is connected, it sleeps again after a short time to prevent a hot backpack situation. Work is ongoing to make better use of this capability, to detect what caused the system to wake up. For example, when plugging in the charger, we might want to wake up, play a short animation and the “plugged in” sound and go back to sleep.

I can still return the device within the 14 day period if something major crops up but I already fell in love with its 120 Hz OLED 16:10 display (I luckily don’t seem to be sensitive to the 240 Hz PWM it uses), so I don’t think I’ll be returning it :-)

During all my time with KDE projects, I've never made an app from scratch.. Except now.

Today my first KDE app ever, KomoDo, was released on Flathub!

It's a simple todo application for todo.txt format and parses todo.txt files into a list of cards. One task is one card.

The application has help sections for any of the rules todo.txt format follows, but you can use as many or as little of them as you want.

I wanted to go through in this blogpost about the process, or what I remember of it anyway. I've always just fixed bugs in Plasma or Frameworks or even in apps like Dolphin, but never made anything from scratch. So I thought that writing this down might be helpful for someone in similar position.

As with any KDE project, it's open source and the repository can be explored right here: utilities/komodo.

Starting up

Starting a Qt project using KDE libraries, especially QtQuick, is not that difficult in the end. KDE has really good documentation for starting up. I mostly followed this guide to get started: https://develop.kde.org/docs/getting-started/kirigami/setup-cpp/

There is also guides for Python and Rust if you wish to use those instead of C++.

I also highly recommend using kde-builder for building and running the applications. It makes things so much easier.

Other than that, there's not much to tell about the setup.

The project itself

Working on the application was not that bad either. I've worked on various C++ and QML files during my work on KDE software, so I had easy time getting into the flow.

I think the most difficult part for me was the CMake files: I couldn't really understand them or what they do, I mostly followed what other projects did and replicated them.

This of course caused me to do unnecessary things, like installing libraries I made for the app: TodoModel which the QML code uses to parse the todo.txt file and generate the view was accidentally installed among the system libraries, which was not ideal, since I'm not building a framework.

Luckily with tons of help and reviews from my friends in the KDE fam, we got CMake to build things nicely. Then with kde-builder the feedback loop of code->build->test was fast enough, especially in small app like this, that I could iterate on the application in a good pace.

I also had a lot of help from a friend with the CI and sysadmin stuff. That side of development is very confusing to me so I'm glad with the help. I dunno if you want to be named so I didn't, but you know who you are: Big thanks. :)

TodoModel

Since Qt is reliant on the model-view system, I had to make a "model" that parses the todo.txt file and spits out Todo objects, which can then be parsed by the QML code, which is the frontend code.

If you have never worked on model-view systems, it can take some time to understand. To me, the model-view as words was always a bit confusing: I would have understood it better if it was worded something like data-ui. But tech jargon has always been my weakest point.

The parsing is done by a RegExp nightmare I concocted with help of stack-overflow and tears.

Here it is, in its nightmarish glory, enjoy the nightmare fuel:

QStringLiteral("(?:^[ "
	"\\t]*(?P<Completion>x))|(?P<Priority>\\([A-Z]\\))|(?:(?P<FirstDate>"
	"\\d{4}-\\d\\d-\\d\\d)[ "
	"\\t]*(?P<SecondDate>\\d{4}-\\d\\d-\\d\\d)?)|(?P<Projects>\\B\\+[\\w\\d\\S]+)|(?P<"
	"Contexts>(?<=\\s)@[^\\s]+)|(?P<KeyValuePairs>[a-zA-Z]+:[\\S]*)");

Yyyeah. It's.. Something.

Testing

Due to the nightmare fuel that RegExp can be, I decided that unit testing would be great addition. So I fought with CMake a bit and then made myself a proper parser testing file.

Thankfully Qt has nice QTest library that can be used to create tests. They can be hard to parse at first, but when you understand how they work, they're really quick and easy to work with.

Testing saved my rear a few times during this project, especially when modifying anything parser related.

Look and feel

When the model worked fine, I started concentrating more on the look and feel of the app.

The application went through various phases: At first, everything was done through a dialog, except viewing the cards. It was kind of distracting that every time you wanted to modify or make new task, the application would pop things up.

Over time though, I think I got it into a good spot: Most actions can be done in the task list, but when user wants to delete a task, the app asks the user first if they are sure about it.

Then there is help menu and quick info for syntax related things.

Otherwise there's really no settings: I did not want to add any settings if I could avoid it. The only setting the app saves to config file is the file you opened last time.

I also consulted the KDE Human Interface Guidelines (HIG) few times, but it was never "in the way." It just helped me to make decisions sometimes when I wasn't sure what to do with the design.

Also my lovely wife @tecsiederp made the application the most adorable icon ever.

Look at it. Just a lil guy.

Also, if you don't get your tasks done, he will get sad. So you better do those tasks!

It just makes me so happy and motivated to work on my tasks when I see this lil guy in my taskbar. :D

The icons however have to follow our guidelines, also mentioned in the HIG. Luckily my wife is good with SVG files, and if she wasn't I already had two people wanting to help me with it, which I very much appreciated. If I had to make an icon myself, it would.. Not be good. :P

Something I mostly struggled with though was getting a nice syntax highlighting for the task text. I wanted to use our KSyntaxHighlighting library, but it would not match all colorschemes: Users may use their own or third party colorscheme for the app, but the syntax highlighter does not have a colorscheme that matches it.. So it would look bit odd.

So I made my own simple one that appends some color tags to the string, and the QML engine does the rest. The text can have HTML tags like <span> in it which QML can parse automagically.

I think the app turned out to look pretty good. It also supports keyboard navigation for getting around the app. (Though there might be some bugs with it still.)

Releasing the app

KDE has documentation for the release process, so I just followed it to the letter. During the release process, I have to wait for at least 2 weeks for people to give me reviews, and so they did. And then I fixed things. And some more.

Eventually the app was good to go (though it was never directly told me, it was just implicitly agreed), and I followed the last bits of relese process, setting up signing keys and such.

And now it exists as a tarball here, so any interested distros can go grab it: https://download.kde.org/stable/komodo/1.0.0/

I also recommend this patch to go with it, to make sure it doesn't install the static libraries in the system: https://invent.kde.org/utilities/komodo/-/commit/57c6fa82719155bd32cb35b4c64cddae956c53e0

With Flathub, the submission process was rather painless in my opinion. I followed their requirements and submission documentation and it all just clicked together. Eventually someone was reviewing my PR and then.. The app is in Flathub. I had to make a patch for Flathub specifically, but it was also really painless so I didn't mind.

What it all mostly took from me is time. Otherwise it was just nice and easy.

More apps?

So at least in my experience, the whole process was rather easy. I didn't want to go into nitty gritty details too much.. Because I don't remember everything + you can see the source code + the process itself happens in the open.

I'm definitely interested in making more KDE apps, but also I have my game project(s).

And I really want to get back into gamedev. Like spend much more time into it.

At least now I have a todo app which fits my needs to keep track of the gamedev projects. :)

Thanks for reading! And if you're looking for new todo application, give KomoDo a try! :)

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.

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

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

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