Introduction

Whatever takes time takes for good. Yeah, so, about on March I created a PR on snapcraft by canonical. It was about adopting more metadata from the parsed appstrean metadata file. The new fields that were made to parse were

1. License
2. Contact
3. Issues
4. Source Code (VCS Browser)
5. Website
6. Donation Link

What does this change means?

For publishers/snapcrafters

Publishers and snapcrafters who also maintains an appstrean metadata for their app, you don’t need to maintain the metadata in your snap package separately. Just add the metadata file in your snap and you’re good to go. (Also please keep in mind to enable the update metadata from snapcraft option in case you disabled it).

Today, we bring you a new report on the Maui Project’s progress after our previous 3.1.0 release, and the last one based on Qt5 – Here you will find detailed information on the new features, bug fixes, and improvements that have been made to the set of apps, frameworks, and shell environment.

To follow the Maui Project’s development or say hi, you can join us on Telegram @mauiproject.

We are present on X and Mastodon:

• https://x.com/maui_project
• https://floss.social/@mauiproject

Maui4 Apps

The complete set of Maui Applications has been fully ported to Qt6. In the migration process, some features have been disabled or removed; and after finalizing the initial porting, the work efforts are now placed on fixing typos, and new bugs introduced, making sure all the features are working correctly. More detailed information about that will be covered and listed below.

The previous stable release – 3.1.0 – is the last one based on Qt5 and MauiKit3. Although a new stable release was scheduled by this time, instead of a new stable version we present to you a beta release of the MauiKit4 Apps and Frameworks, fully based on Qt6 and KF6. A stable release is planned to be out for August 2024.

The ported versions of all the apps can be found in the qt6 branches, and testing packages will be published as they become available.

Porting & Pending

Even though all of the Maui Apps have now been ported there is still pending work to review that all the features are working correctly and there are no regressions introduced.

List of notable changes:

• Vvave lost support for streaming remote files stored in NextCloud and gained mini-mode support.
• Index application has been fully ported, Pix, Buho, Nota, Station, and all the other apps.
• Arca has been ported, and the archive manager has been moved into a framework to be shared, for example, in Index and Shelf.
• Shelf is missing Comic book support coming from MauiKit-Documents, which is being refactored.

Another area of work is on the newest set of apps, aiming to reach parity of features with the older ones.

Note! The MauiKit4 apps have not yet been tested under Android, thus there is not yet a testing APK build. APK testing packages will be published on the Maui Telegram channel once they start becoming available.

https://x.com/cmhiguita/status/1785465786930184697

MauiKit4 Frameworks

Porting & Documentation

The porting of the frameworks has been finalized. All the frameworks are now only Qt6 compatible – thus Qt5 support has been dropped, and the last stable Qt5 version will remain at 3.1.0.

The only pending framework for completing the documentation is MauiKit-Documents, and the newly introduced MauiKit-Archiver.

The following is a list of fixes and new features introduced:

• Fixes to the Documents framework for opening locked PDF documents, and initial support for searching text
• MauiKit4 fine-tuning all the controls implementation and fixing small bugs all around.

Pending

• TextEditor is pending to be ported to a more powerful text rendering/layout engine
• Documents comic book support is to be refactored to solve Android crashing issues on multithreading
• Three new frameworks are still pending for a stable release MauiKit-SDK, MauiKit-Git, and MauiKit-Archiver. Arca, the archive file manager, is now to be ported to be using MauiKit-Archiver, and Index as well.

Maui Shell

Maui Shell and its accompanying projects have long been ported over to Qt6, such as CaskServer, Maui-Settings. However, in the porting, a lot of small details broke and need some love and fixing, which takes us to the roadmap plans of making the first stable release before this year ends. So around November, the first stable release should be out.

And that’s all for this report.

New release schedule

The post Maui Report 23 appeared first on MauiKit — #UIFramework.

Hello everyone in KDE community!

My name is Chengkun Chen. This year I’ll be responsible for improving subtitle support in Kdenlive and I’m excited to work with all of you. :)

About project

The subtitle support in Kdenlive is limited due to its current storage method: subtitles are stored in SRT format files, which are human-readable but lack flexibility. The ASS format is a better choice to enhance Kdenlive’s creative capabilities. This project will focus on migrating Kdenlive from a subtitle storage system centered around the SRT format to one centered around the ASS format. The expected result is more diverse and rich subtitle effects, such as karaoke, along with a more powerful subtitle editor.

About me

I am a second-year undergraduate student in China, majoring Software Enginneering. My goal is to write code that people around the world can freely use, making life more convenient. Additionally, I am a producer and video creator, and I have been using Kdenlive for about two to three years. This is my first time paticipating in an open-source project and I feel very fortunate to have been selected. I’m looking forward to gaining new experiences from improving Kdenlive with the great Kdenlive team.

Thanks for your reading. Stay tuned for updates on my progress via my blog and feel free to connect with me.

Some time ago I quickly wrote a little utility to render XRechnung documents on the free desktop, called XRView. This is the initial Bogpost. It was a very fundamental Qt Widget app that shows e-invoice docs that come in the XRechnung XML format, in a human readable view.

It was never properly released, so recently I decided to wrap it up and finally cut a first release which people can find on the release page on Codeberg.

Technically it uses the XSLT stylesheets provided by Kosit and calls an external java process on the local machine to run that through a specific Saxon processor. For that, XRView requires a java runtime installed.

Since the setup of these dependencies is a bit cumbersome, the new release 1.0 does that for users. It downloads the stylesheets and also the saxon processor runtime from their upstream repositories and stores them on the local machine for future use. Of course it is strongly recommended to double check the downloaded resources for their validity and integrity and not to run software that some other code downloaded.

More new features in this first release are:

• internationalization, first available language is German
• a rudimentary application menu with about dialog and such
• the setup routine as described above

Note that this is the first release of the software. Yet, I think it is useful, and a interesting starting point for further activities in this area. As XRechnung will become a mandatory standard for all companies in Germany (at least) I think it is very important to have a free software alternative. There are already many commercial offerings.

However, I am not feeling to develop and maintain this as an “one man show” forever. Being kind of frustrated about the way how free software is often consumed nowadays, I will happily continue to contribute to it if there is more interest than “gimme for free” by other people or organizations.

Let’s see if this is heading somewhere :-)

Plasma Wayland Protocls 1.13.0 is now available for packaging.

This adds features needed for the Plasma 6.1 beta.

URL: https://download.kde.org/stable/plasma-wayland-protocols/
SHA256: dd477e352f5ff6e6ac686286c4b22b19bf5a4921b85ee5a7da02bb7aa115d57e
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell jr@jriddell.org

Full changelog:

• plasma-window-management: add a stacking order object
• output device, output management: add brightness setting
• outputdevice,outputconfiguration: add a way to use the EDID-provided color profile
• Enforce passing tests
• output device, management: change the descriptions for sdr gamut wideness

In Plasma, when the user wants to do some significant layout change in the desktop, such as adding, moving or removing panels or add and manage desktop widgets, will go in the so called “edit mode”, by a context menu entry when driven by mouse, or by long-press in the desktop when driven by touchscreen.

Let me introduce you the improved edit mode workflow Plasma 6.1 will have:

An “edit mode” is necessary because since is an operation potentially destructive, we really want to avoid the user to for instance remove their own taskbar or some similar operation by mistake, during day to day use.

“Modes” in UI are a delicate thing: they have advantage as well many possible problems, which come in when it’s not immediately clear in which mode the user is in, and can try to use the UI as it was “in the other mode” (see https://www.nngroup.com/articles/modes/ as a quick introduction on advantages and disadvantages of modes).

This was a bit of a problem of the edit mode in plasma, as the edit mode was not clearly visually separated with the normal UI workflow of the day to day plasma usage.

Another problem present was that the action buttons of the edit mode toolbar were often hidden away by either the panel configuration window or the add widgets sidebar.

This new mode zooms out the desktop with the same visual effect of the window overview effect (yay for consistency), to well differentiate between normal and edit mode. Using the same zoom effect it puts the whole desktop “out of the way” when either the add widget sidebar of the panel configuration window appear, making sure the whole desktop area is always reachable, applets can be dropped anywhere in the desktop and the edit mode toolbar is always completely accessible.

Sorry to annoy you, I would prefer not to deal with politics either, but considering that Mastodon recently lost its status as a nonprofit organisation in Germany without an explanation we cannot ignore that there very much is a direct impact of politics on what we do.

As someone who is collaborating with an international group of nice and smart people every day, it might not come as a surprise that I am opposed to all those parties that keep blaming migration and foreigners for every political failure. Let us try to support the innocent people who are being attacked by terrorist groups or nations. Way too many parties are hostile towards people who try to have a happy, honest life while ignoring or understating the importance of fair taxation and reducing greenhouse gas emissions.

You might say: “But all the parties are corrupt!” – Well, true. In every group there is a share of psychopaths. We even have some in KDE! (Surprisingly few though!) This should not deter you from contributing. Please be the change you want to see in the world and vote for the party that sucks the least! Or don't, it's your life and I am not your mom. Thanks for reading. :^)

A few weeks ago (Time flies!) I attended the KDE Goals Sprint in Berlin. I didn't have concrete plans, but I intended to look into accessibility. Quite some time ago I had improved the accessibility of Kleopatra and at Akademy 2023 in Thessaloniki I gave a talk about it. Back then I had taken the easy route fixing everything directly in Kleopatra and working around several issues in Qt instead of fixing the issues in Qt itself so that all apps could profit. Time to do something about it.

(In-)Accessible icon-only buttons

A common problem for accessibility is icon-only buttons. If a button doesn't have text then screen readers can only tell their user that there's a button. That's not very helpful. Sometimes the developers have at least assigned a tool tip to the button. This can be read out by the screen readers (Qt provides the tool tip as accessible description of the button.), but it's often too verbose. To make a button without text accessible the developer has to set the accessible name property of the widget or, in case of a Qt Quick app, the name property of the Accessible QML Type. Unfortunately, that's often forgotten if the UI isn't designed with accessibility in mind.

At the sprint I discussed several ideas with other participants to help developers remember to set the accessible name:

• A helper class to instantiate in your app which inspects the app's windows and prints a report at the end with all inaccessible icon-only buttons it has found. A bit like Qt's QAbstractItemModelTester or the different compiler sanitizers. I implemented a prototype of such a class, but didn't pursue this further. The downside of this approach is that the developer needs to open each window of the app to find all inaccessible buttons. If they are already aware of the problem then it's probably easier to search the code.
• Instead of using a helper class to inspect the widget tree from the inside one could inspect the accessibility tree of the app from the outside. This could be built into our Appium-driven UI test framework so that developers don't have to do anything special. Except that they need to write UI tests that open each and every window of their app. I think it's still worth to look into this.
• Last but not least, we pondered writing a clazy test. Thinking about the many different ways a text can be set on a button (e.g. with KGuiItem::assign) we doubted that it would be feasible to write such a test.

In the end the easiest approach could be education. If the developers are aware of the problem then there's a good chance that they remember to set an accessible name the next time they add an icon-only button to their app.

Accessible date/time inputs

Volker, Carl, David, Harald and me discussed and explored some ideas to make the date and time inputs in Qt Quick apps like Itinerary accessible. In Kleopatra I resorted to allow the user to enter the date in a simple text input instead of trying to make the complex UI of KDE's date picker accessible. Read Volker's blog and David's blog to find out which solutions they found for Qt Quick apps.

A small automation interlude

One advantage of sitting with other people in the same room is that you may overhear them talking about a mistake (e.g. a faulty commit) and you know exactly how to prevent this kind of mistake in the future. In this case the problem was a missing quote character in some YAML file. And the preventive measure was adding a YAML linter CI job. While I was at it I removed some unnecessary code from the CI job and added the job to a second repository.

List views with underlying multi-column model

In several widgets that show or use a simple list of items Qt allows using a model with multiple columns, e.g. QListView, QComboBox, QCompleter. In general this works well except that Qt has a long-standing bug: When navigating through the list screen readers read the entries of the underlying model column by column instead of reading only the entries in the selected model column (QTBUG-33786). In Kleopatra I worked around this bug with a proxy model which pretended that the model only had one column.

During the sprint I finally sat down and prepared a fix for Qt. For better readability I split my changes in five separate commits which resulted in five separate patches for Qt: 556857, 556858, 556859, 556860, 556861. Being used to multi-commit MRs in GitLab I wondered if I had done something wrong when I submitted my changes, but apparently that's Gerrit's way of handling patch reviews. The first two commits are code clean-ups, the third commit changes one aspect of the accessibility test for list views, the fourth commit is the actual fix, and the fifth commit adds a few more unit tests I find useful. The first three commits have been merged, but the actual fix is still waiting for a review.

After that I looked into the problem that QListView emitted an accessibility focus event when the current item changed even if the list view didn't have focus. I found out that this had been fixed recently by a fellow Qt contributor who ran into the same problem independently of me. This meant that I could remove the workaround in Kleopatra for new enough Qt.

Thanks to MBition for hosting us and to Aleix for making sure we don't starve. And many thanks to those donating to KDE which makes these sprints possible.