A new Craft cache has just been published. The update is already available for KDE's CD, CI (Windows/Android) will follow in the next days.
Please note that this only applies to the Qt6 cache. The Qt5 cache is in LTS mode since April 2024 and does not recieve major updates anymore.
Changes (highlights)
Craft Core
Drop Python2 support
Require at least Python 3.9
Blueprints
Qt 6.8.0
FFmpeg 7.1
Kirigami Addons 1.5.0
KDE Frameworks 6.7.0
KDE Plasma 6.2.0
Removed snoregrowl
Removed ctemplate
About KDE Craft
KDE Craft is an open source meta-build system and package manager. It manages dependencies and builds libraries and applications from source on Windows, macOS, Linux, FreeBSD and Android.
We have just switched on the upgrade for KDE neon to rebase on Ubuntu 24.04 LTS.
We do this every two years and the 22.04 LTS base was getting increasingly crusty with old Pipewire causing problems and packages like Krita not compiling at all.
The Kubuntu Team is happy to announce that Kubuntu 24.10 has been released, featuring the new and beautiful KDE Plasma 6.1 simple by default, powerful when needed.
Codenamed “Oracular Oriole”, Kubuntu 24.10 continues our tradition of giving you Friendly Computing by integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution.
Under the hood, there have been updates to many core packages, including a new 6.11 based kernel, KDE Frameworks 5.116 and 6.6.0, KDE Plasma 6.1 and many updated KDE gear applications.
Kubuntu 24.10 with Plasma 6.1
Kubuntu has seen many updates for other applications, both in our default install, and installable from the Ubuntu archive.
Applications for core day-to-day usage are included and updated, such as Firefox, and LibreOffice.
For a list of other application updates, and known bugs be sure to read our release notes.
Wayland as default Plasma session.
The Plasma wayland session is now the default option in sddm (display manager login screen). An X11 session can be selected instead if desired. The last used session type will be remembered, so you do not have to switch type on each login.
Note: For upgrades from 24.04, there may a delay of a few hours to days between the official release announcements and the Ubuntu Release Team enabling upgrades.
Kirigami Addons is out. This releases contains mostly code cleanup and minor
improvements. There is netherless a few relevant changes. Thanks to everyone
who contributed some code.
New KAppTemplate’s template
A new KAppTemplate is available as a good starting point for application that
manage multimedia libraries. It is based on shared design of
Peruse,
Arianna and the WIP Calligra Launcher.
Hopefully it helps people who want to develop game launchers and other type of
specialized multimedia applications.
More templates are planned (e.g. for chat applications), so stay tunned!
FormCard
FormCard is the part of Kirigami Addons that received the most changes in this
release. First of all, FormCard now use more consistent spacing and padding,
which slighly less horizontal padding. Descriptions for radio and checkbox
delegates are also put underneath the delegate’s main text and checkbox, in an
effort to make FormCard a bit more compact.
Before
After
Additionally FormComboBoxDelegate now lets you display an inline status
similar to that is available in other FormCard’s delegates.
Finally FormCard.AboutKDE was renamed to FormCard.AboutKDEPage. This improve
the naming consistency with other page compoenents. A compatibility wrapper on
top of AboutKDEPage named AboutKDE is still available to not break any
existing applications.
Deprecations
The Banner component is now deprecated. Kirigami.InlineMessage now has a
position parameter which can be set to Header or Footer. Additionally
with KDE Frameworks 6.8 Kirigami.InlineMessage will look exactly the same as
Banner! So there is no more reasons for this component to exists
in Kirigami Addons.
Other
Kirigami Addons supports static builds with a recent enough version of extra-cmake-modules.
I've been fixing cursor problems on and off in the last few months. Here's a recap of what I've done, explanation of some cursor size problems you might encounter, and how new developments like Wayland cursor shape protocol and SVG cursors might improve the situation.
(I'm by no means an expert on cursors, X11 or Wayland, so please correct me if I'm wrong.)
Why don't we have cursors in the same size anymore?
My involvement with cursors started back in the end of 2023, when KDE Plasma 6.0 was about to be released. A major change in 6.0 was enabling Wayland by default. And if you enabled global scaling in Wayland, especially with a fractional scale like 2.5x, cursor sizes would be a mess across various apps (the upper row: Breeze cursors in Plasma 6.0 Beta 1, Wayland, 2.5x global scale, the lower row: Same cursors in Plasma 6.0):
So I dug into the code of my favorite terminal emulator, Kitty, which at the time drew the cursor in a slightly smaller size than it should be (similar to vscode in the above image). I gained some understanding of the problem, and eventually fixed it. Let me explain.
How to draw cursors in the same size in different apps?
In X11, there used to be a standard set of cursors, but nowadays most apps use the XCursor lib to load a (user-specified) cursor theme and draw the cursor themselves. So in order to have cursors in the same theme and size across apps, we need to make sure that:
Apps get the same cursor theme and size from the system.
Apps draw the cursor in the same way.
The transition to Wayland created difficulties in both points:
1. Get the same cursor theme and size from the system
It used to be simple in X11: we have Xcursor.size and Xcursor.theme in xrdb, also XCURSOR_SIZE and XCURSOR_THEME in environment variables. Setting them to the same value would make sure that all apps get the same cursor theme and size.
But Wayland apps don't use xrdb, and they interpret XCURSOR_SIZE differently: in X11, the size is in physical pixels, but in Wayland it's in logical pixels. E.g., if you have a cursor size 24 and global scale 2x, then in X11, XCURSOR_SIZE should be 48, but in Wayland it should be 24.
The Wayland way is necessary. Imagine you have two monitors with different DPI, e.g. they are both 24" but monitor A is 1920x1080, while monitor B is 3840x2160. You set scale=1 for A and scale=2 for B, so UI elements would be the same size on both monitors. Then you would also want the cursor to be of the same size on both monitors, which requires it to have 2x more physical pixels on B than on A, but it would be the same logical pixels.
So Plasma 6.0 no longer sets the two environment variables, because XCURSOR_SIZE can't be simultaneously correct for both X11 and Wayland apps. But without them and xrdb, Wayland apps no longer have a standard way to get the cursor theme and size. Instead, different frameworks / toolkits have their own ways. In Plasma, KDE / Qt apps get them from the Qt platform integration plugin provided by Plasma, GTK4 apps from ~/.config/gtk-4.0/settings.ini (also set by Plasma), Flatpak GTK apps from the GTK-specific configs in XDG Settings Portal.
The last one is particularly weird, as you need to install xdg-desktop-portal-gtk in order fix Flatpak apps in Plasma, which surprised many. It might seem like a hack, but it's not. Plasma officially recommends installing xdg-desktop-portal-gtk, and this was suggested by GNOME developers.
But what for 3rd-party Wayland apps besides GTK and Qt? The best hope is to read settings in either the GTK or the Qt way, piggy-backing the two major toolkits, assuming that the DE would at least take care of the two.
(IMHO either Wayland or the XDG Settings Portal should provide a standard way for apps to get the cursor theme and size.)
That was part of the problem in Kitty. It used to read settings from the GTK portal, but only under a GNOME session. I changed it to always try to read from the portal, even if under Plasma. But that's not the end of the story...
2. Draw the cursor in the same way
It's practically a non-issue in X11, as the user usually sets a size that the cursor theme provides, and the app just draws the cursor images as-is. But if you do set a cursor size not available in the theme (you can't do that in the cursor theme settings UI, but you can manually set XCURSOR_SIZE), you'll open a can of worms: various toolkits / apps deal with it differently:
Some just use the closest size available (Electron and Kitty at the time), so it can be a bit smaller.
Some use the XCursor default size 24, so it's a lot smaller.
Some scale the cursor to the desired size, and the scaling algorithm might be different, resulting in pixelated or blurry cursors; Also they might scale from either the default size or the closest size available, resulting in very blurry (GTK) or slightly blurry (Qt) cursors.
The situation becomes worse with Wayland, as the user now specifies the size in logical pixels, then apps need to multiply it by the global scale to get the size in physical pixels, and try to load a cursor in that size. (If the app load the cursor in the logical size, then either the app or the compositor needs to scale it, resulting in a blurry / pixelated cursor.) With fractional scaling, it's even more likely that the required physical size is not available in the theme (which typically has only 2~5 sizes), and you see the result in the picture above.
One way to fix it (and why I didn't do)
It can be fixed by moving the "when we can't load cursors in the size we need, load a different size and scale it" logic from apps / toolkits to the XCursor lib. When the app requests cursors in a size, instead of returning the closest size available, the lib could scale the image to the requested size. So apps would always get the cursor in the size they ask for, and their own different scaling algorithms won't get a chance to run.
Either the default behavior can be changed, or it can be hidden behind a new option. But I didn't do that, because I felt at the time that it would be difficult to either convince XCursor lib maintainers to make a (potentially breaking) change to the default behavior, or to go around convincing all apps / toolkits to use a new option.
My fix (or shall we say workaround)
Then it came to me that although I can't fix all these toolkits / apps, they seem to all work the same way if the required physical size is available in the theme - then they just draw the cursor as-is. So I added a lot of sizes to the Breeze theme. It only has size 24, 36 and 48 at the time, but I added physical sizes corresponding to a logical size 24 and all global scales that Plasma allows, from 0.5x to 3x, So it's 12, 18, 24 ... all the way to 72.
It was easy. The source code of the Breeze theme is SVG (so are most other themes). Then a build script renders it into images using Inkscape, and packages them to XCursor format. The script has a list of the sizes it renders in, so I added a lot more.
And it worked! If you choose Breeze and size 24, then (as in the bottom row in the picture above) various apps draw the cursor in the same size at any global scale available in Plasma.
But this method has its limitations:
We can't do that to 3rd-party themes, as we don't have their source SVG.
It only works if you choose the default size 24. If you choose a different size, e.g. 36, and a global scale 3x, then the physical size 36x3=108 is not available in the theme, and you see the mess again. But we can't add sizes infinitely, as explained in Vlad's blog, the XCursor format stores cursor images uncompressed, so the binary size grows very fast when adding larger sizes.
Both limitations can be lifted with SVG cursors. But before getting to that, let's talk about the "right" way to fix the cursor size problem:
The "right" fix: Wayland cursor shape protocol
The simple and reliable way to get consistent cursors across apps is to not let apps draw the cursor at all. Instead, they only specify the name of the cursor shape, and the compositor draws the cursor for them. This is how Wayland cursor shape protocol works. Apps no longer need to care about the cursor theme and size (well, they might still need the size, if they want to draw custom cursors in the same size as standard shapes), and since the compositor is the only program drawing the cursor, it's guaranteed to be consistent for all apps using the protocol.
(It's quite interesting that we seem to went a full circle back to the original server-defined cursor font way in X11.)
Support for this protocol leaves a lot to improve, though. Not all compositors support it. On the client side, both Qt and Electron have the support, but GTK doesn't.
There are merge requests for GTK and Mutter, but GNOME devs request some modifications in the Wayland protocol before merging them, and the request seems to be stuck for some months. I hope the recent Wayland "things" could move it out of this seemingly deadlock.
Anyway, with this protocol, only the compositor has to be modified to support a new way to draw cursors. This makes it much easier to change how cursors work. So we come to:
SVG cursors
Immediately after the fix in Breeze, I proposed this idea of shipping the source SVG files of the Breeze cursor theme to the end user, and re-generate the XCursor files whenever the user changes the cursor size or global scale. This way, the theme will always be able to provide the exact size requested by apps. (Similar to the "modify XCursor lib" idea, but in a different way.) It would remove the limitation 2 above (and also limitation 1 if 3rd-party themes ship their source SVGs too).
With SVG cursors support in KWin and Breeze, I plan to implement this idea. It would also allow the user to set arbitrary cursor size, instead of limited to a predefined list.
Problems you might still encounter today
Huge cursors in GTK4 apps
It's a new problem in GTK 4.16. If you use the Breeze cursor theme and a large global scale like 2x or 3x, you get huge cursors:
It has not limited to Plasma. Using Breeze in GNOME would result in the same problem. To explain it, let me first introduce the concept of "nominal size" and "image size" in XCursor.
Here is GNOME's default cursor theme, Adwaita:
"Nominal size" is the "cursor size" we are talking about above. It makes the list of sizes you choose from in the cursor theme settings UI. It's also the size you set in XCURSOR_SIZE. "Image size" is the actual size of the cursor image. "Hot spot" is the point in the image where the cursor is pointing at.
Things are a bit different in the Plasma default cursor theme, Breeze:
Unlike Adwaita, the image size is larger than the nominal size. That, combined with a global scale, triggers the bug in GTK4. Explanation of the bug.
XCursor allows the image size to be different from the nominal size. I don't know why it was designed this way, but my guess is so you can crop the empty part of the image. This both reduces file size, and reduces flicking when the cursor changes (with software cursors under X11). But the image size can also be larger than the nominal size, and Breeze (and a lot of other themes) uses this feature.
You can see in the above images that the "arrow" of nominal size 24 in Breeze is actually similar in size to the same nominal size in Adwaita. But the "badge" in Breeze is further apart, so it can't fit into a 24x24 image. That's why Breeze is built this way. In a sense, "nominal size" is similar to how "font size" works, where it resembles the "main part" of a character in the font, but some characters can have "extra parts" that go through the ceiling or floor.
This problem is already fixed in the main branch of GTK 4, but it's not backported to 4.16 yet, probably because the fix uses a Wayland feature that Mutter doesn't support yet. So at the moment, your only option is to use a different cursor theme whose "nominal size" and "image size" are equal.
Smaller cursors in GTK3 apps (most notably, Firefox)
The cursor code in GTK3 is different from GTK4, with its own limitations. You might find the cursor to be smaller than in other apps, and if you run the app in a terminal, you might see warnings like:
cursor image size (64x64) not an integer multiple of scale (3)
GTK3 doesn't support fractional scales in cursors. So if you have cursor size 24 and global scale 2.5x or 3x, it will use a scale 3x and try to load a cursor with a nominal size 24x3=72. And it requires the image size to be an integer multiple of the scale. So if your theme doesn't have a size 72, or it does but the image size is not multiple of 3, GTK3 fallbacks to a smaller unscaled cursor.
End words
OK, this is a long post. Hope I can bring you more cursor goodies in Plasma 6.3 and beyond.
After almost a year, we’re very pleased to announce a new release of KPhotoAlbum, the Linux/KDE photo management software!
There are two new features/changes:
The “time ago”/birthday/age calculation has been reworked. Timespans should now be displayed in a nicer (more natural) way. Also, the age of people born on February 29 is now calculated correctly.
The ‘--db’ command line argument now rejects any file name that is not either an existing directory or an index.xml file within an existing directory (cf. Bug #418647).
One additional change that should be mostly interesting for the distributors is: The key used for signing the release has been updated. All PGP keys used to sign KDE software releases can be found in the sysadmin/release-keyring repo. My currently used key that I used to sign the tarball can also be found there, cf. tleupold@key2.asc.
… and what about Qt 6?!
Fear not! Of course, there will be a Qt6/KF6 release of KPhotoAlbum. We currently have a working Qt6/KF6 branch, so most of the porting is already done. Last thing that’s missing is a Qt6/KF6 release of Marble, which we use to display maps for geographic coordinates in photos (preferrably stored there using KGeoTag ;-). It seems like there will be such a release towards the end of the year. We will get KPhotoAlbum ready for Qt6/KF6 shortly afterwards. Stay tuned!
According to git log, the following individuals contributed commits since the last release:
The Google Summer of Code Mentor Summit is an annual
unconference that every project participating in Google Summer of Code
2024 is invited to attend. This year it was the 20th year celebration of the program!
I was too late to take a picture of the full cake!
We attended many sessions ranging from how to try to avoid falling into the "xz problem" to collecting donations or shaping the governance of open source projects.
We met lots of people that knew what KDE was and were happy to congratulate us on the job done and also a few that did not know KDE and were happy to learn about what we do.
We also did a quick lightning talk about the GSOC projects KDE mentored this year and led two sessions: one centered around the problems some open source application developers are having publishing to the Google Play Store and another session about Desktop Linux together with our Gnome friends.
All in all a very productive unconference. We encourage KDE mentors to take the opportunity to attend the Google Summer of Code Mentor Summit next year, it's a great experience!
[1] me and Albert Vaca, people were moderately amused that both of us had the same name, contribute to the same community and are from the same city.
SVG cursor themes is a new feature in Plasma 6.2, which we are really excited about. In this blog post, I would like to provide more background behind what motivated us to add support for them, what they are, and how to build them.
(Classic) cursor theme format
A cursor theme is a collection of images defining the contents of various cursor shapes and additional metadata (for example, the human readable name of the theme, whether the cursor theme inherits/extends another cursor theme, etc). On disk, it looks as follows
The cursors/ directory contains a list of Xcursor files and symbolic links to represent cursor shape aliases, e.g. the arrow being an alias for default. The XCursor format has been in use for a very long time now and it has a pretty simple structure
The layout of an XCursor file
An XCursor file consists of a header that includes a magic number to determine whether particular file is actually an XCursor file, the size of the header in bytes, the file version, and the number of ToC entries. Every ToC entry provides the information about the corresponding chunk, for example the chunk type and where the chunk can be found in the file. Lastly, a chunk contains some useful data. A chunk may contain image data or text data, etc.
For example, here’s the image data that can be found in the “default” cursor shape file in the Adwaita cursor theme
As you can see, the Adwaita cursor theme provides the following sizes: 24, 32, 48, 64, and 96.
The index.theme files looks as follows
[Icon Theme]
Inherits=breeze_cursors
Name=Cool Cursor
Comment=That is a cool cursor theme
Cursor themes can be found in $DATADIR/icons directories. For example, /usr/share/icons or ~/.local/share/icons.
X11 vs Wayland cursors
Xcursor cursors are used both on X11 and Wayland, but the way how the cursor size is interpreted is different on the two platforms. X11 assumes that the cursor size is specified in the device pixels, while Wayland assumes that it’s in the logical pixels. Logical pixels have the same visual size across various devices, while physical pixels are specific to particular device. For example, 24 logical pixels on an output with a scale factor of 2 corresponds to 48 physical pixels.
Cursor sizes in Xcursor files are specified in the device pixels.
Another very important detail is that the XCURSOR_SIZE environment variable is treated differently by X11 and Wayland native applications. For example, if XCURSOR_SIZE is set to 24 and the output scale is 2, an X11 application would load a cursor with the size 24, but a Wayland application would effectively load a cursor with the size 48 (24 * 2) because it would see that the output is scaled so the provided cursor needs to be scaled accordingly as well.
“XCURSOR_SIZE=24 dolphin -platform xcb” (left) vs “XCURSOR_SIZE=24 dolphin -platform wayland” (right). Note that “Apply scaling themselves” has been selected in the display settings in Plasma Wayland
Limitations of Xcursor
The most painful thing about Xcursor is its lack of the proper HiDPI support. As it was said in the previous chapter, the cursor size in Xcursor files is specified in the device pixels. On X, it’s not a problem because all geometries are specified in the device pixels. It also means that if you change the scaling factor on X, you need to change the cursor size manually so the cursor is not too small. On Wayland, the cursor size is specified in the logical pixels so the compositor and the clients have to scale the cursor size in order to match the output scale. For example, if the configured cursor size is 24 and the window is on an output with a scale factor of 2, the application needs to load an Xcursor cursor with the size 48. If the cursor theme provides cursors with such a size, perfect! But what if it doesn’t? At the moment, every compositor and client applies its own policies. Some find the cursor with the closest size and use that, some find the cursor with the closest size and then scale it to match the requested size at the cost of adding some blurriness, and so on. It’s a mess. Because neither compositors nor clients can agree how to handle such a case, you could easily observe the cursor changing its size when moving between windows owned by different applications or when moving the cursor between the window and its decoration, e.g.
A script element has been removed to ensure Planet works properly. Please find it in the original post.
It’s worth noting though that this issue can be worked around by using the cursor-shape protocol because with it, the application can delegate the compositor the task of loading and displaying cursors. But the bottom line is that the Xcursor format is unsuitable for the HiDPI model that we have present on Wayland.
Another issue with the Xcursor format is that the image data is stored in an uncompressed format. It is okay if you need to provide cursors with small sizes, for example up to 72, but there are cases when you need to display a cursor at a very large size. For example, one such a case is the shake cursor accessibility feature in the Plasma Wayland session.
With the shake cursor feature enabled, the cursor will be inflated when it’s shaken. In order to operate, it needs to load the default cursor shape with a size around 250. If cursor themes provided images for such sizes, their package sizes would easily blow up beyond the 100MiB mark. That’s not good. And as a workaround, in Plasma 6.1, the shake cursor uses its own high resolution images of the Breeze cursor themes.
A script element has been removed to ensure Planet works properly. Please find it in the original post.
Shake cursor without any workarounds in 6.1
A script element has been removed to ensure Planet works properly. Please find it in the original post.
Shake cursor with workarounds in 6.1
The XCursor format was perfectly suitable for the use cases that existed back in the late 90s and early 2000s, but things have changed over the years and its current raster nature can’t keep up with the use cases that we have now (2024). We’ve got fractional scaling, we’ve got accent colors, we’ve got features that enlarge the cursor, and so on.
SVG cursor format
First of all, let’s build a list of requirements that the svg cursor format must satisfy:
obviously, it must support the ability to define cursor contents using svg files so we can fix HiDPI issues, etc
easy porting process for existing clients and compositors
it should be easy to develop and analyze svg cursor themes. Xcursor is a binary file format, which requires a special tool to create Xcursor files, we would like to avoid that with svg cursors
last and the most important requirement is that there must be some compatibility with the existing cursor theme format. We must not be required to write a new system settings module to handle the new cursor format, and the apps that don’t support svg cursors should easily fallback to the Xcursor format.
Here’s how a cursor theme providing svg cursors would look like
index.theme has the same format both for XCursor and SVG cursors. cursors/ directory contains the XCursor cursors, and cursors_scalable/ contains the SVG cursors.
In cursors_scalable/, every cursor shape must have its own directory, or if it’s an alias, then it must be a symlink. Every cursor shape directory must contain the cursor image and a metadata.json file providing the information about the cursor.
For a static cursor, the metadata.json file looks as follows
The filename property specifies the filename of the svg file. The hotspot_x and the hotspot_y properties specify the coordinates of the hot spot. The hot spot in the cursor determines the point where interaction with other elements on the screen occurs, e.g. clicks. The nominal_size property specifies the cursor size that the svg file represents. The nominal size is used to decide how much the svg image and the hotspot coordinates need to be scaled in order to get a cursor with the requested size. Note that the nominal size can’t be determined based on the <svg>‘s width and height attributes because there exist themes such as Breeze whose canvas is bigger than the represented cursor size. As an example, in the Breeze cursor theme, the canvas size is 32x32 even though the represented cursor size is 24 in order to accommodate for additional elements that can be attached to the arrow cursor, e.g. a little circle with a plus sign or a question mark.
For an animated cursor, the metadata.json file looks as follows
The only new thing is the delay property. The delay property indicates the animation delay to the next frame.
A cursor theme that ships SVG cursors is required to have XCursor cursors too. This is needed to provide fallback for legacy applications that are unaware of the cursor-shape-v1 protocol or simply too old applications that are unlikely to be changed anymore. This restriction might be lifted in the future.
It is worth mentioning that SVG supports animations natively. However, that approach was not chosen for cursor animations for two reasons: to allow caching svg render results more easily and require fewer changes in the compositors and the apps to adapt the svg cursor format.
You can find the json schema for metadata.jsonover here.
Accent colors
Since the cursor contents is specified using the SVG format, it should be possible to re-color the cursor based on the currently configured accent color. As of now, it is not implemented, but, in general, this is doable and perhaps such a feature will be added to Plasma some day.
Standardization
This cursor format is not officially standardized. We are looking forward to making it upstream, but for now, the main focus is on confirming that the new format lives up to our and cursor creator needs.
To cursor theme creators
Breeze and Breeze Light are the only two cursor themes that support SVG cursors at the moment, but we would love to see custom themes adapting them too so users experience fewer issues with fractional scaling or other features in Plasma when using their favorite 3rdparty cursor themes. We would also like to hear feedback from the cursor theme creators regarding whether it’s easy to adapt this cursor format or whether some additional features are needed. You can reach out to us at Matrix in the #kwin room https://webchat.kde.org/#/room/#kwin:kde.org or in the kwin mailing list.
Examples
If you need an example of a cursor theme that supports SVG cursors, please check the Breeze cursor theme.
Closing words
The new SVG cursor format is amazing. Please try it!
A long over-due release which has accumulated a bunch of bugfixes but also some
fancy new features…read on!
As always, big thanks to everyone who reported issues and contributed to QCoro.
Your help is much appreciated!
QCoro::LazyTask<T>
The biggest new features in this release is the brand-new QCoro::LazyTask<T>.
It’s a new return type that you can use for your coroutines. It differs from QCoro::Task<T>
in that, as the name suggest, the coroutine is evaluated lazily. What that means is when
you call a coroutine that returns LazyTask, it will return imediately without executing
the body of the coroutine. The body will be executed only once you co_await on the returned
LazyTask object.
This is different from the behavior of QCoro::Task<T>, which is eager, meaning that it will
start executing the body immediately when called (like a regular function call).
QCoro::LazyTask<int> myWorker()
{
qDebug() <<"Starting worker";
co_return42;
}
QCoro::Task<> mainCoroutine()
{
qDebug() <<"Creating worker";
constauto task = myWorker();
qDebug() <<"Awaiting on worker";
constauto result =co_await task;
// do something with the result
}
This will result in the following output:
mainCoroutine(): Creating worker
mainCoroutine(): Awaiting on worker
myWorker(): Starting worker
If myWorker() were a QCoro::Task<T> as we know it, the output would look like this:
mainCoroutine(): Creating worker
myWorker(): Starting worker
mainCoroutine(): Awaiting on worker
The fact that the body of a QCoro::LazyTask<T> coroutine is only executed when co_awaited has one
very important implication: it must not be used for Qt slots, Q_INVOKABLEs or, in general, for any
coroutine that may be executed directly by the Qt event loop. The reason is, that the Qt event loop
is not aware of coroutines (or QCoro), so it will never co_await on the returned QCoro::LazyTask
object - which means that the code inside the coroutine would never get executed. This is the
reason why the good old QCoro::Task<T> is an eager coroutine - to ensure the body of the coroutine
gets executed even when called from the Qt event loop and not co_awaited.
Defined Semantics for Awaiting Default-Constructed and Moved-From Tasks
This is something that wasn’t clearely defined until now (both in the docs and in the code), which is
what happens when you try to co_await on a default-constructed QCoro::Task<T> (or QCoro::LazyTask<T>):
co_await QCoro::Task<>(); // will hang indefinitely!
Previously this would trigger a Q_ASSERT in debug build and most likely a crash in production build.
Starting with QCoro 0.11, awaiting such task will print a qWarning() and will hang indefinitely.
The same applies to awaiting a moved-from task, which is identical to a default-constructed task:
QCoro::LazyTask<int> task = myTask();
handleTask(std::move(task));
co_await task; // will hang indefinitely!`
Compiler Support
We have dropped official support for older compilers. Since QCoro 0.11, the officially supported compilers are:
GCC >= 11
Clang >= 15
MSVC >= 19.40 (Visual Studio 17 2022)
AppleClang >= 15 (Xcode 15.2)
QCoro might still compile or work with older versions of those compilers, but we no longer test it and
do not guarantee that it will work correctly.
The reason is that coroutine implementation in older versions of GCC and clang were buggy and behaved differently
than they do in newer versions, so making sure that QCoro behaves correctly across wide range of compilers was
getting more difficult as we implemented more and more complex and advanced features.
If you enjoy using QCoro, consider supporting its development on GitHub Sponsors or buy me a coffee
on Ko-fi (after all, more coffee means more code, right?).
Edit 2024-10-28: applications for these positions are closed. KDE e.V., the non-profit organization supporting the KDE community, and the Kdenlive team are looking for proactive contractors to implement some features in the Kdenlive video editor. Two positions are currently open:
OpenTimelineIO integration: this will require implementing a C++ module in Kdenlive to allow importing and exporting using this open standard, to allow exchanging project files with other applications. Please see the job ad for more details about this contracting opportunity.
Audiowaveform integration: this will require rewriting the code used to generate and display the audio waveforms in Kdenlive using the audiowaveform library. This should bring faster and more precise waveforms in the timeline. Please see the job ad for more details about this contracting opportunity.
We are looking forward to your application.
@jlskuz:kde.org
CarlSchwan
