Glaxnimate is proud to announce the release of version 0.5.2. This latest update brings several exciting new features and improvements to enhance your animation creation experience.

Animation along Path

Earth and Moon graphics are from Noto Emoji

One of the major additions in this release is the ability to animate objects along a path. This is a feature that allows you to animate elements in a more natural and organic way by having them move along a custom path instead of a straight line. With this feature in Glaxnimate, you can create animations of objects following a curved path, like a bouncing ball or a spaceship flying through space.

After you add position keyframes to an object, the path can be adjusted with the edit tool, giving you full control over the motion of your elements, and the ability to fine-tune your animations until they look just right.

Improved User Interface

The interface layout has also been updated with new presets to provide better display on smaller screens, and the ability to set custom shortcut settings for plugins has been added.

Enhanced Input/Output Functionality

To make your workflow even easier, a new export option as an image sequence has been added to the menu.

This release also brings support for loading and saving Rive animations, improving the quality of video exports, and adding command line options for rendering images without starting the GUI.

Issues with loading Glaxnimate and old Lotties files have also been resolved, as well as a crash on SVG export.

Scripting Additions

For developers and advanced users, the new release features a function to render a node at a specific frame, providing even more control over your animations.

Bug Fixes and Minor Enhancements

This release also includes several bug fixes, including resolution of issues with loading Lotties with hidden fill and stroke, improved previews in the stroke style view, and proper application of duration changes in the startup dialog to all layers.

Additionally, Glaxnimate 0.5.2 includes the addition of Flatpak, improved Freedesktop file naming and metainfo, and the ability to view contributors. Messages are also logged to a file for better tracking of errors and issues.

The Select tool has also been improved, allowing for better handling of ungrouped shapes, making your editing process smoother and more efficient.

Download

We are confident that these new features and improvements will enhance your experience with Glaxnimate and look forward to continuing to bring you the best vector animation application.

If you're interested in trying it out, head over to our download page to get started. As always, if you have any questions or feedback, feel free to reach out to us via our issue tracker.

Thank you for your continued support of Glaxnimate!

As announced previously, Plasma 5.27 will have a significantly reworked multiscreen management, and we want to make sure this will be the best LTS Plasma release we had so far.

Of course, this doesn’t mean it will be perfect from day one, and your feedback is really important, as we want to fix any potential issue as fast as they get noticed.

As you know, for our issue tracking we use Bugzilla at this address. We have different products and components that are involved in the multiscreen management.

First, under New bug, chose the “plasma” category. Then there are 4 possible combinations of products and components, depending on the symptoms:

In order to have a good complete information on the affected system, its configuration, and the configuration of our multiscreen management, if you can, the following information would be needed:

• Whether the problem happens in a Wayland or X11 session (or both)
• A good description of the scenario: how many screens, whether is a laptop or desktop, when the problem happens (startup, connecting/disconnectiong, going out of sleep and things like that)
• The output the terminal command: kscreen-doctor -o
• The output of the terminal command: kscreen-console
• The main plasma configuration file: ~/.config/plasma-org.kde.plasma.desktop-appletsrc

Those items of information already help a lot figuring out what problem is and where it resides.

Afterwards we still may ask for more informations, like an archive of the main screen config files that are the directory content of ~/.local/share/kscreen/ but normally, we wouldn’t need that.

One more word on kscreen-doctor and kscreen-console

Those 2 commands are very useful to understand what Plasma and the rest of the system thinks about every screen that’s connected and how they intend to treat them.

kscreen-doctor

Here is a typical output of the command kscreen-doctor - o:

Output: 1 eDP-1 enabled connected priority 2 Panel Modes: 0:1200x1920@60! 1:1024x768@60 Geometry: 1920,0 960x600 Scale: 2 Rotation: 8 Overscan: 0 Vrr: incapable RgbRange: Automatic
Output: 2 DP-3 enabled connected priority 3 DisplayPort Modes: 0:1024x768@60! 1:800x600@60 2:800x600@56 3:848x480@60 4:640x480@60 5:1024x768@60 Geometry: 1920,600 1024x768 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic
Output: 3 DP-4 enabled connected priority 1 DisplayPort Modes: 0:1920x1080@60*! 1:1920x1080@60 2:1920x1080@60 3:1680x1050@60 4:1600x900@60 5:1280x1024@75 6:1280x1024@60 7:1440x900@60 8:1280x800@60 9:1152x864@75 10:1280x720@60 11:1280x720@60 12:1280x720@60 13:1024x768@75 14:1024x768@70 15:1024x768@60 16:832x624@75 17:800x600@75 18:800x600@72 19:800x600@60 20:800x600@56 21:720x480@60 22:720x480@60 23:720x480@60 24:720x480@60 25:640x480@75 26:640x480@73 27:640x480@67 28:640x480@60 29:640x480@60 30:720x400@70 31:1280x1024@60 32:1024x768@60 33:1280x800@60 34:1920x1080@60 35:1600x900@60 36:1368x768@60 37:1280x720@60 Geometry: 0,0 1920x1080 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic

Here we can see we have 3 outputs, one internal and two via DisplayPort, DP-4 is the primary (priority 1) followed by eDP-1 (internal) and DP-3 (those correcpond to the new reordering UI in the systemsettings screen module).

Important data points, also the screen geometries (in italic in the snippet) which tell their relative positions.

kscreen-console

This gives a bit more verbose information, here is a sample (copied here the data of a single screen, as the output is very long):

Id: 3
Name: "DP-4"
Type: "DisplayPort"
Connected: true
Enabled: true
Priority: 1
Rotation: KScreen::Output::None
Pos: QPoint(0,0)
MMSize: QSize(520, 290)
FollowPreferredMode: false
Size: QSize(1920, 1080)
Scale: 1
Clones: None
Mode: "0"
Preferred Mode: "0"
Preferred modes: ("0")
Modes:
"0" "1920x1080@60" QSize(1920, 1080) 60
"1" "1920x1080@60" QSize(1920, 1080) 60
"10" "1280x720@60" QSize(1280, 720) 60
"11" "1280x720@60" QSize(1280, 720) 60
"12" "1280x720@60" QSize(1280, 720) 59.94
"13" "1024x768@75" QSize(1024, 768) 75.029
"14" "1024x768@70" QSize(1024, 768) 70.069
"15" "1024x768@60" QSize(1024, 768) 60.004
"16" "832x624@75" QSize(832, 624) 74.551
"17" "800x600@75" QSize(800, 600) 75
"18" "800x600@72" QSize(800, 600) 72.188
"19" "800x600@60" QSize(800, 600) 60.317
"2" "1920x1080@60" QSize(1920, 1080) 59.94
"20" "800x600@56" QSize(800, 600) 56.25
"21" "720x480@60" QSize(720, 480) 60
"22" "720x480@60" QSize(720, 480) 60
"23" "720x480@60" QSize(720, 480) 59.94
"24" "720x480@60" QSize(720, 480) 59.94
"25" "640x480@75" QSize(640, 480) 75
"26" "640x480@73" QSize(640, 480) 72.809
"27" "640x480@67" QSize(640, 480) 66.667
"28" "640x480@60" QSize(640, 480) 60
"29" "640x480@60" QSize(640, 480) 59.94
"3" "1680x1050@60" QSize(1680, 1050) 59.883
"30" "720x400@70" QSize(720, 400) 70.082
"31" "1280x1024@60" QSize(1280, 1024) 59.895
"32" "1024x768@60" QSize(1024, 768) 59.92
"33" "1280x800@60" QSize(1280, 800) 59.81
"34" "1920x1080@60" QSize(1920, 1080) 59.963
"35" "1600x900@60" QSize(1600, 900) 59.946
"36" "1368x768@60" QSize(1368, 768) 59.882
"37" "1280x720@60" QSize(1280, 720) 59.855
"4" "1600x900@60" QSize(1600, 900) 60
"5" "1280x1024@75" QSize(1280, 1024) 75.025
"6" "1280x1024@60" QSize(1280, 1024) 60.02
"7" "1440x900@60" QSize(1440, 900) 59.901
"8" "1280x800@60" QSize(1280, 800) 59.91
"9" "1152x864@75" QSize(1152, 864) 75
EDID Info:
Device ID: "xrandr-Samsung Electric Company-S24B300-H4MD302024"
Name: "S24B300"
Vendor: "Samsung Electric Company"
Serial: "H4MD302024"
EISA ID: ""
Hash: "eca6ca3c32c11a47a837d696a970b9d5"
Width: 52
Height: 29
Gamma: 2.2
Red: QQuaternion(scalar:1, vector:(0.640625, 0.335938, 0))
Green: QQuaternion(scalar:1, vector:(0.31543, 0.628906, 0))
Blue: QQuaternion(scalar:1, vector:(0.15918, 0.0585938, 0))
White: QQuaternion(scalar:1, vector:(0.3125, 0.329102, 0))

Important also the section EDID Info, to see if the screen has a good and unique EDID, as invalid Edids, especially in combination with DisplayPort is a known source or problems.

After the announcement upstream, Fedora’s @kde-sig follows up by making KDE Gear 22.12.2 available on Fedora 37.

As per Fedora’s policy, the software will first land on updates-testing and after receiving feedback and karma it will land on the updates repository.

If you want to help, make sure to follow the instructions on the update. You only need to run:

sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-17c31eabf7

Feel free to join us at our Matrix room!.

This is a non-comprehensive list of all of the major work I’ve done for KDE this month of January. I think I got a lot done this month! I also was accepted as a KDE Developer near the start of the month, so I’m pretty happy about that.

Sorry that it’s pretty much only text, a lot of this stuff isn’t either not screenshottable or I’m too lazy to attach an image. Next month should be better!

Custom icon theme in Tokodon

[Feature] I threw all of the custom icons we use in Tokodon into a proper custom icon theme, which should automatically match your theme and includes a dark theme variant. In the future, I’d like to recolor these better and eventually upstream them into Breeze.

KXMLGUI tooltips

[Bugfix] As part of cleaning up some KDE games-related stuff, I also looked into the issue of duplicate “What’s This?” tooltips. This also fixes that visual bug where you can close normal tooltips that don’t have “What’s This?” information to actually open.

KBlocks background changes

[Feature] This one isn’t merged yet, but in the future - KBlock themes authors will be able to specify where to pin the background instead of having it stretched by default.

Kirigami “About KDE” dialog

[Feature] I added something that’s been wanted for a while, Kirigami’s own “About KDE” dialog! It’s currently sitting in Add-ons, but will most likely be moved in the future. If you would like to suggest what we do about the About pages/windows in KDE, please check out the proposal. See the merge request.

Media improvements in Tokodon

[Bugfix] I did a lot of work improving media in Tokodon this month, including fixing the aspect ratios scaling correctly, video support (not merged yet) and other miscellaneous fixes. I also caught a bunch of blurhash bugs along with making the timeline fixed-width so images aren’t absurdly sized on a typical desktop display. Also a fix for three media attachments!

Krita.org dark theme

I’m starting to get involved in improving the KDE websites, and currently working on the new Krita.org website and adding a proper dark theme to it.

See the work-in-progress merge request.

Gwenview MPRIS fixes

[Bugfix] Not merged yet (due to MPRIS bugginess in general?) but I cracked a shot at improving the MPRIS situation with Gwenview. Notably, slideshow controls no longer “hang around” until a slideshow is actually happening.

CMake Package Installer

I worked a little on solving the kdesrc-build issue of manual package lists, and created cmake-package-installer. It parses your CMake log and installs the relevant packages for you. I want to start looking into hooking this into kdesrc-build!

See the repository.

KDE Wiki improvements

I made some misc changes to the Community Wiki this month, mostly centered around fixing some long-standing formatting issues I’ve noticed. The homepage should be more descriptive, important pages no longer misformatted (or just missing?) and the Get Involved/Development page should be better organized.

Misc Qt patches

[Bugfix] I cherry-picked a Qt6 commit fixing video playback in QML, which should appear in the next Qt KDE Patch collection update, mostly for use in Tokodon when video support lands. I also submitted an upstream Qt patch fixing WebP loading, meant for NeoChat where I see the most WebP images. See the GStreamer cherry-pick and the WebP patch.

Window Decoration KCM overhaul

[Feature] This isn’t merged yet (but it’s close!) so it barely misses the mark for January, but I’ll include it anyway. I’m working on making the Window Decoration KCM frameless and give it a new look that matches the other KCMs. See the merge request.

Flatpak applications are based on runtimes such as KDE or Gnome Runtimes. Both of these runtimes are actually based on Freedesktop SDK which contains essential libraries and services such as Wayland or D-Bus.

Recently there were a lot of discussion about supply chain attacks, so it might be interesting to ask how Freedesktop SDK was built. The answer can be found in freedesktop-sdk repository:

sources:
- kind: ostree
  url: freedesktop-sdk:releases/
  gpg-key: keys/freedesktop-sdk.gpg
  track: runtime/org.freedesktop.Sdk.PreBootstrap/x86_64/21.08
  ref: 0ecba7699760ffc05c8920849856a20ebb3305da9f1f0377ddb9ca5600be710b

So it is built using an older version of Freedesktop SDK image. There is now an approved merge request that completely reworks bootstrapping of Freedesktop SDK. It uses another intermediate docker image freedesktop-sdk-binary-seed that bridges the gap between freedesktop-sdk and live-bootstrap.

So what is this live-bootstrap? If you look at parts.rst you’ll see that it is a build chain that starts with 256 byte hex assembler that can build itself from its source and also 640-byte trivial shell that can read list of commands from the file and executes them. Then it proceeds building 130 (as of the moment of writing) other components and in the process builds GCC, Python, Guile, Perl and lots of other supporting packages. Furthermore, each component is built reproducibly (and this is checked using SHA256 hash).

Some caveat: at the moment freedesktop-sdk-binary-seed still uses older binary of rustc to build rustc but in principle one could leverage mrustc to build it. Or possibly rust-gcc will become more capable in future versions and will be able to bootstrap rustc.

So unless your flatpak application uses rust, it will soon be buildable from sub 1 KiB binary seed.

This is a rather small release with only two new features and one small improvement.

Big thank you to Xstrahl Inc. who sponsored development of new features included in this release and of QCoro in general.

And as always, thank you to everyone who reported issues and contributed to QCoro. Your help is much appreciated!

The original release announcement on qcoro.dvratil.cz.

Improved QCoro::waitFor()

Up until this version, QCoro::waitFor() was only usable for QCoro::Task<T>. Starting with QCoro 0.8.0, it is possible to use it with any type that satisfies the Awaitable concept. The concept has also been fixed to satisfies not just types with the await_resume(), await_suspend() and await_ready() member functions, but also types with member operator co_await() and non-member operator co_await() functions.

QCoro::sleepFor() and QCoro::sleepUntil()

Working both on QCoro codebase as well as some third-party code bases using QCoro it’s clear that there’s a usecase for a simple coroutine that will sleep for specified amount of time (or until a specified timepoint). It is especially useful in tests, where simulating delays, especially in asynchronous code is common.

Previously I used to create small coroutines like this:

QCoro::Task<> timer(std::chrono::milliseconds timeout) {
 QTimer timer;
 timer.setSingleShot(true);
 timer.start(timeout);
 co_await timer;
}

Now we can do the same simply by using QCoro::sleepFor().

Read the documentation for QCoro::sleepFor() and QCoro::sleepUntil() for more details.

QCoro::moveToThread()

A small helper coroutine that allows a piece of function to be executed in the context of another thread.

void App::runSlowOperation(QThread *helperThread) {
 // Still on the main thread
 ui->statusLabel.setText(tr("Running"));

 const QString input = ui->userInput.text();

 co_await QCoro::moveToThread(helperThread);
 // Now we are running in the context of the helper thread, the main thread is not blocked

 // It is safe to use `input` which was created in another thread
 doSomeComplexCalculation(input);

 // Move the execution back to the main thread
 co_await QCoro::moveToThread(this->thread());
 // Runs on the main thread again
 ui->statusLabel.setText(tr("Done"));
}

Read the documentation for QCoro::moveToThread for more details.

Full changelog

See changelog on Github

KDE's getting started page on documentation states:

KDE documentation is written in DocBook XML.

Historically, this was probably a good decision. Who does not remember that XML was so much easier to read, parse, and work with compared to binary or virtually any propitiatory file format?

KDE is aiming to bump its major version to 6. This might be a good time to reflect whether DocBook should serve as the sole official documentation language. Well, I would like to open this to an optional second language.

I don't mind what the second language could be; possible candidates are reStructuredText / Sphinx, Markdown, AsciiDoc -- among others. I don't want to convert DocBook to any other format. But giving projects some choice, might help.

I am by far not the only person with regard to a replacement of DocBook: DigiKam recently switched to Sphinx for their user documentation after 20 years of using DocBook. Krita uses Sphinx for five years and Kdenlive for over a year. By the way, the Linux kernel left DocBook for Sphinx, too.

What do you think? This would be a good topic for an Akademy BoF. Where should we discuss this in the meantime?

The XRechnung format is a E-Government standard for electronic invoicing. At some point it will be mandatory for every company dealing with German governmental partners to send the invoices in this XML format.

Many commercial vendors have already caught up and provide ways to generate XRechnung formatted documents with their software. However, to my knowledge, the availability of open source end user software is very limited. Since the standard itself is at least very open and transparently documented, so I think it is worthwhile to also support it with free software on the desktop.

Kraft, the desktop software for invoicing and efficient office work in the small enterprise, supports export of XRechnung documents since a while.

Over the weekend I created a new little project that adds a viewer for XRechnung documents called xrview.

A german city was looking for something to evaluate processes in a Linux- and KDE based productivity work environment.

Technically it is not very sophisticated: It renders the provided XML file using XSL styles officially provided by the Koordinierungsstelle für IT-Standards in a two step process to HTML, which is displayed in a web view. Some values of interest are extracted from the XML and displayed in a detail pane on the left side.

This is just a POC and has to be continued, but the time was good to kickstart this project.

Maybe anybody is interested to create a PR to help to improve digitalization in Germany?

It has been a while since the last blog post covering Qt OPC UA news. This short update will outline what we have primarily worked on in 2022.

Continue reading Qt OPC UA news catch up at basysKom GmbH.

New year, new digiKam Recipes book release. The new version features the completely rewritten Tag faces with the Face Recognition feature chapter and an all-new example workflow section in the Batch process photos and RAW files chapter. Several chapters have been revised and improved, including Edit tags with Tag Manager, Color management in digiKam, and Move digiKam library and databases. All screenshots have been refreshed, too. As always, the new revision includes plenty of tweaks and fixes.