Thursday, 14 March 2024
We are happy to announce the release of Qt Creator 13 RC!
We are happy to announce the release of Qt Creator 13 RC!
In today’s pervasively digital landscape, building software for a single platform is a 1990s approach. Modern applications, even those designed for specific embedded targets, must be adaptable enough to run seamlessly across various platforms without sacrificing efficiency or reliability.
This is often easier said than done. Here are some key points to consider when developing and testing multi-platform embedded software.
When developing software, especially in the initial stages, testing and debugging often don’t happen on the final hardware but on development machines. That, and a frequent lack of target hardware means it’s a good idea to produce a build that can run within a virtual machine or container. Dedicating time and effort in developing custom hardware emulation layers and specialized build images pay off by enabling anyone in the test or development team to run a virtualized version of the final product.
Many product lines offer multiple hardware variants, with differing screen sizes and capabilities. Depending on the severity of the differences, these variants might require dedicated builds, potentially extending the time and resources devoted to your project. To avoid proliferating build configurations, consider enabling the software to auto-adapt to its hardware environment, provided it can be done reliably and without too much effort.
Does your embedded product need to interface with a companion mobile app? These apps often handle remote configuration, reporting, and user profiles, enhancing product functionality and user experience. If so, consider using a cross-platform tool kit or framework to build your software. These allow you to share your business logic and UI components between iOS, Android, and your embedded platform. You can choose to reuse UI components in a stripped-down version of your application written specifically for mobile, or write the application once and have it adjust its behavior depending on the screen size and other hardware differences.
The key to successful multi-platform development is striking a balance between efficiency and coverage. Here are some strategies to consider.
When dealing with multiple platforms, decide if it’s necessary to cross-compile for every platform with each commit. While this ensures up-to-date software for all variants, it can significantly extend the length of the build cycle. Consider reserving certain platforms for daily or less frequent builds to maintain a balance between speed and thoroughness.
Establish a robust build system with dedicated build computers, well-defined build scripts, and effective notification systems. Assign one person to oversee the build system and infrastructure to ensure its reliability and maintenance.
Transitioning from a traditional build approach to a continuous integration (CI) system is beneficial in the long run, especially when you’re managing multiple platforms. However CI demands automated builds, comprehensive unit testing, and automated test scripts. Despite this up-front investment, CI pays off by reducing bugs, enhancing release reliability, and speeding up maintenance changes.
As much as possible, incorporate the “hard” testing bits into your automated testing/CI process – in other words, integration and user interface testing. These tests, while more complex to set up, significantly contribute to the robustness of your software. What works flawlessly in an emulated desktop environment may behave differently on the actual hardware, so ensure your testing procedures also include hardware target testing.
Developing and testing software for multiple platforms requires a commitment to maintaining quality. For additional insights into ensuring your software’s versatility, reliability, and efficiency across all target platforms, read our best practices guide on Designing Your First Embedded Device: The Development Environment.
If you like this article and want to read similar material, consider subscribing via our RSS feed.
Subscribe to KDAB TV for similar informative short video content.
KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.
The post Streamlining Multi-platform Development and Testing appeared first on KDAB.
It's 2024 already, and even already March. Like last year, we had a video call with all sponsored developers, artists and volunteers to discuss what we achieved last year, figure out the biggest issues we're facing and set the priorities for this year.
A very serious issue is that the maintainer of the Android and ChromeOS port of Krita has become too busy to work on Krita full-time. The Android and ChromeOS versions of Krita both use the Android platform, and that platform changes often and arbitrarily. This means that Sharaf has spent almost all of his time keeping Krita running on Android (and ChromeOS), instead of, as we had planned, work on a dedicated tablet user interface for Krita on Android. And since that maintenance work now is not being done, we're having a really big problem there. Additionally, since KDE has retired the binary factory and moved binary builds to invent.kde.org's continuous integration system, we don't have automatic builds for Android anymore.
We've also lost another sponsored developer. They were sick for quite some time, but recently they blogged they had started to work a different job. Since they were especially working on maintaining the libraries Krita is dependent on and were very good at upstreaming fixes, they will also really be missed.
Finally, we got Krita into the Apple MacOS store last year. However, two years ago, Krita's maintainer, that's me, changed her legal name. Now the certificates needed to sign the package for the store have expired, and we needed to create new certificates. Those have to have the signer's current legal name, and for some reason, it's proving really hard get the store to allow that the same developer, with the same ID and code but a different legal name to upload packages. We're working on that.
Of course, we released Krita 5.2 and two bugfix releases for Krita 5.2. We'll do at least one other bugfix release before we release Krita 5.3.
The audio system for Krita's animation feature got completely overhauled, ported away from Qt's QtMultimedia system to MLT, The storyboard feature got improved a lot, we gained JPEG-XL support just in time for Google's Chrome team to decide to drop it, because there was nobody supporting it... We also refactored the system we use to build all dependent libraries on all platforms. Well, work on MacOS is still going on, with PyQt being a problem point. Of course, there were a lot of other things going on as well.
Wolthera started rewriting the text object, and mostly finished that and now is working on the tool to actually write, modify and typeset text. This is a huge change with very impressive results!
Parts of this list is from last year, part of it is new.
One big caveat: now that the KDE project has released the first version of KDE Frameworks for Qt6, porting Krita to Qt6 is going to have to happen. This is a big project, not just because of disappearing functions, but very much because of the changes to the support for GPU rendering. On Windows, OpenGL drivers are pretty buggy, and because of that, Qt5 offered the possibility to use the Angle compatibility layer between applications that use OpenGL and the native Direct3D library for GPU rendering. That's gone, and unless we rewrite our GPU rendering system, we need to put Angle back into the stack.
All in all, it's pretty likely that porting to Qt6 will take a lot of time away from us implementing fun new features. But when that is done we can start working on a tablet-friendly user interface, provided we can still release Krita for Android.
That's not to say we don't want to implement fun new featurs!
Here's the shortlist:
We also discussed using the GPU for improving performance. One original idea was to use the GPU for brushes, but the artists argued that the brush performance is fine, and what's way too slow are the liquefy transform tool, transform masks and some filters. In the end, Dmitry decided to investigate
And there's the most controversial thing of all: should we add AI features to Krita? We have had several heated discussions amongst developers and artists on the mailing list and on invent.kde.org.
The artists in the meeting argued that generative AI is worthless and would at best lead to bland, repetitive templates, but that assistive AI could be useful. In order to figure out whether that's true, we started investigating one particular project: AI-assisted inking of sketches. This is useful, could replace a tedious step when doing art while still retaining the artistic individuality. Whether it will actually make it to Krita is uncertain of course, but the investigation will hopefully help us understand better the issue, the possibilities and the problems.
Note: we won't be implementing anything that uses models trained on scraped images and we will make sure that the carbon footprint of the feature doesn't exceed its usefulness.
Tuesday, 12 March 2024. Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.0.2.
This release adds a week's worth of new translations and fixes from KDE's contributors. The bugfixes are typically small but important and include:
The team is thrilled to introduce the much-anticipated release of Kdenlive 24.02, featuring a substantial upgrade to our frameworks with the adoption of Qt6 and KDE Frameworks 6. This significant under-the-hood transformation establishes a robust foundation, shaping the trajectory of Kdenlive for the next decade. The benefits of this upgrade are particularly noteworthy for Linux users, as improved Wayland support enhances the overall experience. Additionally, users on Windows, MacOS, and Linux will experience a substantial performance boost since Kdenlive now runs natively on DirectX, Metal, and Vulkan respectively, replacing the previous abstraction layer reliance on OpenGL and Angle, resulting in a more efficient and responsive application. This upgrade brings significant changes to packaging, featuring the introduction of a dedicated package for Apple Silicon, the discontinuation of PPA support and an enhanced method for installing the Whisper and Vosk speech-to-text engines.
While a significant effort has been invested in providing a stable user experience in this transition, we want to acknowledge that, like any evolving software, there might be some rough edges. Some known issues include: themes and icons not properly applied in Windows and AppImage, text not properly displayed in clips in the timeline when using Wayland and a crash in the Subtitle Manager under MacOS. Worth noting also is the temporary removal of the audio recording feature pending its migration to Qt6. We appreciate your understanding and encourage you to provide feedback in this release cycle so that we can continue refining and improving Kdenlive. In the upcoming release cycles (24.05 and 24.08), our development efforts will concentrate on stabilizing any remaining issues stemming from this upgrade. We’ll also prioritize short-term tasks outlined in our roadmap, with a specific emphasis on enhancing performance and streamlining the effects workflow.
In terms of performance enhancements, this release introduces optimized RAM usage during the import of clips into the Project Bin. Furthermore, it addresses Nvidia encoding and transcoding issues with recent ffmpeg versions.
To safeguard project integrity, measures have been implemented to prevent corruptions. Projects with non-standard and variable frame rates are not allowed to be created. When rendering a project containing variable frame rate clips, users will receive a warning with the option to transcode these clips, mitigating potential audio-video synchronization issues.
Users can now enjoy the convenience of an automatic update check without an active network connection. Glaxnimate animations now default to the rawr format, replacing Lottie. Furthermore, we’ve introduced an FFv1 render preset to replace the previously non-functional Ut Video. And multiple project archiving issues have been fixed.
Beyond performance and stability we’ve managed to sneak in several nifty quality-of-life and usability improvements, the highlights include:
This release introduces multiple subtitle support, allowing users to conveniently choose the subtitle from a drop-down list in the track header.
A subtitle manager dialog has been implemented to facilitate the import and export of subtitles.
Now, in the Import Subtitle dialog, you have the option to create a new subtitle instead of replacing the previous one.
The Speech Editor, our text-based editing tool that enables users to add clips to the timeline from selected texts, now includes the option to create new sequences directly from the selected text.
The initial implementation of the long awaited easing interpolation modes for keyframes has landed. Expected soon are easing types (ease in, ease out and ease in and out) and a graph editor.
The Gaussian Blur and Average Blur filters are now keyframable.
Added the option to set an interpolation method for scaling operations on rendering.
Added the option to apply an effect to a group of clips by simply dragging the effect onto any clip within the group.
Added list of last opened clips in Clip Monitor’s clip name
The Document Checker has been completely rewritten following the implementation of sequences. Now, when you open a project, Kdenlive checks if all the clips, proxies, sequences, and effects are loaded correctly. If any errors are spotted, Kdenlive seamlessly sorts them out in the project files, preventing any possible project corruptions
The post Kdenlive 24.02.0 released appeared first on Kdenlive.
If you have not been following this blog series, I made a wrapper for Firefox to be able to run different tabs (and more) in different KDE Plasma Activities.
Often a hurdle to using a piece of software is that it is not packaged for Linux distros.
Kudos to Aurélien Couderc (coucouf), who packaged already 0.4.1 for Debian and provided the patch to make it easier to package to different distros.
With 0.4.2 version of Activity-aware Firefox we applied that patch. Other then that, the functionality remains the same as in 0.4.1.
Then I also wrote an AUR package, so Arch, EndeavourOS etc. should be covered now too.
As a consequence, Repology now lists 12 distro packages for Activity-aware Firefox – that is a great start!
But while large, Debian- and Arch-based distros are just a subset of all available FOSS operating systems that KDE Plasma and Firefox run on. If someone were to put it on Open Build Service to cover also RPM-based and other distros, that would be a great boon!
Contributions welcome, as I am reaching the limit of my skills here.
hook out → server migration successful – more on that some other day
In today’s other blog post, I mentioned how we’ve been getting a huge number of bug reports since the Mega-Release. If you’re not in software engineering, this probably seems like a bad thing. “Oh no, why so many bugs? Didn’t you test your software properly!?”
Since most people are not involved in software engineering, this perspective is common and understandable. So I’d like to shed a light on the assumptions behind it, and talk about the challenges involved in improving software quality, which is a passion of mine.
See, bug reports are a “don’t kill the messenger” type of thing. Bugs are there whether they get reported or not, and getting them reported is important so you have a more accurate picture of how your software is actually being used by real people in the real world.
In our KDE world, the alternative to “lots of bug reports” isn’t “few bug reports because there are few bugs” but rather “few bug reports because the software isn’t actually being used much so no one is finding the bugs.” What matters more is the severity of the actionable bug reports.
That sounds so defeatist! Surely it must actually be possible to have bug-free software, right?
Yes. But to achieve it, you have to test literally every possible thing the software can do to make sure it performs correctly in the environment in which it’s doing it. If the software can do infinite things in infinite environments, then testing also becomes infinite and therefore impossible, so combinations get missed and bugs sneak through. Bug-free software must aggressively limit the scope and variety of those environments to just the ones that can be tested. What does that look like in practice?
Does this sound very much like how KDE software is developed, distributed, and used? I’d say it’s more like how Apple builds products (and note that Apple products still have bugs, but I digress)! By contrast: KDE develops lots of features and options; we’re liberal with supported library, dependency, and kernel versions; and we don’t prevent you from installing our software on any random device you can get your hands on.
You can see the challenge right away! The foundation of quality is a set of restrictions that we don’t want to impose on ourselves and our users. You folks reading this probably don’t want us to impose them on you, either.
So is it just impossible to ensure quality in a permissive environment? No, but it’s harder. That’s right: we in the KDE free software world set for ourselves a fundamentally more difficult task than the big corporations with their billions of dollars of resources. Given this, I think we’ve done a pretty darn impressive job with the Mega-Release. And judging by initial impressions out there, it seems like many others agree too!
So how did we do it?
We lengthened our beta period to 3 months and relied on bug reports from people using the software in their own personal environments.
Yes you, loyal reader! We wanted to hear how our software was working on your 12-year-old Netbook. We wanted to hear how it worked when plugged into two TVs and a rotated monitor, all through a KVM switch. We wanted to hear how it coped with the most bizarre-looking 3rd-party themes. By using our flexible and non-limited software in your diverse ways on your diverse hardware, you’re testing it and finding all the bugs that we lack the resources to find ourselves.
Does this sort of QA work sound like something you don’t want to do? That’s 100% fine. But then you need for someone else to be the QA team for you. There are two options:
But what if you do want to help out with making the software better for others, but you’re not a programmer? Congratulations, you’re a real-life superhero.
We’ve already talked about reporting bugs. It’s also important to do a good job with your bug reports so they’re actionable! I’ll encourage folks to read through our documentation about this. Low-quality bug reports don’t just waste our time, they waste yours as well!
But where do all those 150-200 bug reports per day that I mentioned actually go? There’s a flip side which is that someone needs to do something with every single one of them. The more bug reports we get (which, again, is good!) the more we need people to help triaging them.
Because the truth is, most bug reports don’t begin life being actionable for developers. They may be missing key information; they may be mistaking a feature for a bug; they may be describing an issue in someone else’s software; they may be about an issue that was already fixed in a version of the software that the reporter doesn’t have; they may be describing a real issue but in an unclear and confusing way; and so on.
The job of bug triagers is to make each of these bug reports actionable. Ask for missing information! Move them to the right products! Set the version and severity appropriately! Mark already reported bugs as duplicates of the existing report! Mark obvious upstream or downstream issues accordingly and direct people to the places where they can report the bugs to the responsible developers! Try to reproduce the issue yourself and mark it as confirmed if you can! And so on. It isn’t terribly glamorous work, so there aren’t very many people lining up to be volunteer bug triagers, unlike developers. But it’s very important. And so every person who helps out adds resources to what’s currently a very small team, making a massive difference in the process.
If you’ve been looking for a way to help out KDE in a way that doesn’t require programming or a consistent time commitment, this is it. Triage a few bugs here, a few bugs there. Chip in when you can. If 30 people each triaged three bugs a day (this would take under 10 minutes, on average), we’d be in an amazing position.
So get started today! I’m available to help in the #kde-bugs
Matrix room.
Still don’t wanna? Donate to KDE e.V. so we can eventually hire our own professional bug triage and QA team!
With KDE’s Frameworks 6 being released recently, I’ve been working on getting Tellico to compile with it. It didn’t actually take too much work since I’ve been gradually porting away from any deprecated functions in Qt5.
There’s plenty to do to make sure everything is fully functional and has the correct appearance. But I’m hopeful to have a release soon. At the moment, the master branch compiles with either KF5/Qt5 or KF6/Qt6.
The floodgates are fully open and developers have started landing juicy features for Plasma 6.1!
But not just that… we asked for bug reports and you folks gave us bug reports! Usually we get 30-50 per day, but now we’re up to 150-200. It’s kind of crazy.
Now, this doesn’t mean the software is actually really buggy. It means that people are using the software! Most of the bug reports actually not about KDE issues at all: graphics driver issues, bugs in themes, and bugs in 3rd-party apps. And many are duplicates of existing known issues, or really weird exotic issues only reproducible with specific combinations of off-by-default settings.
Of course some are more significant, but at this point I think we’ve got most of them fixed. There are still a couple open–such as slow login and black lock screens with certain setups–but both have open merge requests to fix them, so I expect those to be fixed pretty soon too.
You can now split embedded terminal views in Kate horizontally or vertically (Akseli Lahtinen, Kate 24.05. Link)
You can now configure whether the magnifier in Spectacle’s Rectangular Region mode is always on, always off, or only on while holding down the Shift key (Noah Davis, Spectacle 24.05. Link)
There are now “edge barrier” and “corner barrier” features when you’ve using a multi-screen setup. These barriers add virtual spacing between screens, so that it’s easier for you to click on the pixels touching shared screen edges. Why would you want to do this? For example to make auto-hide panels between screens possible, and to make it easy to click the close button of a maximized window with another screen next to it. Note that these features are Wayland-only. And yes, you can turn these features off if you don’t like them, and also adjust the size of the barrier’s virtual space (Yifan Zhu, Plasma 6.1):
You can now hide the Web Browser widget’s navigation bar, making it suitable for cases where it’s simply monitoring the same web page you never navigate away from (Shubham Arora, Plasma 6.1. Link)
Manual session saving now works on Wayland. Note that until real session restore is added, this will be hooking into the “real fake session restore” feature I blogged about a few weeks ago (David Edmundson, Plasma 6.1. Link)
When you have Spectacle configured to not take a screenshot when launched, the window that appears on launch now gives you the opportunity to take a screen recording too (Noah Davis, 24.05. Link)
Search results for pages in System Settings now better prioritize exact name matches (Alexander Lohnau, Plasma 6.0.1. Link)
Using a keyboard shortcut to activate the Calculator widget on a Panel now passes focus to it correctly so you can start typing to calculate things immediately (Marco Martin, Plasma 6.0.2. Link)
When using the Kicker Application Menu launcher, you can now do calculation and unit conversion, and find the power and session actions by searching for them (me: Nate Graham, Plasma 6.1. Link)
The new “Shake cursor to find it” effect is now enabled by default (Vlad Zahorodnii, Plasma 6.1. Link)
The new Printers page in System Settings now does a better job of helping you figure out what to do next when it finds a driverless network printer that doesn’t have the right drivers installed (yes, that sounds like a contradiction, but such is life) (Mike Noe, Plasma 6.1. Link)
Panel widgets’ popups now close when you click on an empty area of the Task Manager (David Edmundson, Plasma 6.1. Link)
By default, XWayland apps are now allowed to listen for non-alphanumeric keypresses, and shortcuts using modifier keys. This lets any global shortcut features they may have work with no user intervention required, while still not allowing arbitrary listening for alphanumeric keypresses which could potentially be used maliciously (me: Nate Graham, Plasma 6.1. Link)
Bluetooth connection failures are now additionally mentioned in the widget pop-up itself, right next to the thing you clicked on to try the connection which is where your eyeballs were probably still looking (Patrik Fábián, Plasma 6.1. Link)
The width of the clipboard history popup that appears when you press Meta+V
now has a width that’s capped at a lower, more sane level when you’re using an ultrawide screen (Dominique Hummel, Plasma 6.1. Link)
Gwenview no longer crashes when opening certain FITS image files (Albert Astals Cid, Gwenview 24.02.1. Link)
Minimizing a Dolphin window no longer causes all of its panels to get hidden (Nicolas Fella, Dolphin 24.02.1. Link)
Fixed a glitch with multi-line text selection in Okular (Okular 24.02.1. Link)
While dragging a file in Dolphin, if it happens to pass over other files and linger there for a bit, the other files no longer get immediately opened (Akseli Lahtinen, Dolphin 24.05. Link)
Plasma no longer crashes when you open Kickoff or Kicker while uninstalling an app that’s in the Favorites list (Marco Martin, Plasma 6.0.1. Link)
Launching/activating items with the Enter key in the Kicker Application Menu once again works (Marco Martin, Plasma 6.0.1. Link)
“Get [app name]” search results from KRunner once again work (Nicolas Fella, Plasma 6.0.1. Link)
Fixed a regression with System Tray icon support that caused some apps’ tray icons to show the wrong icon (Nicolas Fella, Plasma 6.0.1. Link)
When you drag multiple files from Dolphin onto the desktop, they no longer stack on top of one another until Plasma is restarted (Marco Martin, Plasma 6.0.1. Link)
Discover no longer crashes when you search for various fairly common terms, including “libreoffice” (Aleix Pol Gonzalez, Plasma 6.0.2. Link)
Fixed the “Move to Desktop > All Desktops” titlebar menu item on X11 (Nicolas Fella, Plasma 6.0.2. Link)
Fixed a case where Plasma could exit (not crash) with a Wayland protocol error after turning screens off and back on again (Vlad Zahorodnii, Plasma 6.0.2. Link)
Fixed a case where KWin could crash when a window was opened on a secondary screen plugged into a secondary GPU (Xaver Hugl, Plasma 6.0.2. Link)
Our previous fix for VLC and MPV not being able to go full screen turned out not to be enough, so we beefed it up, and now it should actually always work (Łukasz Patron, Plasma 6.0.2. Link 1 and link 2)
Fixed a bug that could cause Night Color to not work on systems with certain graphics hardware (Xaver Hugl, Plasma 6.0.2. Link)
The first search result in the Kicker Application Menu is no longer sometimes covered up by the search field (Marco Martin, Plasma 6.0.2. Link)
When you drag a window off the left side of the screen on X11, the cursor no longer moves unexpectedly (Yifan Zhu, Plasma 6.0.2. Link)
Setting your system language to “C” on System Settings’ Region & Language page no longer mangles the text of the previews for individual formats (Han Young, Plasma 6.0.2. Link)
Fixed a case where Discover could crash on launch when its Flatpak backend is active (David Redondo, Plasma 6.1. Link)
When you have a Panel at the top of the screen, showing its config dialog no longer overlaps the global Edit Mode Toolbar; instead, the toolbar jumps down to the bottom of the screen where there’s plenty of space for it (Niccolò Venerandi, Plasma 6.1. Link)
Downloading items in the “Get New [thing]” dialogs that only have a single file available once again works (Akseli Lahtinen, Frameworks 6.1. Link)
Various actions throughout KDE apps that open the default terminal app–such as Dolphin’s “Open Terminal Here” menu item–once again work (Nicolas Fella, Frameworks 6.1. Link)
“Horizontal bars” graphs in various System Monitor widgets now use the right colors (Arjen Hiemstra, Frameworks 6.1. Link)
Menu items in context menus for text fields in QtQuick-based apps are now translated (Evgeny Chesnokov, Frameworks 6.1. Link)
Made a bunch of places icons in the Breeze icon theme respect the accent color, just like their compatriots (Someone going by the pseudonym “leia uwu”, Frameworks 6.1. Link)
Other bug information of note:
Fixed a source of lag and frame drops on some systems with certain graphics hardware (Xaver Hugl, Plasma 6.0.1. Link)
Wrote a tutorial for how to set up automatic publishing of your KDE app to KDE’s F-Droid repository (Ingo Klöcker, Link)
Updated the tutorial for how to write a System Settings page (KCM) to reflect modernity (Akseli Lahtinen, Link)
Added an autotest ensuring that a special feature of KConfig and desktops files works (David Faure, Link)
This blog only covers the tip of the iceberg! If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.
Please help with bug triage! The Bugzilla volumes are extraordinary right now and we are overwhelmed. I’ll be doing another blog post on this tomorrow; for now, if you’re interested, read this.
Otherwise, visit https://community.kde.org/Get_Involved to discover other ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!
As a final reminder, 99.9% of KDE runs on labor that KDE e.V. didn’t pay for. If you’d like to help change that, consider donating today!