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

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

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.

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

Changes in release 0.8.6

• 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.

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.

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.

Wayland has a unique way to let clients specify the contents of the cursor. After receiving a wl_pointer.enter event, the client must call wl_pointer.set_cursor request

    <request name="set_cursor">
      <arg name="serial" type="uint" summary="serial number of the enter event"/>
      <arg name="surface" type="object" interface="wl_surface" allow-null="true"
	   summary="pointer surface"/>
      <arg name="hotspot_x" type="int" summary="surface-local x coordinate"/>
      <arg name="hotspot_y" type="int" summary="surface-local y coordinate"/>
    </request>

The wl_pointer.set_cursor request takes an optional wl_surface object that represents the actual contents of the cursor. That’s it, the wl_surface interface is used both by windows and cursors! It opens a whole lot of features that you could use with the cursor, for example use the wp_viewport protocol for fractional scaling or create cursor surface trees using the wl_subcompositor interface. On the other hand, many compositors view the cursor as a simple image. So, let’s see how we improved kwin in this regard.

Cursor source

Currently (as of 5.26.x), kwin assumes that the cursor can show only a QImage. It’s okay for simple cases, but it falls apart once we need to show a wl_surface, e.g. we will hit problems with getting a QImage from a linux dmabuf client buffer.

So the first thing that we need to do in order to move anywhere forward is to choose proper abstractions to represent what is actually in the cursor. For example, if the cursor hovers a window, it obviously needs to present what the corresponding wl_surface contains. But sometimes the mouse cursor is not above any window, for example if the pointer is above a server-side decoration. Server-side decoration can be considered part of the window, but we cannot use client’s wl_surface anymore, the compositor may choose to show a different cursor, which is a QImage.

class KWIN_EXPORT CursorSource : public QObject
{
    Q_OBJECT

public:
    explicit CursorSource(QObject *parent = nullptr);

    QImage image() const;
    QSize size() const;
    QPoint hotspot() const;

Q_SIGNALS:
    void changed();
};

The CursorSource class is the base class for all other “source” classes that can be attached to the cursor. It contains generic properties, e.g. the hotspot, and it also contains the CursorSource::changed() signal to tell the world when the image has changed. CursorSource::image() exists for compatibility and to make the transition to new abstractions easier.

Sometimes, we need to show a static image in the cursor, so let’s add an ImageCursorSource to serve that purpose

class ImageCursorSource : public CursorSource
{
public:
    explicit ImageCursorSource(QObject *parent = nullptr);

public Q_SLOTS:
    void update(const QImage &image, const QPoint &hotspot);
};

On the other hand, some cursors are not static. For example, the loading cursor usually contains some animation, e.g. spinning wheel

class ShapeCursorSource : public CursorSource
{
public:
    explicit ShapeCursorSource(QObject *parent = nullptr);

    QByteArray shape() const;
    void setShape(const QByteArray &shape);
    void setShape(Qt::CursorShape shape);

    KXcursorTheme theme() const;
    void setTheme(const KXcursorTheme &theme);

private:
    void refresh();
    void selectNextSprite();
    void selectSprite(int index);

    KXcursorTheme m_theme;
    QByteArray m_shape;
    QVector<KXcursorSprite> m_sprites;
    QTimer m_delayTimer;
    int m_currentSprite = -1;
};

The ShapeCursorSource class represents a cursor shape from an Xcursor theme. It can be used to show both animated and static cursors. If the given cursor shape is animated, i.e. it has more than one sprite, ShapeCursorSource will start a timer with the timeout as indicated by the cursor theme. When the timer expires, ShapeCursorSource will switch to the next sprite and emit the CursorSource::changed() signal. If it’s the last sprite, it will wrap around to the first sprite.

And last but not least, we need something to represent wl_surface attached to the cursor

class SurfaceCursorSource : public CursorSource
{
public:
    explicit SurfaceCursorSource(QObject *parent = nullptr);

    KWaylandServer::SurfaceInterface *surface() const;

public Q_SLOTS:
    void update(KWaylandServer::SurfaceInterface *surface, const QPoint &hotspot);
};

ImageCursorSource, ShapeCursorSource, and SurfaceCursorSource are the main types that indicate what the cursor shows.

Scene

The CursorSource classes act as data sources, they don’t actually paint anything on the screen. It’s the responsibility of the scene. I’ve already written a little bit about the scene abstraction in kwin, I recommend you to read my earlier blog post about it https://blog.vladzahorodnii.com/2021/04/12/scene-items-in-kwin/

But as a quick recap: kwin breaks up a window in smaller building blocks called items. The DecorationItem corresponds to the server-side decoration if there’s one. The ShadowItem is a server-side drop shadow, for example a drop shadow cast by the decoration or the panel. The SurfaceItem represents the actual window contents. That’s the same strategy that we will follow here. The cursor will be broken in smaller pieces.

If we look closely at our cursor sources, the painting code should handle only two cases – paint a QImage and paint an arbitrary wl_surface tree. The wl_surface case is already taken care by SurfaceItem \o/, so we just need a new type of item to present an image in the scene graph, e.g. ImageItem

The CursorItem type ties both cases together. It monitors what source is attached to the cursor and creates either a SurfaceItem or an ImageItem according to the type of the cursor source

• If a SurfaceCursorSource is attached to the cursor, the CursorItem is going to destroy its child ImageItem (if there’s one) and create a SurfaceItem tree
• If an ImageCursorSource or a ShapeCursorSource is attached to the cursor, the CursorItem is going to destroy its child SurfaceItem (if there’s one) and create an ImageItem child item

Note that SurfaceItems are rendered the same way regardless of their role.

With all of this, kwin can easily handle simple cases such as displaying an image in the cursor and more esoteric things that you can do with a wl_surface.

Cursor layer

The last thing that’s needed to make cursor handling perfect is putting the cursor on its own hardware plane. Imagine that you move the mouse cursor. Ideally, you should not repaint any windows below the cursor, only update the position of the cursor. Unless the windows need to repaint their content because of new pointer position, e.g. add or remove button outlines, etc. It can be achieved by painting the cursor in its own plane.

KWin already attempts to put the cursor on hardware planes, but we would like to clean things up and unify cursor and overlay planes. It is still work in progress. TBA.

Summary

The new cursor design is more powerful and should make it easier to add new fancy features. For example, it would be amazing if you could wire the velocity of the cursor to its scale so you could shake the pointer in order to find the cursor more easily. The new design also fixes longstanding limitations that prevented kwin from displaying cursors rendered by OpenGL or Vulkan.

Happy new year! To get a good start in this new new year, I’m happy to announce that Tokodon 23.01.0 is out! This is a new major release for Tokodon and while it’s been only 2 weeks since the last major release, this release is packed with new features and improvements.

Tokodon is a Mastodon/Pleroma/Nextcloud Social client built with Kirigami that I started back in spring 2021. Tokodon has a great integration with KDE Plasma and Plasma Mobile, but it also work on other desktop environments and even Windows and macOS.

Get it!

You can download Tokodon 23.01.0 from Flathub and from the F-Droid using the KDE repo. Currently we don’t offer binaries for Windows and macOS but if you want to help with that, please get in touch. build

New timeline design

The first thing you will notice, when trying out this new version, is the new layout of the timelines.

I updated it to follow more closely the design of Mastodon web-UI and I also spent some time adjusting the spacing and typographie to be more consistent.

Search

It is now possible to search for posts, accounts and tags directly from within Tokodon.

Hashtag Handling

Tokodon now handles hashtags better. Previously, when clicking on a hashtag, Tokodon would redirect you to the website where you could see the posts that included the selected hashtag. Now you don’t need to leave Tokodon anymore, and the posts are displayed inside the app like any other timeline.

Conversation View

Tokodon now includes a basic conversation view. This shows the list of your last direct conversations. This makes it possible to see your conversation in a much nicer way than with the latest mentions view.

I plan to improve this feature further in the future, as I will be adding support for conversation markers and maybe offer a real chat-like view for conversations (which I will shamelessly steal from NeoChat).

Poll Support

It’s now possible to view and interact with polls. This supports both multiple choice and single choice polls, but creating new polls is still not possible.

Account Editor

I also added an account editor. The merge request was actually 10 months old and I started it during a stream at the last FOSDEM. As you might imagine, it was not that fun to rebase. But it is finally possible to edit your account metadata and preferences directly from Tokodon.

I also submitted a pull request in Mastodon itself to expose more settings in the API.

Real-Time Timeline Update

Tokodon was already handling some real-time events coming from the server, but until now this only included notifications. Now Tokodon will also handle new incoming messages and add them to the timeline. It will also delete messages as soon as the server asks for them to be deleted.

Technical Details

Aside from the many new features, there was several large re-factorings of the code base to cleanup some code that younger-me wrote. The C++ code base now has a coverage of 35%, and I am pretty happy with this increase from 12% of the previous release.

Coming next, I want to focus more on the post editor. The back-end also needs to be cleaned up and several important features are still missing (choosing the language, posting polls and adding alternative textual descriptions to images). I already created a branch for that and you can follow the work on this merge request.

Get Involved

If you are interested in helping, don’t hesitate to reach out in the Tokodon matrix channel (#tokodon:kde.org) and I would be happy to guide you.

I’m also regularly posting about my progress on Tokodon (and other KDE apps) on my Mastodon account, so don’t hesitate to follow me ;)

And in case, you missed it, as a member of the fundraising working group, I need to remind you that KDE is currently running an end of the year campaign. Don’t hesitate to donate!

Packager section

You can find the package on download.kde.org and it has been signed with my GPG key.

Kraft, which was released as version 1.0 after long time of active development, is targetted to the Linux desktop. My firm conviction is that the Linux desktop is very suitable for the target group of Kraft: In the small office of craftsmen for example, a Linux desktop is a great work horse which is stable, very well adoptable and has a great amount of applications that are stable and maintained.

These are only the most obvious points why Kraft is so far only available for Linux.

But often enough switching to Linux is another hurdle that users have to go, coming from a more mainstream world. So it is great to learn that Kraft, as many UI applications, can be run unter the Windows Subsystem for Linux (WSL) on Windows systems quite flawlessly.

It was tried with Windows 11 Home and the Kraft AppImage of 1.0.

The steps to run Kraft in WSL:

• Make WSL running on the Windows installation
• Install a X-server on the Windows machine
• Create a Debian or Ubuntu Linux subsystem
• Install a few extra packages into the Linux installation
• Download and run the Kraft AppImage 1.0

A more detailed howto and discussion can be found in the easy cash & tax forum. Thanks Thomas for bringing up the topic and providing the Howto!

Dear digiKam fans and users,

A new year means new goals, and this one is a challenge: migrating the old digiKam documentation based on DocBook format to a new architecture, more simple and easy to maintain. After 20 years, we left the DocBook manual for the modern Sphinx/ReStructuredText framework. This one is really a pleasure to use by documentation writers.

The content is published in a dedicated web site, internationalized by the KDE translation teams. An EPUB version is also available for the off-line use cases.

Two month ago, in October 2022, KDE's GitLab made me use a two-factor authentication (2FA). Without a second factor, I was no longer able to push code, comment on merge requests, or contribute anything meaningful on KDE Invent.

For a long time, I have known I should use two-factor authentication for my important accounts; especially for those accounts used to commit code other people are executing because they trust me. But I was too lazy to have everything prepared to use the second factor.

Thanks to Ben and the KDE infrastructure team, there were no more excuses and I had to set up a secure login.

Secure login, but don't lock yourself out 

Having a second factor, it is important that I am not locked out, if my second factor is left at home or broken. Here is what I did:

1. The first step is to choose the second factor. I decided against dedicated hardware like a Yubi key. I am familiar with one-time passwords on my mobile phone, thus, I decided to use Time-based one-time password (TOTP). This means a device or mobile app knows a secret to calculate a six-digit one-time password. The password is only valid for a couple of seconds, then a new one can be generated locally. I use Google Authenticator, but there are alternatives from less controversial vendors. Just scan the QR code and verify the secret by once entering a one-time code.
2. I installed Keepass to store the recovery codes in case my TOTP device is broken or stolen. As a side effect, I can now use more complex passwords for less frequently used passwords.
3. I made a backup including the Keepass database.
   
4. As a side-effect, I need to use tokens for checkouts and pushes. A great opportunity to have this aspect of secure development activated, too.
   

Remaining open questions

Some questions remain open for me. Time will tell, how much they bug me and where I need to adjust.

Currently, I only have my personal phone as a TOTP device. Maybe I want to add more phones or my iPad. I am also unsure whether I should install and use a TOTP software on my desktop like KDE Keysmith. It is a weighting of comfort, security, and reliability.

By-product: More security everywhere

Now that I have everything prepared on my side to use TOTP as my two-factor authentication, it was easy to use it for all the other accounts that deserve some extra protection: GitLab.com, GitHub, and independent GitLab instances hosted by FOSS projects similar to KDE Invent. Even my Google account is now protected by a TOTP mechanism and I no longer get text messages to my mobile phone. Further, I stored ten security codes from Google, just in case.

Having a security spree, I also wanted to use TOTP for my banking accounts. Unfortunately, my banks insist on the use of their own app. I think they could benefit from using open and established standards, but they decided to force us costumers to install and use their apps.