We're happy to announce the new release 5.12.0 of KPhotoAlbum, the KDE photo management program!
20 years KPhotoAlbum
This is some kind of "special" release, as exactly 20 years ago, on 2003-11-27, version 1.0 was tagged (we tagged this release already on saturday, so that it will hit the mirrors and we can publish this release announcement at this very date though ;-).
20 years is quite a long time for such a "small" FLOSS project. Enough times, nice programs die from bit rot, because the only dev or too many of the few lose interest in it, don't need it anymore and/or nobody wants to take over maintainership. Happily, this is not the case for KPA! After all these years, the project is still alive and kicking, and – when the family, the job and everything else allow it (after all, we're all not fulltime KPA devs), we work on it to make it better.
Just speaking of me, I joined the project back in 2014, almost ten years ago now (which is arguably also quite a long period of time). And I'm really proud to still be a part of this great project :-)
So, I think it's time to especially thank Jesper Pedersen for initiating the project back then, and Johannes Zarl-Zierl for taking over the maintainership and being the project leader since 2019! Joyfully, Jesper never really stopped contributing to KPA and still works on it until now.
After all, we're still – without too much self-laudation – a small but excellent crew of FLOSS enthusiasts ;-)
Kudos to our new super-diligent beta tester Victor Lobo for filing 17 of those bug reports alone, always providing meaningful information about how to reproduce the issue and tirelessly testing the fixes. Thank you! As a dev, you really appreciate this! Apart from that, also big thanks to Pierre Etchemaïté and Andreas Schleth for providing equivalently excellent bug reports!
Thanks to you all for helping making KPhotoAlbum better!
New features and changes
Apart from that, there are also some new interesting features:
Support annotating images from the viewer by using letters to assign tags. Use the context menu and select "Annotate | Assign Tags" to enable. More information is available in the KPhotoAlbum handbook.
Add option to sort category page by natural order (feature #475339). Natural sort order takes the locale into account and sorts numeric values properly (e.g. sort "9" before "10").
Allow selecting a date range in the DateBar via keyboard (Use "Shift + Left|Right")
Allow closing the annotation dialog's fullscreen preview using the Escape key.
… as well as sone changes:
In the viewer window, using the letters A-Z to assign tokens now needs to be explicitly enabled. You can do this by opening the context menu and selecting "Annotate | Assign Tokens".
When KPhotoAlbum is started in demo mode and a previously saved demo database exists, the old demo database is no longer overwritten.
The ui.rc file (kphotoalbumui.rc) is now deployed as a Qt resource instead of an on-disk file.
Improved usability of "Invoke external program" menu (#474819)
No longer set the default shortcut for "Use current video frame in thumbnail view" to Ctrl+S and avoid shortcut conflict.
Restrict context menu entries for fullscreen preview of annotation dialog to a sane set of actions.
It is no longer possible to annotate images from the viewer by pressing "/" and typing tag names.
It is no longer possible to change an image through the annotation dialog's fullscreen image preview.
Thanks to everybody involved!
According to git, the following individuals pushed commits:
Yuri Chornoivan
Friedrich W. H. Kossebau
Nicholas Leggiero
Tobias Leupold
Alexander Lohnau
Scarlett Moore
Jesper K. Pedersen
Johannes Zarl-Zierl
Thanks for spending your time with coding on KPA and for contributing your work!
Have a lot of fun with the new release, and keep KPA the best photo management program out there, also for the 20 years to come :-)
We’re already in November, but I managed to do a lot of work this month which I’m really happy about.
Quickly something that’s not strictly programming: I was accepted as a member of KDE e.V. early this month, thank you all very much! I was also given moderation powers on Discuss so maybe it will stop rate limiting me when moving posts around.
I also went on a crusade of merging and triaging merge requests on Invent, which some of you might’ve seen. Notably I was able to take care one or two pages worth of open MRs, which I’m really happy about.
Without further ado, let’s begin.
Plasma
[Feature]
Merged the Game Controller KCM into Plasma, starting with a simple rewrite in QML. I’m aiming to add back the visual representation in 6.1 (which still exists in the standalone repository if you want to take a shot at it.) At least for right now the code is much better and it supports more devices than the 5.X Joystick KCM ever could.
[6.0]
[Feature]Added supports for lists. You can’t add people to lists (you must use another client to do that) but you can at least view and manage them.
[24.02]
Kiten
[Bugfix]Marked the X11 socket as fallback. This removes a warning on the Flathub page about the deprecated windowing system.
[23.08]
[Feature]Improved the look of it’s KCM. Not only does it look nice, and it’s design is more in line with other list based ones.
PlasmaTube
[Feature]Added better hover effects for video items. I did a bunch of refactoring to unify the two types (list and grid) so they work better in general (especially for keyboard-only navigation.)
[24.02]
[Feature]Added a video queue system, which is exactly what you think it is. You can queue up an entire playlist, or add videos manually like on YouTube.
[24.02]
[Feature]Added support for MPRIS, which is used by the Media Player applet, the lockscreen and KDE Connect.
[24.02]
Accessibility
[Bugfix]
Fixed our spinboxes not being read correctly by screen readers, since they were editable by default. Now the accessible descriptions and other data is passed down to the text field. Fixed in QQC2 Desktop Style (used on Plasma Desktop) and QQC2 Breeze Style (Plasma Mobile and Android.)
[6.0]
Documentation
Found lots more missing Bugzilla links in Invent, and did some more README updating!
[Feature]
Not merged yet, but I’m adding a pen calibration tool to the Tablet KCM. If you have the required equipment and can test, please help out! It’s cutting it close to the feature freeze, so this will most likely be pushed off until 6.1.
For some time now, Qt has been internally utilizing RHI (Rendering Hardware Interface), a new cross-platform technology for graphic rendering. Since Qt 6.6, this API has been semi-public, meaning that the API is mature for practical use but may still be subject to potential changes between major Qt versions.
In this blog post, we demonstrate how to to get started with RHI.
Fedora 39 has been released!
🎉 So let’s see what comes in this new release for the Fedora Silverblue, Kinoite,
Sericea and Onyx variants. This post is a summary of the “What’s new in Fedora
Silverblue, Kinoite, Sericea and Onyx?” talk I did with
Joshua Strobl for the
Fedora 39 Release Party
(see the
full slides).
What’s new?
Welcome to Fedora Onyx!
Fedora Onyx is a new variant using the Budgie desktop, with a (nearly) stock
experience. It follows up on the Fedora Budgie Spin which has been introduced
in Fedora 38.
The experience is similar to other Fedora Atomic Desktops (what’s that? see
below 🙂): ships toolbx out-of-the-box and access to Flatpaks.
We will hopefully re-brand it from “Onyx” to “Fedora Budgie Atomic” and later
aspire at having the Atomic variant be the “Fedora Budgie” and have the
“mutable” spin be re-branded.
Fedora Atomic Desktops
We have created a new
Special Interest Group (SIG)
focused on (rpm-)ostree based desktop variants of Fedora (Silverblue, Kinoite,
Sericea and Onyx). The “Fedora Atomic Desktops” name will also serve as an
umbrella to regroup all those variants under a common name.
Note that the new name is still pending approval by the Fedora Council. A
Fedora Change Request
has been opened to track that for Fedora 40.
Silverblue comes with the latest GNOME 45 release. Loupe replaces Eye of GNOME
(EOG). For now, the new Flatpaks are not
automatically installed on
updates so you will have to replace EOG by Loupe manually.
Fedora Flatpaks are now available ppc64le and included in the installer.
Kinoite stays on Plasma 5.27. Plasma 6 is coming for
Fedora 40.
A subset of KDE Apps is now available as Flatpaks from Fedora. They are built
from Fedora RPM source and build options and are also available for all
releases (not just the latest) and even other distributions due to the nature
of Flatpaks.
Thanks a lot to Yaakov Selkowitz and the Flatpak SIG for making this happen!
With the Flatpaks being available in the Fedora remote, we have removed some
apps from the base image: Okular, Gwenview, Kcalc. The Flatpaks are
not installed on updates but
you can install them from the Fedora Flatpak remote or from Flathub.
Fedora Flatpaks will be installed by Anaconda by default for new installations
in Fedora 40.
What’s new in Sericea?
No major changes this release.
rpm-ostree unified core
Ostree commits are now built via rpm-ostree unified core mode. The main
benefits are cleanups and stricter build constraints (that sometimes surface
bugs in RPMs). This is also how Fedora CoreOS is being built right now.
This change should be completely transparent to users.
This is needed to get bootupd support and a step towards moving to ostree
native container images (discussed below).
What’s next?
bootupd support
Adding bootupd support to Atomic Desktops will finally let users easily update
their bootloader on their systems
(issue#120).
We needed the commits to be built using rpm-ostree unified core mode, which is
a change that landed in Fedora 39.
We are now waiting on Anaconda installer fixes that are
in progress. This should
hopefully land in Fedora 40.
Ostree Native Containers
The idea behind Ostree Native Containers is to package ostree commits as OCI
containers. The main benefits are:
OCI containers are easier to manage, deploy and mirror than ostree repos
It makes it possible to create derived images via a Containerfile/Dockerfile
As it is a regular container, you can inspect its content, scan it for
vulnerabilities or run it like a container
Signing is made easier via support for cosign/sigstore
You can take a look at the following examples that take advantage of this
functionality:
Work is currently in progress to add support to build those images via Pungi.
Initially, they will be built alongside the current ostree commits. This is
currently planned for
Fedora 40
(the change page needs to be updated / rewritten).
We will be looking at fully transitioning to containers in a future release.
Universal Blue, Bluefin and Bazzite
Those projects build on the in-progress support for the Ostree Native
Containers format and the Fedora Atomic Desktops images. All the changes that
are included are made via Containerfiles/Dockerfiles.
They include lots of options, offer a wide choice of images, include additional
fixes, enable more platform support, UX fixes, etc.
Universal Blue is the general project,
Project Bluefin is the developer focused one and
Bazzite is focused on gaming, including
on the Steam Deck and other similar devices.
Check them out!
Support for Asahi Linux?
Help us make that happen! One notable missing part is support in Kiwi
(issue#38) to build the images.
See Fedora Asahi Remix for more details.
Where to reach us?
We are looking for contributors to help us make the Fedora Atomic Desktops the
best experience for Fedora users.
The migration of jobs from Binary Factory to KDE's GitLab continues. Last week almost all jobs that built APKs were migrated to invent.kde.org. The only remaining Android job on Binary Factory doesn't use Craft.
The Android APK jobs running on invent are the first jobs that make use of our CI Notary Services delegating tasks that require sensitive information (e.g. the keys to sign the APKs or the credentials to upload the APKs to our F-Droid repositories) to services running outside of GitLab. Currently, the apksigner service and the fdroidpublisher service are live. The configuration of the services can be found in the sysadmin/ci-utilities repository.
As before, the APKs are published in our F-Droid repositories:
Many apps have already switched from Qt 5 to Qt 6, but the Qt 6 APKs are not yet ready for public consumption. Not even as nightly builds. Therefore many "nightly" builds are many weeks old.
The migration to invent has a few implications. On Binary Factory all APKs (release and nightly) were rebuilt once a day even if nothing changed. On invent the APKs are rebuilt whenever a change is pushed to the release/23.08 branch or the master branch of a project. Another change is that on invent any KDE developer can manually trigger a new pipeline to build the APKs (e.g. if a bug in a dependency was fixed). On Binary Factory you often needed to ask someone to trigger a build for you.
Building APKs
If you want to start building APKs for your project then add the craft-android-apks.yml template for Qt 5 or the craft-android-qt6-apks.yml template for Qt 6 to the .gitlab-ci-yml of your project. Note that you must use the include:project format (example).
The jobs will build unsigned APKs. To enable signing your project (more precisely, a branch of your project) needs to be cleared for using the signing service. This is done by adding your project to the project settings of the apksigner. The master branch is cleared by default for all applications listed in the project settings, so that you only need to add two lines: The repo path on invent and the ID of your application. The key used to sign your application will best be created by us directly on the machine that does the signing.
Once you think the APKs are ready for publication you can enable publishing in our F-Droid repositories by adding your project to the project settings of the fdroidpublisher. Because some Qt 6 APKs are not yet ready for publication although their build succeeds, by default the master branch is not cleared for publishing. This means you will have to add five lines to the project settings of fdroidpublisher.
Outlook
To complete the Android jobs/services a job/service for submitting APKs to Google Play will go live soon. It's currently only used by Itinerary but, in view of our Make a Living initiative, we hope to publish more apps on Google Play to create some revenue to fund our work. Creating and publishing Android Application Bundles (AAB), the new packaging format required for new applications published on Google Play, will follow soon after.
Then we'll add signing of Windows artifacts and installers and submission to the Microsoft Store, signing and publishing of Flatpaks, and signing and publishing of builds for macOS.
Today, 12 years after the meeting where AppStream was first discussed and 11 years after I released a prototype implementation I am excited to announce AppStream 1.0!
I was not in the original AppStream meeting, since in 2011 I was extremely busy with finals preparations and ball organization in high school, but I still vividly remember sitting at school in the students’ lounge during a break and trying to catch the really choppy live stream from the meeting on my borrowed laptop (a futile exercise, I watched parts of the blurry recording later).
I was extremely passionate about getting software deployment to work better on Linux and to improve the overall user experience, and spent many hours on the PackageKit IRC channel discussing things with many amazing people like Richard Hughes, Daniel Nicoletti, Sebastian Heinlein and others.
At the time I was writing a software deployment tool called Listaller – this was before Linux containers were a thing, and building it was very tough due to technical and personal limitations (I had just learned C!). Then in university, when I intended to recreate this tool, but for real and better this time as a new project called Limba, I needed a way to provide metadata for it, and AppStream fit right in! Meanwhile, Richard Hughes was tackling the UI side of things while creating GNOME Software and needed a solution as well. So I implemented a prototype and together we pretty much reshaped the early specification from the original meeting into what would become modern AppStream.
Back then I saw AppStream as a necessary side-project for my actual project, and didn’t even consider me as the maintainer of it for quite a while (I hadn’t been at the meeting afterall). All those years ago I had no idea that ultimately I was developing AppStream not for Limba, but for a new thing that would show up later, with an even more modern design called Flatpak. I also had no idea how incredibly complex AppStream would become and how many features it would have and how much more maintenance work it would be – and also not how ubiquitous it would become.
The modern Linux desktop uses AppStream everywhere now, it is supported by all major distributions, used by Flatpak for metadata, used for firmware metadata via Richard’s fwupd/LVFS, runs on every Steam Deck, can be found in cars and possibly many places I do not know yet.
What is new in 1.0?
API breaks
The most important thing that’s new with the 1.0 release is a bunch of incompatible changes. For the shared libraries, all deprecated API elements have been removed and a bunch of other changes have been made to improve the overall API and especially make it more binding-friendly. That doesn’t mean that the API is completely new and nothing looks like before though, when possible the previous API design was kept and some changes that would have been too disruptive have not been made. Regardless of that, you will have to port your AppStream-using applications. For some larger ones I already submitted patches to build with both AppStream versions, the 0.16.x stable series as well as 1.0+.
For the XML specification, some older compatibility for XML that had no or very few users has been removed as well. This affects for example release elements that reference downloadable data without an artifact block, which has not been supported for a while. For all of these, I checked to remove only things that had close to no users and that were a significant maintenance burden. So as a rule of thumb: If your XML validated with no warnings with the 0.16.x branch of AppStream, it will still be 100% valid with the 1.0 release.
Another notable change is that the generated output of AppStream 1.0 will always be 1.0 compliant, you can not make it generate data for versions below that (this greatly reduced the maintenance cost of the project).
Developer element
For a long time, you could set the developer name using the top-level developer_name tag. With AppStream 1.0, this is changed a bit. There is now a developer tag with a name child (that can be translated unless the translate="no" attribute is set on it). This allows future extensibility, and also allows to set a machine-readable id attribute in the developer element. This permits software centers to group software by developer easier, without having to use heuristics. If we decide to extend the developer information per-app in future, this is also now possible. Do not worry though the developer_name tag is also still read, so there is no high pressure to update. The old 0.16.x stable series also has this feature backported, so it can be available everywhere. Check out the developer tag specification for more details.
Scale factor for screenshots
Screenshot images can now have a scale attribute, to indicate an (integer) scaling factor to apply. This feature was a breaking change and therefore we could not have it for the longest time, but it is now available. Please wait a bit for AppStream 1.0 to become deployed more widespread though, as using it with older AppStream versions may lead to issues in some cases. Check out the screenshots tag specification for more details.
Screenshot environments
It is now possible to indicate the environment a screenshot was recorded in (GNOME, GNOME Dark, KDE Plasma, Windows, etc.) via an environment attribute on the respective screenshot tag. This was also a breaking change, so use it carefully for now! If projects want to, they can use this feature to supply dedicated screenshots depending on the environment the application page is displayed in. Check out the screenshots tag specification for more details.
References tag
This is a feature more important for the scientific community and scientific applications. Using the references tag, you can associate the AppStream component with a DOI (Digital object identifier) or provide a link to a CFF file to provide citation information. It also allows to link to other scientific registries. Check out the references tag specification for more details.
Release tags
Releases can have tags now, just like components. This is generally not a feature that I expect to be used much, but in certain instances it can become useful with a cooperating software center, for example to tag certain releases as long-term supported versions.
Multi-platform support
Thanks to the interest and work of many volunteers, AppStream (mostly) runs on FreeBSD now, a NetBSD port exists, support for macOS was written and a Windows port is on its way! Thank you to everyone working on this
Better compatibility checks
For a long time I thought that the AppStream library should just be a thin layer above the XML and that software centers should just implement a lot of the actual logic. This has not been the case for a while, but there was still a lot of complex AppStream features that were hard for software centers to implement and where it makes sense to have one implementation that projects can just use.
The validation of component relations is one such thing. This was implemented in 0.16.x as well, but 1.0 vastly improves upon the compatibility checks, so you can now just run as_component_check_relations and retrieve a detailed list of whether the current component will run well on the system. Besides better API for software developers, the appstreamcli utility also has much improved support for relation checks, and I wrote about these changes in a previous post. Check it out!
With these changes, I hope this feature will be used much more, and beyond just drivers and firmware.
So much more!
The changelog for the 1.0 release is huge, and there are many papercuts resolved and changes made that I did not talk about here, like us using gi-docgen (instead of gtkdoc) now for nice API documentation, or the many improvements that went into better binding support, or better search, or just plain bugfixes.
Outlook
I expect the transition to 1.0 to take a bit of time. AppStream has not broken its API for many, many years (since 2016), so a bunch of places need to be touched even if the changes themselves are minor in many cases. In hindsight, I should have also released 1.0 much sooner and it should not have become such a mega-release, but that was mainly due to time constraints.
So, what’s in it for the future? Contrary to what I thought, AppStream does not really seem to be “done” and fetature complete at a point, there is always something to improve, and people come up with new usecases all the time. So, expect more of the same in future: Bugfixes, validator improvements, documentation improvements, better tools and the occasional new feature.
Seems getting laid off was pretty good for me after all. Funny how things go sometimes.
A company that works on KDE stuff (and other Linuxy things),
interviewed me for a fun job: "Wanna help us work on KDE Plasma?"
You bet I said YES!
So now I work daily 8 hours a day, 5 days a week, to improve KDE Plasma!
It's contract work, but I hope people there like me a lot to keep me around. :)
At least I am planning to be around for the long haul!
Anyway, this was my first week doing this job!
Everyone I work with is really nice and most of them I have already met during my contribution
adventures.
The job itself for now has been about helping finding and fixing bugs in KDE Plasma. I've
mostly concentrated on bugs that can appear when moving from 5 to 6, like migrating configs, etc.
There's some other stuff I'm doing as well, but they're not that visible to end user, necessarily.
Like fixing warnings.
I am also focusing on learning the stack and hopefully eventually get to work more on Flatpak related
things and Kwin related things, since those interest me. I am also hoping to help with accessibility,
like high-contrast color schemes and such. And who knows what else I will work on in future!
Also due to my experience in test automation, I have taken on the sidequest to help with that part as well.
I have been quite interested how test automation of Linux desktop apps works, and there's quite cool
stuff going on there.
In my personal KDE plans, I want to add color customization options for separators, since those can be used
in high contrast themes. But since it would be any custom color the user wants, well, they can
set it to anything. Anyhow, I will first prioritize fixing bugs and learning more.
Thank you so much for the company who took me under their wing. And thanks to my colleagues
for helping me get into this and teaching me things, even when my questions can be a bit dumb at times.. :'D
You know who you are!
Expect more posts in future about what I learn during this job! :)
The RiveQtQuickPlugin has now integrated the latest rivecpp version. We've implemented rendering support for rive text elements. We ensured seamless text rendering compatibility across both software and hardware-backed renderers. Explore our latest blog post for a demonstration video and to learn about more rendering enhancements.
redstrate
@redstrate:pyra.sh
