I was first introduced to Linux when my outdated computer could not run Windows anymore. I had previously heard some information about LINUX while surfing the internet, but my initial impression was that it was highly sophisticated and exclusively for programmers or mainly hackers :). I finally started using Linux Mint, and was moved by how quick and configurable it was 🤩.

After a few distro-hopps, I finally settled for KDE Neon being amazed by how easily customizable it was ❣️

Motivation for applying to sok’23

I was very much content with KDE plasma but I always found some minor annoying bugs here and there, it was also around this time I got started with programming and was looking into ways to get better at it, so I decided that I would contribute to KDE 😇, and like every other beginner, I didn’t know how to navigate through such large repositories of KDE. I also learned about the Season of KDE program, which assists in onboarding new contributors for KDE, so I decided to apply.

My Project

My project for SOK’23 is improving the accessibility of Tokodon by writing appium tests. My project involves two parts: the first one is making Tokodon work without internet connection so that it is ready for tests and then the second part is writing GUI tests to improve accessibility. You can find my full project proposal SoK Proposal for Tokodon.

Work done so far🤗

Week 1-2:

In my first week, I researched how I would run Tokodon without network connectivity. I tried to reverse engineer the existing unit-tests, and created a new start file offline-main.cpp, and by the end of the second week, I could start Tokodon without network connectivity with some broken UI.

Week 3-4:

The next step was writing appium test for the search functionality. For this, I first fixed the broken search UI by reversing the already written unit-test for search and following which I wrote my first test for testing the GUI of search. The final result is shown in the gif below:

Week 5-6:

In these weeks I, with the help of the maintainers of Tokodon, fixed the breaking pipelines of tokodon-offline and also wrote another appium test for testing different types of timeline statuses.

What I will be doing in the upcoming weeks

In the upcoming weeks I plan to add more appium tests and fix broken UI elements in tokodon-offline.

This Monday, I was in Brussels to attend a stakeholder workshop for the Digital Market Act (DMA) organized by the European Commission. For those who don’t know that is the DMA, it’s a new law that the European Parliament voted on recently and one of its goals of it is to force some interoperability between messaging services by allowing small players to able to communicate with users from the so-called Gatekeepers (e.g., WhatsApp).

I attended this meeting as a representative of KDE and NeoChat. NeoChat is a client for the Matrix protocol (a decentralized and end-to-end encrypted chat protocol). I started developing it with Tobias Fella a few years ago during the covid lockdown.

I learned about this workshop thanks to NLNet, who funded previous work on NeoChat (end-to-end encryption). They put Tobias Fella and me in contact with Jean-Luc Dorel, the program officer for NGI0 for the European Commission. I would never have imagined sitting in a conference room in Brussels, thanks to my contribution to open-source projects,

Regarding the workshop itself, this was quite enlighting for me, who is just a minor player there and only work on NeoChat and many other KDE application in my free time as a volunteer. I expected a room full of lawyers and lobbyists, which was partially true. A considerable part of the room was people who were silent during the entire workshop, representing big companies and mostly taking notes.

Fortunately, a few good folks with more technical knowledge were also in the room. With, for example, people from Element/Matrix.org, XMPP, OpenMLS, Open Source Initiative (OSI), NlNet, European Digital Rights (EDRi), and consumer protection associations.

The workshop consisted of three panels. The first was more general, and the latter two more technical.

In the first panel, the topic was the scope, the trade-offs, and the potential challenges of the Article 7 of the DMA. This panel was particularly well represented by a consumer protection organization, European Digital Rights, and a university professor, who were all in favor of the DMA and the interoperability part of it. Regarding the scope, one topic of discussion started by Simon Phipps was if gatekeepers like Meta should be forced to also interop with small self-hosted XMPP or Matrix instances or if this would only be about relatively big players. Unfortunately, I also learned that, while it was once part of the draft of the DMA, social networks are not required to interop. If Elon had bought Twitter earlier, this would have probably been part of the final text too. From this panel, I particularly appreciated the remarks of Jan Penfrat from the EDRi, who mentionned that this is not a technical or standardization problem and pointed out that some possible solutions like XMPP or Matrix already exist for a long time. There were also some questions left unanswered, like how to force gatekeepers to cooperate, as some people in the audience fear that they would make it needlessly difficult to interoperate.

After this panel, we had a short lunch, and this was the occasion for me to connect a bit with the Matrix, XMPP and NlNet folks in the room.

The second panel was more technical and was about end-to-end encryption. This panel had people from both sides of the debate. Paul Rösler, a cryptography researcher, tried to explain how end-to-end encryption works for the non-technical people in the audience, which I think was done quite well. Next, we had Eric Rescorla, the CTO of Mozilla, who also gave some additional insight into end-to-end encryption.

Cisco was also there, and they presented their relative success integrating other platforms with Webex (e.g. Teams and Slack) with for example, the possibility of creating Webex calls from Slack. This ‘interoperability’ between big players is definitively different from the direction of interoperability I want to see. But this is also a good example showing that when two big corporations want to integrate togethers, there are suddenly no technical difficulties anymore. They are also working on a new messaging standard (with reminds me a bit of xkcd 927) as part of the MIMI working group of the IETF and they already deployed that in production.

Afterward, it was the turn of Matrix, and Matthew Hodgson, the CEO/CTO at Element. Matthew showed a live demo of client-side bridging. This is their proposed solution to bridging end-to-end-encrypted messages across protocols without having to unencrypt the content inside a third-party server. This solution would be a temporary solution; ideally, services would converge to an open standard protocol like Matrix, XMPP, or something new. He pointed out that Apple was already doing that with iMessage and SMS. I found this particularly clever.

Last, Meta sent a lawyer to represent them. The lawyer was reading a piece of paper in a very blank tone. He spent the entirety of his allocated time, telling the commission that interoperability represents a very clear risk for their users who trust Meta to keep their data safe and end-to-end encrypted. He ignored Matthew’s previous demo and told us that bridging would break their encryption. He also envisioned a clear opt-in policy to interoperability so that the users are aware that this will weaken their security and express a clear need for consent popups when interacting with users of other networks. It is quite ironic coming from Meta who in the context of the GDPR and data protection, was arguing against an opt-in policy and against consent. And as someone pointed out in the audience, while Whatsapp is end-to-end-encrypted, this isn’t the case for Messengers and Instagram conversations, which are both also products of Meta. The lawyer quickly dismissed that and explained that he only represented Whatsapp here and couldn’t answer this question for other Meta products. As you might have guessed, the audience wasn’t convinced by these arguments. Still, something to note is that Meta had at least the courage to have something in front of the audience, unless other big gatekeepers like Microsoft, Apple and Google who were also in the room but didn’t participate at all in the debate.

Finally, after another small coffee break, the last panel was about abuse prevention, identity management, and discovery. With Meta in the panel again, consent was again a hot subject of discussion. Some argued that each time someone from another server joins a room, each user should consent to this new server can read their messages. This sounds very impractical to me, but I guess this goal is to make interoperability impractical. It also reminds me very much of the GDPR popup, which privacy-invading services try to optimize using dark patterns so that the users click on the “Allow” button, just that in this case, this will try to convince the user to click on the “Don’t connect with this user coming from this untrusted and scary third party server” button.

There was also some discussion about whether this was the server’s role in deciding if they allow connection from a third-party server or the user’s role. The former would mean that big providers would only allow access to their service for other big providers and block access to small self-hosted instances, and the latter would give users a choice. Another topic was the identifier, which, as someone from the audience pointed out, phone numbers used by Whatsapp, Signal and Telegram are currently not perfect as they are not unique across services and might require some standardization.

In the end, the European Commission tried to summarize all the information they got today and sounded quite happy that so many technical folks were in the room and active in the conversation.

And finally, after the last panels, I went to a bar next to the conference building with a few people from XMPP, EDRi, NlNet and OpenMLS to get beers and Belgium fries.

Since I am planning to go on vacations very soonish (actually, just idling the time until I head for the airport…), I think it is good time to wrap-up the recent changes in the KDE Yocto area.

As you might have noticed, 4 weeks ago there finally was an in-person FOSDEM again. It was great event, many interesting people were there and I had really good chats. One of the main topics for me was discussing the next steps for our Yocto efforts, in particular as Volker and Hannah were also around.

Our current state is as follows:

1. meta-kf5 is updated the the latest KF5 release, 5.103.0. We plan to update that branch further as more KF5 releases appear. But it will stick with KF5 and KF6 is packed separately (see below).
2. meta-kde also got an update, but a much bigger one than meta-kde: here, you will now find KDE Plasma 5.27.0 as well as support for Yocto Langdale and all needed backports in the Wayland area to make it work with Kirkstone. I expect this layer at some time to switch to Qt6/KF6 support and at latest once I am back, there will appear a kf6-staging branch.
3. meta-kf6 is probably the most interesting point on the list. Following the Yocto project’s approach to have one repository per layer, there now is a new meta-kf6 repository. In this repository we use branch names that follow the supported Yocto releases to make it easier for device creators to pick compatible versions.
   This meta-kf6 repository now has an initial set of Git master hashes that are known to build regarding Langdale and scripting is prepared such that we can do semi-regular updates of the hashes as long as now official KF6 releases exist. Stressing the meaning of “Git master hashes”, please do not in any way expect that to be stable The only safeguard at the moment before updating the hashes is that we check that everything is building on Yocto Langdale. Currently, the main purpose is to catch packaging regressions early and support KF6 development with build fixes for more exotic setups.

Talking about “exotic setups”, I was very glad about the interested in our Plasma Bigscreen @ RISC-V/VisionFive2 demo at FOSDEM. All the WIP changes which were needed for this demo are finally landed in the KDE Yocto layers. There is only one remaining (very big) MR pending for meta-riscv which needs to get merged. The overall state of the board image though is quite basic and a lot of things are still to do (if you know Yocto and have such a board, help is welcome ) For example, RAM size is reported incorrectly from the Kernel, the screen looks too pink, GStreamer and Kwin does not want to work yet together with the GStreamer-OMX backend from Starfive…
Recreating my setup should be fairly simple, just use this manifest file, add meta-riscv with the branch of the above mentioned MR and do “MACHINE=visionfive2 . ./setup-environment && bitbake kde-demo-image-bigscreen”.

So, 2022 was a successful year for Qt - and we highlight the Qt 6.3 and Qt 6.4 releases, Qt World Summit, and Qt Contributor Summit.

And our community members keep up with the activity by writing diligent bug reports, contributing patches, giving technical advice, or helping out other users in forums and mailing lists.

New Gamepad KCM

The Joystick KCM is pretty bad shape right now, for numerous reasons:

• What the heck is a joystick?
• What is the purpose of this KCM if I can’t even configure anything?
• Why is it telling me about device paths?
• What’s up with all of the tables?

So one of my big “Plasma 6” goals is to rewrite the KCM with a few goals in mind:

• Re-brand it around “Gamepads” and “Game Controllers” instead of “Joystick”. A lot of people have mentioned they didn’t even know it supported regular game controllers.
• Based on modern APIs and frameworks such as Solid.
• QML-based, with clear a symbolic gamepad layout which makes it easier to test a controller. No more tables of buttons!
• Remap buttons for SDL games along with the regular calibration found in the old KCM.

I’ve been collaborating with Jeremy Whiting on this project, and it’s been going through some technical turmoil but it’s making solid progress:

Next month hopefully we’ll be able to get a proper UI working, now that mapping buttons is mostly sorted.

See my merge request and Jeremy’s UI merge request.

Tokodon changes

I landed a bunch of features in Tokodon this month, including some much needed bugfixes for some rough edges of the project.

Web+ap support

[Feature] I landed support for the web+ap url scheme used to open ActivityPub objects in Tokodon! Just like matrix.to links in NeoChat, these allow linking to ActivityPub objects online. Once everything is in place, we will be one of the first clients to support it!

If you can’t wait, it’s also possible to open up regular https linked posts in Tokodon by passing it as an argument, if you want to hook it up somehow in your browser.

See the merge request and the wishlist bug.

Post language support

[Feature] You can now select the language you’re posting in! You can’t view a post’s language or filter them from within Tokodon yet, but it’s a start¹. Your preferred languages (chosen through the Languages & Formats KCM if you’re using KDE) is shown at the top of the list.

See the merge request.

Poll support

[Feature] Tokodon has supported viewing polls already, but not posting them. Now you can create polls! All of your usual options are exposed, including some not even shown on Mastodon Web. This is not merged yet, but will be soon.

See the [merge request]https://invent.kde.org/network/tokodon/-/merge_requests/152).

More Changes

• [Bugfix] A bunch of Android bugs are squashed, including links not working. I just recently got my PinePhone working again too, so expect more mobile-related work soon! :) See the merge request.
• [Feature] Soon you’ll be able to configure the network proxy on the login page. See the merge request.
• [Bugfix] Posting is much more reliable in general, and it’s clearer when an error has occurred. Hopefully no more of your toots get eaten. See the merge request.
• The README finally includes a screenshot! See the merge request.

NeoChat Notification Badge

[Bugfix] One thing that always irked me with NeoChat is the notification badge. The number never feels right, and no matter how many rooms I read it never changes:

Now the badge will actually update based on your current notification count, hurrah! See the merge request.

PulseAudio KCM

[Feature] Last month I redid the Window Decoration KCM, and this month I did the same for the PulseAudio KCM, although the changes needed where much smaller.

See the merge request.

Kirigami and QQC2 Desktop Style

[Bugfix] For Kirigami, I tried to focus on fixing up Dialog behavior to mixed results. I wanted to change the dialog closePolicy, but that’s been more complex than expected. I attempted to fix the extra horizontal scrolling bug in Dialogs², but that has unintended regressions in Discover and I’m not really happy with the solution. I also have a bunch of OverlaySheet fixes that I need to rebase³ :) So a bunch of half-baked things I should start finishing next month!

[Bugfix] I noticed an issue where Breeze Icons on Android wouldn’t work if you had a custom icon theme in your application - which I tried to fix but I’m not happy with the solution. It looks like the built-in icons index.theme is not installed properly, and I want to figure out if we can fix that first.

[Bugfix] For qqc2-desktop-style, I fixed an odd case where you could select text in TextAreas that explicitly disabled it by using the right-click context menu.

Plasma Welcome

Oliver landed the Plasma Welcome redesign for 6.0, which looks wonderful. As with all great features, this has had it’s fair share of technical issues which I had the pleasure of helping with, including fixing this bug:

Embedded KCMs create and manage their own QML engine. Objects like Kirigami.ApplicationWindow are separated though, because that exists in Plasma Welcome’s engine and not the KCMs, which breaks a lot of things including the global toolbar. I figured out that you can inject your own QML engine to KDeclarative, which will fix most of the issues. While doing this, I also simplified embedded KCMs in Plasma Welcome which will help developers creating their custom pages.

There’s one lingering issue – KDeclarative get’s a little bit too greedy with the engine we give it and will try to destroy it to due to std::shared_ptr shenanigans, but fixing it will require changes to the framework. Right now we work around the issue by not assigning a parent, but I want to look into changing that soon.

See Oliver’s merge request.

Fun with Doxygen

This month we had a strange incident where api.kde.org fails to generate a page for IconItem, but why?

Of course the first thing I tried was running kapidox locally for plasma-framework, but there’s still a doc page for IconItem generated. Huh. So I started looking into what the binary factory actually does to see if there’s some inherent issue with our system. What I ended up with is a bash script which emulates what binary factory does, but locally.

What I noticed is terrifying, the doc page doesn’t show up here! So I had an idea, what if the problem is that the name is colliding? After some quick global code searches using our LXR, I discovered that Maui recently introduced a new type called IconItem which coincidentally fits within the timeline of IconItem disappearing. How can this even happen in the first place?

I’m no expert in doxygen (is anyone?) but there is something called “tags” which is basically an index of every type that doxygen indexes. Doxygen also uses these tags to interlink doc pages together, so what’s going wrong? Well, kapidox actually runs the doc generation twice, once initially and then another time to interlink dependencies. What I theorize is that when it’s plasma-framework’s turn to generate, doxygen sees that “IconItem” is already in Maui’s tagfile and refuses to generate the page again.

With this new caveat in mind, I submitted two MRs to hopefully fix the documentation problems:

• Renaming unnamespaced classes on the doxygen side.
• Removing unnecessary qmldirs that were exposing private APIs.

… Except that I forgot about the KF5/KF6 split, which makes this harder. Next month will be focusing on rebasing those into KF5, and then creating KF6-specific MRs if needed (but a lot of fat is being cut here, so it might not be).

KDevelop.org

I took the responsibility of converting the bit-rotting kdevelop.org site to Hugo, which should be live soon! Most of the old site content is brought over (and converted to Markdown) while pages are updated where needed. The new site is now live at kdevelop.org!

See the new repository.

Updating go-kde-org

I opened an MR to update the matrix.to redirector hosted at go.kde.org which should include a link to open in NeoChat! Once it’s merged, I plan on replacing the links on the KDE Community Wiki with these instead of the WebChat links we have now.

Changing Notification History Order

This is something that’s been sitting on my backlog, but I’m super annoyed about the ordering of notification history. Whenever I miss a notification⁴ I scroll through my notification history. However, it’s ordered seemingly randomly, because it’s sorted by “type and urgency”. That’s not too helpful because neither criteria is really exposed in the UI. I propose changing it to “Date” which makes way more sense for a history view of notifications.

See the merge request.

Manjaro ARM is proud to present the packages for Plasma 5.27.0 together with the packages for Plasma Mobile Gear (soon to be regular Gear) 23.01.0 for the mobile devices.

These packages are currently being tested in our Unstable branch and will soon be transferred to Testing and then finally to Stable branch when the time comes..

This also makes our next Beta images (Beta 15) the last that will be tagged as Beta. We are preparing to include PinePhone and PinePhone Pro images into our main release cycle from either 23.04 or 23.06.

How to try

If you want to try this early, you can switch your current Manjaro system running Plasma mobile to Unstable branch and update this way:

sudo pacman-mirrors -aS unstable
sudo pacman -Syyu

Some new features

New features in this release/update includes, but are not limited to:

• New Power Off Menu
• More KCMs are mobile friendly
• Added User KCM (although it does not save changes)
• Lots of under-the-hood changes and fixes

And a couple of screenshots:

I am happy to announce Tokodon 23.02. This release contains around one month’s worth of improvements, and while it is only one month, this release is feature packed! This was an exciting month for me in general, I started working at KDAB, went to FOSDEM in Brusels where I meet a bunch of other KDE folks, and spend time enjoying my new life in Berlin.

Fortunately I still found some time to contribute to Tokodon, and Joshua Goins has also been a very active contributor. The number of contributors is also growing with a bunch of new faces: Aakarsh MJ, Harshil Jani, Mohit Marathe, Raphael Gaschiganrd, Rishi Kumar who also contributed some code in this release.

So what is Tokodon? Is is basically a client for the federated social network Mastodon. It is built with Kirigami with the goal to have a great integration with Plasma Desktop and Plasma Mobile, but it also works on other desktop environments, and even Windows and macOS.

Get it!

You can download Tokodon 23.02.0 from Flathub and from 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 on Matrix.

Post composer rewamp

As part of this release, we reworked the post composer considerably. This is the central area of your interaction with Mastodon and we wanted it to be more reliable.

It is now possible to add an alternative description to images and videos sent via Tokodon. This is very important for accessibility as images without alternative description are invisible for screen readers. (Carl Schwan, Link)

It is also now possible to see the upload progress when uploading an attachment, giving you some visual feedback that something is happening. (Carl Schwan, Link)

An error message will be displayed when sending a message didn’t work. The post composer will only be closed once the message is sent, so if there is an network error the post you wrote is not lost and you can try posting it again. This should make Tokodon much more reliable for interacting with Mastodon. (Joshua Goins, Link).

Another big thing is that we are now supporting editing posts, so in case you made a typo you don’t need to delete your post and post it again. (Joshua Goins, Link)

And finally Tokodon respects your default sensibility and visibility preferences when posting, and when replying to a message, the visibility of the message will be inherited in your reply. So if you are replying to a private message, the reply will automatically be set to be also private. (Carl Schwan, Link)

Timeline and notification view

Aside from the improvements to the post editor, we continued to polish the timeline.

The models for timelines has been completely refactored. Aside from making the code nicer to work with and a bit faster, it also made it possible to show the avatar of who boosted or liked a post. (Carl Schwan, Link)

Tokodon now doesn’t only support image as attachments, but we now also have a prelimary support for videos and gifs. (Joshua Goins, Link).

Additionally the previews for attachements should be better displayed with correct aspect ratio. (Joshua Goins, Link 1, Link 2)

Other ways to interact with a post are now available in an overflow menu for posts adding actions like a “Copy link to post” feature (Joshua Goins, Link), a bookmark feature (Joshua Goins, Link) and the previously mentioned edit feature (Joshua Goins, Link)

There are now some new special pages available in the sidebar to display your bookmarks as well as your favorite posts. (Joshua Goins, Link)

We now handle notifications for poll updates (Riya Bisht, Link), and when a post you interacted with gets updated (Harshil Jani, Link)

There are now placeholders for when you currently don’t have any notifications or conversations instead of showing you an empty view (Mohit Marathe, Link)

Search

The search field introduced during the last released got a nice visual refresh…

… And it now supports searching for hashtags. (Joshua Goins, Link)

Other Improvements

It is now possible to configure the color scheme used by Tokodon independently from the Plasma color scheme. (Joshua Goins, Link but most of the code was copied in good tradition from NeoChat)

We added the missing separators in the settings pages (Rishi Kumar, Link)

It is now possible to directly edit your account from your profile page (Joshua Goins, Link)

The user’s avatar in the profile page now uses the standard Kirigami.Avatar component (Joshua Goins, Link)

The behavior of selectable text fields is now consistent (Aakarsh MJ, Link)

Important Bugfixes

A bug that broke loading the timeline in some conditions has been fixed (Carl Schwan, Link)

We fixed rendering of some attachments caused by a bug in the blurhash decoding. (Joshua Goins, Link)

Storing the account settings is now using the account username and instance hostname as a unique identifier. This fixes situations where someone had multiple accounts with the same username on a different instance. (Raphael Gaschiganrd, Link)

Technical Details

Aside from the many new features, there were 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 36%, this is a small increase compared to the previous release. Rishi Kumar is also working on integration tests as part of his Season of KDE project.

Get Involved

If you are interested in helping, don’t hesitate to reach out in the Tokodon matrix channel (#tokodon:kde.org) and I will 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 there ;)

And in case, you missed it, as a member of the fundraising working group, I need to remind you that KDE e.V., the non-profit behind the KDE community accepts donations.

Packager section

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

After the announcement upstream, Fedora’s @kde-sig follows up by making KDE Plasma 5.27.0 available on Fedora 36 and Fedora 37.

There’s a catch though: you will have to use our COPR.

The regular update on Fedora repositories will follow shortly, I will keep you all posted.

Feel free to join us at our Matrix room!.

Glaxnimate is proud to announce the release of version 0.5.2. This latest update brings several exciting new features and improvements to enhance your animation creation experience.

Animation along Path

Earth and Moon graphics are from Noto Emoji

One of the major additions in this release is the ability to animate objects along a path. This is a feature that allows you to animate elements in a more natural and organic way by having them move along a custom path instead of a straight line. With this feature in Glaxnimate, you can create animations of objects following a curved path, like a bouncing ball or a spaceship flying through space.

After you add position keyframes to an object, the path can be adjusted with the edit tool, giving you full control over the motion of your elements, and the ability to fine-tune your animations until they look just right.

Improved User Interface

The interface layout has also been updated with new presets to provide better display on smaller screens, and the ability to set custom shortcut settings for plugins has been added.

Enhanced Input/Output Functionality

To make your workflow even easier, a new export option as an image sequence has been added to the menu.

This release also brings support for loading and saving Rive animations, improving the quality of video exports, and adding command line options for rendering images without starting the GUI.

Issues with loading Glaxnimate and old Lotties files have also been resolved, as well as a crash on SVG export.

Scripting Additions

For developers and advanced users, the new release features a function to render a node at a specific frame, providing even more control over your animations.

Bug Fixes and Minor Enhancements

This release also includes several bug fixes, including resolution of issues with loading Lotties with hidden fill and stroke, improved previews in the stroke style view, and proper application of duration changes in the startup dialog to all layers.

Additionally, Glaxnimate 0.5.2 includes the addition of Flatpak, improved Freedesktop file naming and metainfo, and the ability to view contributors. Messages are also logged to a file for better tracking of errors and issues.

The Select tool has also been improved, allowing for better handling of ungrouped shapes, making your editing process smoother and more efficient.

Download

We are confident that these new features and improvements will enhance your experience with Glaxnimate and look forward to continuing to bring you the best vector animation application.

If you're interested in trying it out, head over to our download page to get started. As always, if you have any questions or feedback, feel free to reach out to us via our issue tracker.

Thank you for your continued support of Glaxnimate!

As announced previously, Plasma 5.27 will have a significantly reworked multiscreen management, and we want to make sure this will be the best LTS Plasma release we had so far.

Of course, this doesn’t mean it will be perfect from day one, and your feedback is really important, as we want to fix any potential issue as fast as they get noticed.

As you know, for our issue tracking we use Bugzilla at this address. We have different products and components that are involved in the multiscreen management.

First, under New bug, chose the “plasma” category. Then there are 4 possible combinations of products and components, depending on the symptoms:

In order to have a good complete information on the affected system, its configuration, and the configuration of our multiscreen management, if you can, the following information would be needed:

• Whether the problem happens in a Wayland or X11 session (or both)
• A good description of the scenario: how many screens, whether is a laptop or desktop, when the problem happens (startup, connecting/disconnectiong, going out of sleep and things like that)
• The output the terminal command: kscreen-doctor -o
• The output of the terminal command: kscreen-console
• The main plasma configuration file: ~/.config/plasma-org.kde.plasma.desktop-appletsrc

Those items of information already help a lot figuring out what problem is and where it resides.

Afterwards we still may ask for more informations, like an archive of the main screen config files that are the directory content of ~/.local/share/kscreen/ but normally, we wouldn’t need that.

One more word on kscreen-doctor and kscreen-console

Those 2 commands are very useful to understand what Plasma and the rest of the system thinks about every screen that’s connected and how they intend to treat them.

kscreen-doctor

Here is a typical output of the command kscreen-doctor - o:

Output: 1 eDP-1 enabled connected priority 2 Panel Modes: 0:1200x1920@60! 1:1024x768@60 Geometry: 1920,0 960x600 Scale: 2 Rotation: 8 Overscan: 0 Vrr: incapable RgbRange: Automatic
Output: 2 DP-3 enabled connected priority 3 DisplayPort Modes: 0:1024x768@60! 1:800x600@60 2:800x600@56 3:848x480@60 4:640x480@60 5:1024x768@60 Geometry: 1920,600 1024x768 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic
Output: 3 DP-4 enabled connected priority 1 DisplayPort Modes: 0:1920x1080@60*! 1:1920x1080@60 2:1920x1080@60 3:1680x1050@60 4:1600x900@60 5:1280x1024@75 6:1280x1024@60 7:1440x900@60 8:1280x800@60 9:1152x864@75 10:1280x720@60 11:1280x720@60 12:1280x720@60 13:1024x768@75 14:1024x768@70 15:1024x768@60 16:832x624@75 17:800x600@75 18:800x600@72 19:800x600@60 20:800x600@56 21:720x480@60 22:720x480@60 23:720x480@60 24:720x480@60 25:640x480@75 26:640x480@73 27:640x480@67 28:640x480@60 29:640x480@60 30:720x400@70 31:1280x1024@60 32:1024x768@60 33:1280x800@60 34:1920x1080@60 35:1600x900@60 36:1368x768@60 37:1280x720@60 Geometry: 0,0 1920x1080 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic

Here we can see we have 3 outputs, one internal and two via DisplayPort, DP-4 is the primary (priority 1) followed by eDP-1 (internal) and DP-3 (those correcpond to the new reordering UI in the systemsettings screen module).

Important data points, also the screen geometries (in italic in the snippet) which tell their relative positions.

kscreen-console

This gives a bit more verbose information, here is a sample (copied here the data of a single screen, as the output is very long):

Id: 3
Name: "DP-4"
Type: "DisplayPort"
Connected: true
Enabled: true
Priority: 1
Rotation: KScreen::Output::None
Pos: QPoint(0,0)
MMSize: QSize(520, 290)
FollowPreferredMode: false
Size: QSize(1920, 1080)
Scale: 1
Clones: None
Mode: "0"
Preferred Mode: "0"
Preferred modes: ("0")
Modes:
"0" "1920x1080@60" QSize(1920, 1080) 60
"1" "1920x1080@60" QSize(1920, 1080) 60
"10" "1280x720@60" QSize(1280, 720) 60
"11" "1280x720@60" QSize(1280, 720) 60
"12" "1280x720@60" QSize(1280, 720) 59.94
"13" "1024x768@75" QSize(1024, 768) 75.029
"14" "1024x768@70" QSize(1024, 768) 70.069
"15" "1024x768@60" QSize(1024, 768) 60.004
"16" "832x624@75" QSize(832, 624) 74.551
"17" "800x600@75" QSize(800, 600) 75
"18" "800x600@72" QSize(800, 600) 72.188
"19" "800x600@60" QSize(800, 600) 60.317
"2" "1920x1080@60" QSize(1920, 1080) 59.94
"20" "800x600@56" QSize(800, 600) 56.25
"21" "720x480@60" QSize(720, 480) 60
"22" "720x480@60" QSize(720, 480) 60
"23" "720x480@60" QSize(720, 480) 59.94
"24" "720x480@60" QSize(720, 480) 59.94
"25" "640x480@75" QSize(640, 480) 75
"26" "640x480@73" QSize(640, 480) 72.809
"27" "640x480@67" QSize(640, 480) 66.667
"28" "640x480@60" QSize(640, 480) 60
"29" "640x480@60" QSize(640, 480) 59.94
"3" "1680x1050@60" QSize(1680, 1050) 59.883
"30" "720x400@70" QSize(720, 400) 70.082
"31" "1280x1024@60" QSize(1280, 1024) 59.895
"32" "1024x768@60" QSize(1024, 768) 59.92
"33" "1280x800@60" QSize(1280, 800) 59.81
"34" "1920x1080@60" QSize(1920, 1080) 59.963
"35" "1600x900@60" QSize(1600, 900) 59.946
"36" "1368x768@60" QSize(1368, 768) 59.882
"37" "1280x720@60" QSize(1280, 720) 59.855
"4" "1600x900@60" QSize(1600, 900) 60
"5" "1280x1024@75" QSize(1280, 1024) 75.025
"6" "1280x1024@60" QSize(1280, 1024) 60.02
"7" "1440x900@60" QSize(1440, 900) 59.901
"8" "1280x800@60" QSize(1280, 800) 59.91
"9" "1152x864@75" QSize(1152, 864) 75
EDID Info:
Device ID: "xrandr-Samsung Electric Company-S24B300-H4MD302024"
Name: "S24B300"
Vendor: "Samsung Electric Company"
Serial: "H4MD302024"
EISA ID: ""
Hash: "eca6ca3c32c11a47a837d696a970b9d5"
Width: 52
Height: 29
Gamma: 2.2
Red: QQuaternion(scalar:1, vector:(0.640625, 0.335938, 0))
Green: QQuaternion(scalar:1, vector:(0.31543, 0.628906, 0))
Blue: QQuaternion(scalar:1, vector:(0.15918, 0.0585938, 0))
White: QQuaternion(scalar:1, vector:(0.3125, 0.329102, 0))

Important also the section EDID Info, to see if the screen has a good and unique EDID, as invalid Edids, especially in combination with DisplayPort is a known source or problems.