Skip to content

Thursday, 26 January 2023

Qt OPC UA news catch up

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

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

Wednesday, 25 January 2023

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

Tuesday, 24 January 2023

We at the @kde-sig are happy to announce we have created a COPR repository which currently contains the KDE Plasma 5.27.0 Beta (aka: 5.26.90).

We intend to use this COPR repository in the future for KDE beta releases so that those Fedora users who want to help the KDE Community can test and report bugs to the KDE developers.

Enabling this COPR repository is very simple:

sudo dnf copr enable @kdesig/kde-beta
sudo dnf update

Your system should now have the Plasma Beta:

Plasma 5.26.90!

For our users using Kinoite, you should check out this blog post by @siosm

That’s all for now.

Feel free to join us at our Matrix room!.

Friday, 20 January 2023

gcompris 3.1

Today we are releasing GCompris version 3.1.

As we noticed that version 3.0 contained a critical bug in the new "Comparator" activity, we decided to quickly ship this 3.1 maintenance release to fix the issue.

It also contains some little translation update.

You can find packages of this new version for GNU/Linux, Windows, Raspberry Pi and macOS on the download page. This update will be available soon in the Android Play store, the F-Droid repository and the Windows store.

Thank you all,
Timothée & Johnny

A pesar de un protocolo abierto y libre, y una red pública y federada, el correo electrónico se ha convertido en un oligopolio. ¿Correrán la misma suerte Mastodon y el resto del Fediverso?

Tuesday, 17 January 2023

gcompris 3.0

We are pleased to announce the release of GCompris version 3.0.

It contains 182 activities, including 8 new ones:

  • "Mouse click training" is an exercise to practice using a mouse with left and right clicks.
  • In "Create the fractions", represent decimal quantities with some pie or rectangle charts.
  • In "Find the fractions", it's the other way: write the fraction represented by the pie or rectangle chart.
  • With "Discover the International Morse code", learn how to communicate with the International Morse code.
  • In "Compare numbers", learn how to compare number values using comparison symbols.
  • "Find ten's complement" is a simple exercise to learn the concept of ten's complement.
  • In "Swap ten's complement", swap numbers of an addition to optimize it using ten's complement.
  • In "Use ten's complement", decompose an addition to optimize it using ten's complement.

We've added 2 new command line options:

  • List all the available activities (-l or --list-activities)
  • Directly start a specific activity (--launch activityName)

This version also contains several improvements and bug fixes.


On the translation side, GCompris 3.0 contains 36 languages. 25 are fully translated: (Azerbaijani, Basque, Breton, British English, Catalan, Catalan (Valencian), Chinese Traditional, Croatian, Dutch, Estonian, French, Greek, Hebrew, Hungarian, Italian, Lithuanian, Malayalam, Norwegian Nynorsk, Polish, Portuguese, Romanian, Russian, Slovenian, Spanish, Ukrainian). 11 are partially translated: (Albanian (99%), Belarusian (83%), Brazilian Portuguese (94%), Czech (82%), Finnish (94%), German (91%), Indonesian (99%), Macedonian (94%), Slovak (77%), Swedish (94%) and Turkish (71%)).

A special note about Ukrainian voices which have been added thanks to the organization "Save the Children" who funded the recording. They installed GCompris on 8000 tablets and 1000 laptops, and sent them to Digital learning Centers and other safe spaces for children in Ukraine.

Croatian voices have also been recorded by a contributor.


As usual you can find packages of this new version for GNU/Linux, Windows, Android, Raspberry Pi and macOS on the download page. This update will also be available soon in the Android Play store, the F-Droid repository and the Windows store.

For packagers of GNU/Linux distributions, note that we have a new dependency on QtCharts QML plugin, and the minimum required version of Qt5 is now 5.12. We also moved from using QtQuick.Controls 1 to QtQuick.Controls 2.

Thank you all,
Timothée & Johnny

Monday, 16 January 2023

Carl Schwan already announced it on discuss.kde.org and at @neochat@fosstodon.org.

In this blog we’ll see how it was done and how you can publish your KDE app in the Microsoft Store.

Reserving a Name and Age Rating Your App

The first step requires some manual work. In Microsoft Partner Center you need to create a new app by reserving a name and complete a first submission. How to do this has been described by Christoph Cullmann in the Windows Store Submission Guide. Don’t hesitate to reserve the name of your app even if you are not yet ready for the first submission to the Microsoft Store. Once a name is reserved nobody else can publish an app with this name.

The first submission needs to be done manually because you will have to answer the age ratings questionnaire. NeoChat was rated 18+ because it allows you to publish all kinds of offensive content on public Matrix rooms. Filling out the questionnaire was quite amusing because I did it together with the NeoChat crowd at #neochat:kde.org.

On the first submission of NeoChat I chose to restrict the visibility to Private audience until it was ready for public consumption. I created a new customer group NeoChat Beta Testers with the email address of my regular Microsoft Store account in Microsoft Partner Center and then selected this group under Private audience. This way I could test installing NeoChat with the Microsoft Store app before anybody else could see it.

Don’t spend too much time filling out things like Description, Screenshots, etc. under Store Listings because some of this information will be added automatically from the AppStream data of your app for all available translations.

Semi-automatic App Submissions

The next submissions of NeoChat were done semi-automatically via the Microsoft Submission API with the submit-to-microsoft-store.py script while writing this Python script and the underlying general Microsoft Store API Python module microstore. The script is based on a Ruby prototype (windows.rb) written by Harald Sitter.

The idea is that the script is run by a (manual) CI job that the app’s release manager can trigger if they want to publish a new version on the Microsoft Store.

To run the script locally you need the credentials for an Azure AD application associated with KDE’s Partner Center account. Anything else you need to know is documented in the script’s README.md.

Making NeoChat Publically Available

The last step of the process to get NeoChat published in the Microsoft Store was another manual submission which just changed the visibility to Private audience. This could also have been done via the Microsoft Submission API (but not with the current version of the script), but I think it’s good to have a last look at the information about the app before it is published. In particular, you may have to fill out the Notes for certification, e.g. if your app cannot be tested without a service or social media account. For NeoChat we had to provide a test account for Matrix.

Moreover, you may want to fill out some details that are currently not available in the AppStream data, e.g. a list of Product features, the Copyright and trademark info, or special screenshots of the Windows version of your app.

What’s Next

On our GitLab instance, we want to provide a full CI/CD pipeline for building and publishing our KDE apps on the Microsoft Store (and many other app stores). A few important things that require special credentials or signing certificates are still missing to complete this pipeline.

And we want to get more KDE apps into the Microsoft Store.

If you need help with getting your KDE app into the Microsoft Store, then come find me in the #kde-windows room.


Updates after publication:

  • 2023-01-31: Updated link to script after merge of the MR

Saturday, 14 January 2023

New year, new RISC-V Yocto blog post \o/ When I wrote my last post, I did really not expect my brand new VisionFive-2 board to find its way to me so soon… But well, a week ago it was suddenly there. While unpacking I shortly pondered over my made plans to prepare a Plasma Bigscreen RaspberryPi 4 demo board for this year’s FOSDEM.

Obvious conclusion: “Screw it! Let’s do the demo on the VisionFive-2!” — And there we are:

After some initial bumpy steps to boot up a first self-compiled U-boot and Kernel (If you unbox a new board, you need to do a bootloader and firmware update first! Otherwise it will not boot the latest VisionFive Kernel) it was surprisingly easy to prepare Yocto to build a core-image-minimal that really boots the whole way up.

Unfortunately after these first happy hours, the last week was full of handling the horrors of closed-source binary drivers for the GPU. Even though Imagination promised to provide an open source driver at some time, right now there is only the solution to use the closed source PVR driver. After quite a lot of trying, guessing and and comparing the boot and init sequences of the reference image to the dark screen in front of me, I came up with:

  • a new visionfive2-graphics Yocto package for the closed source driver blobs
  • a fork of Mesa that uses a very heavy patch set for the PVR driver adaptions; all patches are taken from the VisionFive 2 buildroot configurations
  • and a couple of configs for making the system start with doing an initial modeset

The result right now:

VisionFive-2 device with Plasma-Bigscreen (KWin running via Wayland), SD card image built via Yocto, KDE software via KDE’s Yocto layers, Kernel and U-Boot being the latest fork versions from StarFive

Actually, the full UI even feels much smoother than on my RPi4, which is quite cool. I am not sure where I will end in about 3 weeks with some more debugging and patching. But I am very confident that you can see a working RISC-V board with onboard GPU and running Plasma Shell, when you visit the KDE stall at FOSDEM in February 😉

For people who are interested in Yocto, here is the WIP patch set: https://github.com/riscv/meta-riscv/pull/382

Sunday, 8 January 2023

I am pleased to announce Linux-Stopmotion release 0.8.6! The last release was three years ago and this is the first release since Stopmotion became a KDE incubator project.

About Stopmotion

Stopmotion is a Free Open Source application to create stop-motion animations. It helps you capture and edit the frames of your animation and export them as a single file.

Direct capture from webcams, MiniDV cameras, and DSLR cameras. It offers onion-skinning, import images from disk, and time lapse photography. Stopmotion supports multiple scenes, frame editing, basic sound track, animation playback at different frame rates, and GIMP integration for image. Movies can be exported to a file and to Cinelerra frame lists.



Technically, it is a C++ / Qt application with optional dependencies to camera capture libraries.

Changes in release 0.8.6

This release does not contain new features but provides changes under the hood.
  • New build system using CMake. The qmake one is deprecated and will be removed.
  • The test executable can be executed as a CMake test target (make test-stopmotion && make test).
  • Fixed various warnings from Clang, GCC, and Qt 5.15.
  • We have a build pipeline executing automated builds and tests.

Future plans

  • We decided to renamed the application to KStopmotion, as Linux is trademarked.
  • Transition from Qt 5 to version 6.
  • We should integrate better to KDE's tech stack: Internationalization, using KDE libraries, update and reformat documentation.

Get involved!

If you are interested, give Stopmotion a try. Reach out to our mailing list kstopmotion@kde.org to share ideas or get involved.

You can also help to improve Stopmotion. For example, we started the transition to Qt 6 and we welcome any helping hand.

Friday, 6 January 2023

As an Linux application developer, one might not aware that there could be certain effort required to support Input Method (or Input Method Editor, usually referred as IME) under Linux.

What is input method and why should I care about it?

Even if you are not aware, you are probably already using it in daily life. For example, the virtual keyboard on your smart phone is a form of input method. You may noticed that the virtual keyboard allows you to type something, and gives you a list of words based on what you already partially typed. That is a very simple use case of input method. But for CJKV (Chinese, Japanese, Korean, Vietnamese) users, Input method is necessary for them to type their own language properly. Basically imagine this: you only have 26 English key on the keyboard, how could you type thousands of different Chinese characters by a physical keyboard with only limited keys? The answers, using a mapping that maps a sequence of key into certain characters. In order to make it easy to memorize, usually such mapping is similar to what is called Transliteration , or directly use an existing Romanization system.

For example, the most popular way for typing Chinese is Hanyu Pinyin.

In the screenshot above, user just type “d e s h i j i e”, and the input method gives a list of candidates. Modern Input method always tries to be smarter to predict the most possible word that the user wants to type. And then, user may use digit key to select the candidate either fully or partially.

What do I need to do to support Input method?

The state of art of input method on Linux are all server-client based frameworks. The client is your application, and the server is the input method server. Usually, there is also a third daemon process that works as a broker to transfer the message between the application and the input method server.

1. Which GUI toolkit to use?

Gtk & Qt

If you are using Gtk, Qt, there is a good news for you. There is usually nothing you need to do to support input method. Those Gtk toolkit provides a generic abstraction and sometimes even an extensible plugin system (Gtk/Qt case) behind to hide all the complexity for the communication between input method server and application.

The built-in widget provided by Gtk or Qt already handles everything need for input method. Unless you are implementing your own fully custom widget, you do not need to use any input method API. If you need your custom widget, which sometimes happens, you can also use the API provided by the toolkit to implement it.

Here are some pointers to the toolkit API:

Gtk: gtk_im_multicontext_new GtkIMContext

Qt: https://doc.qt.io/qt-6/qinputmethod.html https://doc.qt.io/qt-6/qinputmethodevent.html

The best documentation about how to use those API is the built-in widget implementation.

SDL & winit

If you are using SDL, or rust’s winit, which does have some sort of input method support, but lack of built-in widget (There might be third-party library based on them, which I have no knowledge of), you will need to refer to their IME API to do some manual work, or their demos.

Refer to their offical documentation and examples for the reference:

https://wiki.libsdl.org/SDL2/Tutorials-TextInput

https://github.com/libsdl-org/SDL/blob/main/test/testime.c

https://github.com/rust-windowing/winit/blob/master/examples/ime.rs

Xlib & XCB

Xlib has built-in XIM protocol support, which you may access via Xlib APIs. I found a good article about how to add input method support with Xlib at:

https://tedyin.com/posts/a-brief-intro-to-linux-input-method-framework/

As for XCB, you will need to use a third-party library. I wrote one for XCB for both server and client side XIM. If you need a demo of it, you can find one at:

https://github.com/fcitx/xcb-imdkit/blob/master/test/client_demo.c

Someone also wrote a rust binding for it, which is used by wezterm in real world project. Some demo code can be found at:

https://github.com/H-M-H/xcb-imdkit-rs/tree/master/examples

wayland-client

As for writing a native wayland application from scratch with wayland-client, then you will want to pick the client side input method protocol first. The only common well supported (GNOME, KWin, wlroots, etc, but not weston, just FYI) one is:

https://wayland.app/protocols/text-input-unstable-v3

2. How to write one with the APIs above?

If you use a toolkit with widget that can already support input method well, you can skip this and call it a day. But if you need to use low level interaction with input method, or just interested in how this works, you may continue to read. Usually it involves following steps:

  1. Create a connection to input method service.
  2. Tell input method, you want to communicate with it.
  3. Keyboard event being forwarded to input method
  4. input method decide how key event is handled.
  5. Receives input method event that carries text that you need to show, or commit to the application.
  6. Tell input method you are done with text input
  7. Close the connection when your application ends, or the relevant widget destructs.

The 1st step sometimes contains two steps, a. create connection. b. create a server side object that represent a micro focus of your application. Usually, this is referred as “Input Context”. The toolkit may hide the these complexity with their own API.

Take Xlib case as an example:

  1. Create the connection: XOpenIM
  2. Create the input context: XCreateIC
  3. Tell input method your application wants to use text input with input method: XSetICFocus
  4. Forward keyevent to input method: XFilterEvent
  5. Get committed text with XLookupString
  6. When your widget/window lost focus, XUnsetICFocus
  7. Clean up: XDestroyIC, XCloseIM.

Take wayland-client + text-input-v3 as an example

  1. Get global singleton object from registry: zwp_text_input_manager_v3
  2. Call zwp_text_input_manager_v3.get_text_input
  3. Call zwp_text_input_v3.enable
  4. Key event is forward to input method by compositor, nothing related to keyboard event need to be done on client side.
  5. Get committed text zwp_text_input_v3.commit_string
  6. Call zwp_text_input_v3.disable
  7. Destroy relevant wayland proxy object.

And always, read the example provided by the toolkit to get a better idea.

3. Some other concepts except commit the text

Support input method is not only about forwarding key event and get text from input method. There are some more interaction required between application and input method that is important to give better user experience.

Preedit

Preedit is a piece of text that is display by application that represents the composing state. See the screenshot at the beginning of this article, the “underline” text is the “preedit”. Preedit contains the text and optionally some formatting information to show some rich information.

Surrounding Text

Surrounding text is an optional information that application can provide to input method. It contains text around the cursor, where the cursor and user selection is. Input method may use those information to provide better prediction. For example, if your text box has “I love |” ( | is the cursor). With surrounding text, input method will know that there is already “I love ” in the box and may predict your next word as “you” so you don’t need to type “y-o-u” but just select from the prediciton.

Surrounding text is not supported by XIM. Also, not all application can provide valid surrounding text information, for example terminal app.

Reporting cursor position on the window

Many input method engine needs to show a popup window to display some information. In order to allow input method place the window just at the position of the cursor (blinking one), application will need to let input method know where the cursor is.

Notify the state change that happens on the application side

For example, even if user is in the middle of composing something, they may still choose to use mouse click another place in the text box, or the text content is changed programmatically by app’s own logic. When such things happens, application may need to notify that the state need a “reset”. Usually this is also called “reset” in the relevant API.