This month, we welcome a new chat app for Matrix, while KIO Fuse brings better integration with files on a local network.
Back in 2019, KDE added Matrix to its instant messaging services. Matrix brings KDE’s chat channels up to date with persistent connections you can use from all your devices, lets you send pictures and includes plugins for things like video chat.
Now KDE has its own Matrix app too: NeoChat. NeoChat is written using our Kirigami user interface framework which gives the app a modern look and feel and allows it to adapt well to all your devices, be it your desktop, laptop, tablet or phone.
Read the full announcement for more information.
You can get NeoChat from Flathub or from your distribution’s repos.
Soon NeoChat will be available for Windows and Android too.
The other big news this week is KIO Fuse, an addon for KDE apps that improves the integration of remote files with your desktop.
While apps using KDE frameworks, like Kate or Dolphin, can talk directly to network protocols such as Windows' SMB or SSH, other apps like LibreOffice cannot. Instead, KDE used to make local copies of remote files that were then copied back and forth between the servers and the desktop. This proved to be unreliable and could lead to the data loss. Now, using KIO Fuse, all apps will be able to talk to remote files as if they were local, removing the problems of making a temporary copies.
Distributions such as openSUSE tumbleweed and KDE neon have already started shipping with KIO Fuse pre-installed.
KDevelop 5.6.1 was released this month and adds support for Python 3.9 and Gdb 10. Several crashes on exit while debugging were fixed and the behavior of the “Stop” and “Stop all” toolbar buttons were made less confusing.
New apps that have moved into KDE include:
MyGnuHealth, a component of GNU Health, the Libre digital health ecosystem. MyGNUHealth will be able to track your heart rate, blood pressure and other vital signs, nutritional and lifestyle factors that have help you keep fit. It became a KDE project this month.
KGeoTag is a Free/Libre Open Source photo geotagging program and it is now in beta.
Kongress, an app which provides practical information about conferences such as the schedule and locations of talks at the venue, passed the kdereview stage this month.
Some of our projects release on their own timescale and some get released en-masse. The 20.12.1 bundle of projects was released today with dozens of bugfixes and will be available through app stores and distros soon. See the 20.12.1 releases page for details.
Some of the fixes in today’s bugfix releases include:
20.12 release notes • Package download wiki page • 20.12.1 source info page • 20.12.1 full changelog
If you would like to help, get involved! We are a friendly and accepting community and we need developers, writers, translators, artists, documenters, testers and evangelists. You can also visit our welcome chat channel and talk live to active KDE contributors.
Another way to help KDE is by donating to KDE and helping the Community keep things running.
Following Kévin it’s my turn to show you what happened around Kontact in the previous two months. More than 30 people contributed about 1200 changes in that time, we had a new major release in early December and there’s a virtual New Year meetup on Saturday!
Cornelius is organizing an online KDE PIM Meetup next Saturday, starting at 14:00 CET, themed in the 15+ year old tradition of the new year sprints at the Intevation office in Osnabrück, where much of what we have in Kontact today got started. Past, present and future PIM contributors should follow the wiki page for the meeting details :)
There has been a renewed effort to push Kontact on Windows forward, resulting in various fixes throughout the entire stack by Dan, Hannah, Laurent and others.
To improve the experience on Windows, there is an ongoing effort to move password storage from using KWallet directly to handling that via QtKeychain. This will use the corresponding platform infrastructure for credential storage (which on Linux, FreeBSD, etc of course still is KWallet).
Improving forward compatibility with the upcoming Qt6 and KF6 transition also remained an important topic all over the place.
Take a look at some of the junior jobs that we have! They are simple, mostly programming tasks that don’t require any deep knowledge or understanding of Kontact, so anyone can work on them. Feel free to pick any task from the list and reach out to us! We’ll be happy to guide you and answer all your questions. Read more here…
You might have noticed that the blog has a markedly different look than before. It has not only changed visually, but also under the hood. This (brief) post summarizes the reasons behind the change.
Simply put, the previous solution was unmaintainable. “But,” you might say, “it was a static site generator! How could it become unmaintainable?”.
It can. You might recall I moved from Wordpress to Jekyll about six years ago. I chose the Feeling Responsive theme at the time, but it did not do what I wanted it to do (including support of Isso for hosted comments), and it was meant to be a landing page rather than a blog.
So, having probably indulged in something that altered my perceptions at the time (funny, because I neither drink nor smoke…), I forked the theme.
Yes. You read that right. I forked the theme. And to add the functionality I required, and in particular not to leave many broken links around I had to add several Jekyll plugins: some I even had to modify myself to make them behave properly.
Then…
Jekyll had several compatibility-breaking updates. I couldn’t update my fork because it was far beyond my ability (I’m a scientist, not a designer nor a coder in the strict sense), and many plugins started falling apart. I had to hastily prepare a makeshift Docker image containing the exact versions of everything I had (Jekyll 2.5.x, even) and spend several hours trying to make it work correctly (that included using obsolete versions of Alpine Linux, for example).
In short, I made even a worse job than what Viktor von Frankenstein did. Unfortunately, I am not really proud of that. The horrible contraption I built made even writing posts problematic, because the process would sometimes break.
It’s good having a blog where not even the main author can write and expect things to be published, eh?
More recently, I’ve been reading about Hugo, a rather fast static site generator which also happens to be packaged for openSUSE. In particular I found the approach to theming better than Jekyll, because you can just override parts of a theme should you require it, instead of forking a whole theme and hope for the best.
Thus, I used the Ananke theme with some extra additions (documented in the git repository). Importing things was pretty painless. The CSS wasn’t, and I’m sure there are still loads of broken things, but at least I’m moving forward. Please leave a comment if you find anything broken, thanks!
Hopefully I can blog a little more than just making an update and disappearing again (not that I’ve disappeared: I’ve been fairly active doing packaging work in openSUSE). But again, to quote the words of Merlin, “it is a secret only known to the ancient gods and me.”
Conquests of Camelot: The Search for the Grail - © 1989 Sierra On-Line
If I look back at the last post I made on ths blog… let’s say quite a lot of time has passed. The reason? Well, first of all, one would call it a lack of motivation1, and afterwards, the emergence of a small yet quite annoying pathogen which caused a bit of a stir worldwide. But today I’m not going to talk about viruses: perhaps some other time when you can avoid hear about it for breakfast, lunch, and dinner.
Yes, today I’m going to talk about the OBS, that is the Open Build Service, not to be confused with another highly successful open source project.
As you know, since ages, the openSUSE KDE team provides a series of repositories which track the latest state of the git repositories in KDE, be them either Frameworks, Plasma, or the applications part of the Release Service. This also allows to create Live CDs which can be useful for testing out the software.
But the question that I’ve seen every now and then is… how it is actually done? Is everything provided by the OBS, or does someone need to add some glue on top of that?
From the official documentation:
Source Services are tools to validate, generate or modify sources in a trustable way.
Ok, that doesn’t tell us much, does it? Luckily, the concept is simple. It is that, for packages built in the OBS, we can use tools (internal or external) to perform operations on the source(s) the packages are built from. These are done before any actual building starts.
The openSUSE wiki has some examples of what a source service can do, of which one immediately jumps to our eye:
Checkout service - checks out from SVC system (svn, git, …) and creates a tarball.
That means that we can, theoretically, ask the OBS to do a checkout from git, and automatically generate a tarball from there. In addition, a source service can add version information to the RPM spec file - the blueprint of an openSUSE package - including some data taken off git, for example the date and the revision hash of the checkout.
Source services are implemented as files named _service
which live in the OBS for each package. Let’s take a look at the one for kcoreaddons
in the KDE:Unstable::
<services>
<service name="obs_scm">
<param name="url">https://invent.kde.org/frameworks/kcoreaddons.git</param>
<param name="scm">git</param>
<param name="versionformat">VERSIONgit.%ci~%h</param>
</service>
<service name="set_version_kf5" mode="buildtime"/>
<service mode="buildtime" name="tar" />
<service mode="buildtime" name="recompress">
<param name="file">*.tar</param>
<param name="compression">xz</param>
</service>
<service mode="buildtime" name="set_version" />
</services>
The first line inside service
tells us that we’re using the obs_scm
service, which is a built-in service in openSUSE’s OBS instance to checkout the sources from the url, using git. The versionformat
parameter sets the version to a literal VERSION
(more on that later) and adds the git
suffix, and then adds %ci
, which is replaced by the checkout date (example: 20210102T122329
) and %h
, which puts the short git revision hash in the version (example: 5d069715
).
The whole data is compressed in a cpio archive with the obscpio
extension. At this point, we don’t have a tarball yet.
THe next services run when the package is actually built, as you can see by the mode="builtime"
in their definitions. The first one (set_version_kf5
) is actually a service made by Fabian Vogt (fellow member of the KDE team) which replaces VERSION
by the current version present in the KDE git (done manually: it is read from the OBS project configuration, and bumped every time it happens upstream). The following lines set the version in the spec file, and compress the whole thing into a tarball.
At this point, the build system starts building the actual source and creating the package.
Just when are these kind of source services run? If left by themselves, never. You need to actually signal the OBS (trigger, in OBS-speak) to run the service. An example is with the osc
command line utility:
osc service remoterun KDE:Unstable:Frameworks kcoreaddons
Or there’s a button in the OBS web interface which can allow you to do just that:
There’s just a little problem. When there are more than 200 packages to handle, updating in this way gets a complicated. Also, while the OBS is smart enough to avoid updating a package that has not changed, it has no way to tell you before the service is actually run.
Luckily, the OBS has features which, used with some external tools, can solve the problem in a hopefully effective way.
Since 2013 the OBS can use authentication tokens to run source services, and you can for example trigger updates with pushes to GitHub repositories. To perform this task for the KDE:Unstable repositories, I based upon these resources to build something to do mass updates in a reliable way.
First of all, I generated a token, and I wanted to make sure that it could only trigger updates. Nothing more, nothing less. This was fairly easy with osc
:
osc token --create -o runservice
I did not specify a project, so the token works with all the repositories I have access to. This was a requirement, because the KDE Unstable repositories are actually three different OBS projects.
To trigger an update in the OBS, one needs to call the https://api.opensuse.org/trigger/runservice
endpoint, doing a POST request and include the project name (project
parameter) and the package name (package
parameter). An example (I know, I didn’t encode the URL for simplicity, bear with me):
https://api.opensuse.org/trigger/runservice?project=KDE:Unstable:Frameworks&package=kcoreaddons
The token needs to be passed as an Authorization
header, in the form Token <your token here>
. You get a 200 response if the trigger is successful, and 404 in other cases (including an incorrect token).
Like this, I was able to find a way to reliably trigger the updates. In fact, it would be probably easy to conjure a script to do that. But I wanted to do something more.
I wanted to actually make sure to trigger the update only if there were any new commits. But at the same time I did not want to have a full checkout of the KDE git repositories: that would have been a massive waste of space.
Enter git ls-remote
, which can give you the latest revision of a repository for all its branches (and tags), without having to clone it. For example:
git ls-remote --heads https://invent.kde.org/pim/kitinerary.git/
22175dc433dad1b1411224d80d77f0f655219122 refs/heads/Applications/18.08
5a0a80e42eee138bda5855606cbdd998fffce6c0 refs/heads/Applications/18.12
2ca039e6d4a35f3ab00af9518f489e00ffb09638 refs/heads/Applications/19.04
2f96d829f28e85f3abe486f601007faa2cb8cde5 refs/heads/Applications/19.08
f12f2cb73e3229a9a9dafb347a2f5fe9bd6c7975 refs/heads/master
18f675d888dd467ebaeaafc3f7d26b639a97d142 refs/heads/release/19.12
90ba79572e428dd150183ba1eea23d3f95040469 refs/heads/release/20.04
763832e4f1ae1a3162670a93973e58259362a7ba refs/heads/release/20.08
c16930a0b70f5735899826a66ad6746ffb665bce refs/heads/release/20.12
In this case I limited the list to branches to branches (--heads
). As you can see, the latest revision in master
for kitinerary at the time of writing is f12f2cb73e3229a9a9dafb347a2f5fe9bd6c7975
. So, the idea I had in mind was:
This was slightly complicated by the fact that package names on the OBS and source repositories in KDE can differ (example: plasma-workspace
is plasma5-workspace
or akonadi
is akonadi-server
). My over-engineered idea was to create a JSON mapping of the whole thing (excerpt):
{
"KDE:Unstable:Frameworks": [
{
"kde": "frameworks/attica",
"obs": "attica-qt5",
"branch": "master"
},
{
"kde": "frameworks/kdav",
"obs": "kdav",
"branch": "master"
}
]
}
(Full details on the actual repository)
It was painful to set up the first time, but it paid off afterwards. I just needed a few more adjustments:
As I am mostly a Python person, I just used Python to write a yet another over-engineered script to do all the steps outlined above.
Mmm… cake. Wait. We’re not talking about food here, just about how the whole idea was put into “production” (include several hundred of quotes around that word). I created a separate user on my server (the same which runs dennogumi.org) with minimal privileges, put the token into a file with 0600 permissions, and set up a cron job which runs the script every day at 20 UTC+1.
There was just one extra step. Historically (but this is not the case anymore nowadays) the OBS would fail to perform a git checkout. This would leave a package in the broken state, and the only way to recover would be to force an update again (if that did not fix it, it would be time to poke the friendly people in #opensuse-buildservice
).
Inspired by what a former KDE team member (Raymond “tittiatcoke” Wooninck) did, I wrote a stupid script which checks the packages in broken state (at the moment just for one repository and one architecture: a broken clone would affect all of them equally) and forces an update. It needs to use tokens rather than osc
, but I’ll get to that soon, hopefully.
There, you have it. This is how (at the moment) I can handle updating all KDE packages from git in the OBS with (now) minimal effort. Probably it is an imperfect solution, but it does the job well. Shout out to Fabian who mentioned tokens and prompted the idea.
Also called laziness. ↩︎
Tuesday, 05 January 2021
Today KDE releases a bugfix update to KDE Plasma 5, versioned 5.20.5. Plasma 5.20 was released in October with many feature refinements and new modules to complete the desktop experience.This release adds a month’s worth of new translations and fixes from KDE’s contributors. The bugfixes are typically small but important and include:
As I wrote last time, I currently develop a web app based on Django and Vue using the django-compressor-parceljs. I’d like to mention some small things that I’ve learned since last.
Vue in development mode
I found it interesting that parceljs described how to get Vue into development mode for several bundlers, but failed to mention parcel. After some digging around, I figured out that parcel respects the NODE_ENV environment variable, so starting the django server with NODE_ENV=development ./manage.py runserver
does the trick. Now I get proper error messages from Vue.
Constantly rebundling
Another annoyance with the default configuration of the compressor, was that it compiles (bundles / compresses) the Vue files once every time the server is started. This really lengthened the change-build-test cycle time, so something needed to be done. It turns out that the solution is to set the COMPRESS_REBUILD_TIME to a really low value in the django settings, and the contents is compressed every time. I set it to one second on my development machine.
Disabling compression would break the Vue files, as the browser cannot run the Vue files natively, i.e. they need a compression to be possible to run.
The consequence of this configuration is that loading a view based on Vue takes a bit longer, but it takes way shorter time than restarting the django server, recreating the backend state and so on.
Exposing Django context to Javascript
Django exposes a set of context variables when loading a view. This avoids an unnecessary round-trip over the server to asynchronously request the info that I already know the view will need. I’ve developed a small convention for this.
In the Django template, I add something along these lines:
<script>
var context_title = '{{ title }}';
var context_actors = [
{% for actor in actors %}'{{ actor }}',
{% endfor %} ];
...
</script>
This copies the django context into Javascript space with the variable name prefix of context_
. I then consume these in the Vue app’s mounted
method, e.g.:
...
mounted() {
this.title = context_title;
this.actors = context_actors;
...
},
...
This copies the state into the state of the app, which means that it is now a part of what the Vue interface is reactive to.
KDE people mostly spent the time on a well-deserved break this week, but we still managed to get some things done. Check it out:
Kate’s CTags plugin now includes a “Go to symbol” feature (Waqar Ahmed, Kate 21.04)
Dolphin now lets you modify the entries in the context menu so you can remove items you never ever use (Duong Do Minh Chau, Dolphin 21.04):
Okular now more reliably recognizes Markdown files for what they are so it can render them correctly (Albert Astals Cid, Okular 20.12.1)
Further improved the speed of Kate’s search feature, nearly doubling it for the case of very long files (Waqar Ahmed, Kate 21.04)
Konsole’s terminal bell feature now triggers the system bell too (Ahmad Samir, Konsole 21.04)
KRunner’s windows runner (which finds open windows) now has tiny little thumbnail images again (Kai Uwe Broulik, Plasma 5.21)
KRunner’s history view now works properly with the mouse (Alexander Lohnau, Plasma 5.21)
The progress bar that appears in a “file is being downloaded” notification now renders correctly in all circumstances (Kai Uwe Broulik, Frameworks 5.78)
Mnemonics (those little horizontal lines that appear below letters when you hold down the alt key) now work for Plasma buttons and tabs (David Edmundson, Frameworks 5.78)
Okular’s settings window has been modernized to use the common FormLayout style (David Hurka, Okular 21.04):
Dolphin now makes it a bit more obvious how you connect to a remote server whose URL you know when you click on the Network item in the Places panel (me: Nate Graham, Dolphin 21.04):
You can now middle-click or scroll on the entire selection area for System Tray icons, rather than just on the little icon itself (Konrad Materka, Plasma 5.21)
When searching for power-related actions in KRunner (e.g. “Shut down,” “restart,” etc), KRunner now matches partial strings and finds the actions by their English words even when your system language is set to something else (Alexander Lohnau, Plasma 5.21)
Kate and other KTextEditor-based apps now show the dragged text while it’s being dragged (Waqar Ahmed, Frameworks 5.78)
Have a look at https://community.kde.org/Get_Involved to discover ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!
Finally, consider making a tax-deductible donation to the KDE e.V. foundation.
We are pleased to announce the launch of Nitrux 1.3.6. This new version brings together the latest software updates, bug fixes, performance improvements, and ready-to-use hardware support.
Nitrux 1.3.6 is available for immediate download.
sudo apt install -yy nvidia-driver-450 nvidia-settings nvidia-prime ubuntu-drivers-common sudo apt install -yy --reinstall nx-desktop-settings-legacy
To report bugs, please use our bug tracker at GitHub.
To see a list of previous changelogs, click here for the changelogs archived at our site, or click here for the changelogs archived at Sourceforge.
The post Changelog: Nitrux 1.3.6 appeared first on Nitrux — #YourNextOS.
Just like last year, here are the things I expect will get done in 2021:
We’ll finally finish up polkit-in-kio, which got closer in 2020 but didn’t quite make it. 2021 will be the year! We will probably also get power/session actions in the lock screen as this feature is necessary for Plasma Mobile, and making it work in the Plasma Desktop session as well will be fairly simple. Per-screen scaling on X11 seems unlikely given our renewed focus on Wayland, and on that subject…
I’ll be honest: before 2020 the Plasma Wayland session felt like a mess to me. Nothing worked properly. But all of this changed in 2020: suddenly things started working properly. I expect the trend of serious, concentrated Wayland work to continue in 2021, and finally make Plasma Wayland session usable for an increasing number of people’s production workflows.
This is already in progress! It’s a lot of work because support needs to be added in SDDM, the lock screen, KAuth, Polkit… There are a lot of moving pieces to put together. I think 2021 will be the year that it finally happens!
This work is in progress and about half of it has already been merged, to be released in Plasma 5.21. I expect the rest will land in Plasma 5.22 and possible 5.23 later in the year. At that point, the project will be complete and our apps will look super modern and awesome!
A super-fantastic replacement for the venerable Kickoff application launcher has been in heavy development throughout 2020, according to the spec that VDG wrote in 2019. It’s almost done, and I expect it to be merged soon and be released in Plasma 5.21.
This is already in progress and very close to being done! 2021 will be the year that Konsole’s window finally re-flows the text when you resize it.
I feel like we’re getting really really close to the goal of having a mainstream-hardware-ready software stack. In some ways we’re already there, especially when you compare our stuff to some of the weaker offerings in the market. We need to keep plugging away, and start thinking about the next steps: more hardware partnerships, closer coordination with distros, and more engineering effort for our own Neon distro. 2021 is going to be a great year for KDE and KDE users! So what are you waiting for? Get involved!
Rachana Institute of Typography starts the new year 2021 with the release of a new body-text Malayalam Unicode font named ‘Panmana’.
The font is named after and dedicated to Prof. Panmana Ramachandran Nair who steadfastly voiced for the original script of Malayalam. It is designed by K.H. Hussain with inputs from Ashok Kumar and CVR and font engineering by Rajeesh (your correspondent); maintained by RIT.
‘Panmana’ is released under Open Font License, free to use and share. Truetype and Web font can be downloaded from the website. A flyer about the font is available. If you spot any issues, please report those in the source repository.