Skip to content

Wednesday, 1 January 2025

I use several non-KDE Qt-based applications which I tend to compile manually from source to use the same non-distro-provided Qt version that I compile KDE software against.

I’ve noticed that I don’t update them as often as the rest of the system, so I decided to see if I can add them to kdesrc-build.

The packages-to-be-built definitions are located in repo-metadata/module-definictions which already contains a few 3rd-party libraries that the KDE frameworks and applications use.

Adding the Strawberry player (fork of Clementine, which was a fork of Amarok 1.x) to the build, was quite straight-forward. I just needed to define the repository, cmake options to make it build the Qt6 version instead of the Qt5 one, and the branch I want to build from.

module strawberry
    repository https://github.com/strawberrymusicplayer/strawberry.git
    cmake-options -DBUILD_WITH_QT6=ON
    branch master
end module

For applications with normal cmake setup, it is as easy as that. But there are applications like recoll which don’t have a CMakeLists.txt file in the top level, and kdesrc-build doesn’t like that.

To ensure that kdesrc-build finds the real src directory for cmake, I needed to do something completely hackhish. I had to pass the path to the source directory, which is otherwise defined automatically by kdesrc-build for each project it builds, to cmake-options:

module recoll
    repository https://framagit.org/medoc92/recoll.git
    cmake-options \
        -DRECOLL_QT6_BUILD=1 \
        -DRECOLL_ENABLE_SYSTEMD=0 \
        -DRECOLL_ENABLE_WEBENGINE=1 \
        -DRECOLL_ENABLE_X11MON=0 \
        -S /kde/src/recoll/src
    branch master
end module

Fortunately, kdesrc-build appends cmake-options the normal cmake arguments, so my -S path overrides the path that kdesrc-build defines.

Tuesday, 31 December 2024

I use Hugo to build my website (which you can explore the source code to on GitHub.) And because I love using KDE applications whenever I can, I do all of my editing - from config files, CSS and Markdown for posts - in Kate.

My song & dance when I want to edit my website is a bit inefficient. I would use Kate, then manually navigate to my folder. Or I would invoke Kate from the command-line to do the same. Then I would open a separate Konsole window (and sometimes the integrated terminal) in order to launch Hugo to build the site. I would then open up a separate terminal to perform git operations.

So I have created a neat workflow that I think is worth sharing, in case you didn’t know Kate had these features. This also serves as documentation to myself whenever I want to re-create it.

Sessions

The first and easiest improvement is to use sessions. You can manage these under the “Session” menu item at the top of Kate.

My sessions window.

Instead of opening a fresh Kate session each time, the folder I was in (which is always my site’s folder) and the open documents I have are saved automatically. Note that you probably need the Projects plugin enabled to have access to the “Projects” tab where it’s state is also saved in the session.

External Tools

The next thing to tackle is making it easier to launch Hugo. We can accomplish this by using External Tools, which is managed under Settings or under the Tools menu item. I have two, one for launching Hugo and the other for stopping it.

These external tools can be pinned to the “Main Toolbar <externaltools>” in the Configure Toolbars window.

These external tools are self-explanatory, but I set the working directory to %{Project:Path} to ensure it’s running at the site root. I also have it set to spit out the Hugo output into the pane, but it doesn’t actually display until the process quits which seems like a bug in Kate.

The output pane when Hugo is finished

It’s not a huge deal, as the output is displayed when I use the “Stop Hugo” action. I suggest using the “-O” argument of hugo server to automatically open your default web browser when Hugo completes initialization.

Ideas

It would be cool to have a preview pane that automatically finds the Markdown file you’re editing and navigate to it, which seems possible. Another nicety would be a native Kate plugin to handle launching/stopping/configuring the Hugo server. But this workflow is already a big improvement over what I had before.

Sunday, 29 December 2024

The Amarok Development Squad is happy to announce the immediate availability of Amarok 3.2 "Punkadiddle"!

2024 was the year that finally introduced a Qt5/KF5 based Amarok 3 release in April, and it was followed by a number of 3.x bugfix and feature releases. Now, to conclude 2024, it is time for Amarok 3.2.0. The most interesting change is probably the ability to build the same codebase on both Qt5 and Qt6. Qt5/KF5 is still the recommended, tested configuration, for now. Qt6 version should be usable, but in addition to any unknown issues, there are a number of known issues documented in README.

Additionally, 3.2.0 includes e.g. collection filtering and Ampache related features and fixes, oldest resolved feature request being from 2013. Multiple long-standing crash bug reports have been closed lately, and probable fixes for various issues observed in crash report data have been introduced. Amarok 3.2.0 should thus feature slightly improved stability. Some 3.2.x bugfix releases are to be expected in 2025, before the focus shifts to preparations for an "Amarok 4".

Changes since 3.1.1

CHANGES:
  • Building an experimental Qt6/KF6 Amarok version is now possible
  • Allow filtering collection by lack of tag / empty tag (BR 325317)
CHANGES:
  • Amarok now depends on KDE Frameworks 5.108
  • Show current track context applet by default
BUGFIXES:
  • Probably fix occasional crashes when filtering collection (BR 492406)
  • Probably fix occasional crashes when clearing CompondProgressBars
  • Fix context view applets on Qt6/KF6
  • Fix Ampache login on server version 5.0.0 and later (BR 496581)
  • Fix crash if Ampache login is redirected (BR 396590)

The git repository statistics between 3.1.0 and 3.2.0 are as follows:

l10n daemon script: 68 commits, +41987, -35275
Tuomas Nurmi: 46 commits, +723, -4854
Raresh Rus: 3 commits, +41, -53
Ian Abbott: 1 commit, +17, -3
Heiko Becker: 1 commit, +0, -3

Getting Amarok

In addition to source code, Amarok is available for installation from many distributions' package repositories, which are likely to get updated to 3.2.0 soon, as well as the flatpak available on flathub.

Packager section

You can find the tarball package on download.kde.org and it has been signed with Tuomas Nurmi's GPG key.

Unfortunately, there won't be any "This Week in KDE Apps" blog post this week as I (Carl) and others are at the #38C3 (Chaos Communication Congress) in Hamburg. But if you are also there, don't hesitate to come by and say hi.

The KDE stand at 38c3

One of the much requested feature for Kdenlive was a modern background removal tool.

Among the many features and enhancements that will come in 2025, we are excited to announce a preview version with a background removal tool using object masks. The feature is based on SAM2‘s object segmentation. You can download the Kdenlive test alpha version from the links at the bottom of this page.

Since this is a testing preview version, the binaries are not signed and you might need to manually allow the install on Windows.

Here is a quick demo of how the feature works in screenshots:

  1. Add a clip to your project
  2. Select a zone to apply the background removal
  3. Click on the Mask button
  4. Select Configure to setup the tool (to be done only the first time)
  1. Click on Install in the Object detection setup

Go drink a coffee while the module is being downloaded and installed (between 5 and 15 minutes depending on your internet connection). Currently there is not much feedback from the install, we will improve this so just be patient.

Kdenlive downloads the smallest model by default. Once it shows up, you can close the dialog and start using the feature.

  1. Click on the Create new mask button
  2. Click on the object you want to keep (foreground)
  3. When the white mask appears, click on Generate Mask
  4. The video mask task starts, drink another coffee

When the video mask is created, it will appear in the mask manager dialog (2).

  1. Drag your clip zone from the clip monitor to timeline
  2. Select the newly created mask
  3. Click on Apply Mask

Success, you can now enjoy your video without the background.

Of course, this feature can also be used for other exciting things like applying an effect or a color correction to a specific object only.

Keep in mind that this is an alpha version, we will enhance and polish it for the upcoming 25.04 version. Happy editing!

Linux AppImage download:

https://files.kde.org/kdenlive/unstable/kdenlive-25.04.0-alpha-x86_64.AppImage.mirrorlist

Windows download:

https://files.kde.org/kdenlive/unstable/kdenlive-25.04-alpha-x86_64.exe.mirrorlist

Flatpak:

Check our experimental nightly version (see instructions at the bottom of our download page)

Screen magnification is an accessibility feature that enlarges the screen to make text, images, and other user interface components easier to see or read. It is not something that requires constant developer attention, however, in Plasma 6.3, the zoom plugin received some improvements that I’d like to go over quickly.

Pixel grid

A script element has been removed to ensure Planet works properly. Please find it in the original post.

Arguably, it will be too hard to read text if the screen is “too” zoomed in. There are several ways how this case can be handled. For example, the magnification factor can be capped (e.g. to x8 or x10), or do nothing and just display blurry upscaled screen contents… or display something else.

With the old behavior, the zoom plugin used not to do anything special when the magnification factor reaches a high value, but with the new behavior, it is going to display the individual pixels on the screen. This can be very useful to developers, designers, etc.

System settings

In addition to the new pixel grid mode, the system settings for the zoom plugin received minor polishing to look more consistent with other config modules.

Future improvements

Keyboard shortcuts are not the only way how the zoom plugin can be triggered. For example, it can be also triggered by pressing Meta and Control keys and scrolling the mouse wheel to zoom. However, it is not exposed anywhere in the user interface and some people may prefer zooming with just the Meta key pressed. In order to address the discoverability issue of the mouse wheel gesture and allow using a different combination of modifier keys, there is already a patch to add the corresponding system setting, but it’s 6.4 material. It would be also nice to move screen magnifier settings from the desktop effects config module to the accessibility config module.

Last but not least, the zoom effect currently uses the bi-linear magnification filter, which produces okay-ish visual results, but it’s worth looking for alternative upscaling algorithms that handle edges better so zoomed in text looks less blurry.

Hello,

I need your help. I’ve created a first version of Skrooge that can be built on KF6 and Qt6 (Its temporary number version is 2.33.8).

I use it daily for managing my own accounts. However, before releasing an official version, I’d like some of you to test it and provide feedback by reporting any issues you encounter.

I’m counting on you! To get started, check out the download section and the README.md.

Thanks in advance!

Friday, 27 December 2024

Bundle Creator

After almost a year, I finally found some time to dive back into Krita. I stumbled upon the Memileo Impasto Brushes bundle, which mimics the texture and thickness of real paint—perfect for adding depth and dimension. Inspired to try them out, I created this quick one-hour painting.

Friday, 20 December 2024

I started this blog back in 2010. Back then I used Wordpress and it worked reasonably well. In 2018 I decided to switch to a static generated site, mostly because the Wordpress blog felt slow to load and it was hassle to maintain. Back then the go-to static site generator was Jekyll, so I went with that. Lately I’ve been struggling with it though, because in order to keep all the plugins working, I needed to use older versions or Ruby, which meant I had to use Docker to build the blog locally. Overall, it felt like too much work and for the past few years I’ve been eyeing Hugo - more so since Carl and others migrated most of KDE websites to it. I mean, if it’s good enough for KDE, it’s good enough for me, right?

So this year I finally got around to do the switch. I migrated all the content from Jekyll. This time I actually went through every single post, converted it to proper Markdown, fixed formatting, images etc. It was a nice trip down the memory lane, reading all the old posts, remembering all the sprints and Akademies… I also took the opportunity to clean up the tags and categories, so that they are more consistent and useful.

Finally, I have rewritten the theme - I originally ported the template from Wordpress to Jekyll, but it was a bit of a mess, responsivity was “hacked” in via JavaScript. Web development (and my skills) has come a long way since then, so I was able to leverage more modern CSS and HTML features to make the site look the same, but be more responsive and accessible.

Comments

When I switched from Wordpress to Jekyll, I was looking for a way to preserve comments. I found Isso, which is basically a small CGI server backed with SQLite that you can run on the server and embed it into your static website through JavaScript. It could also natively import comments from Wordpress, so that’s the main reason why I went with it, I think. Isso was not perfect (although the development has picked up again in the past few years) and it kept breaking for me. I think it haven’t worked for the past few years on my blog and I just couldn’t be bothered to fix it. So, I decided to ditch it in favor of another solution…

I wanted to keep the comments for old posts by generating them as static HTML from the Isso’s SQLite database, alas the database file was empty. Looks like I lost all comments at some point in 2022. It sucks, but I guess it’s not the end of the world. Due to the nature of how Isso worked, not even the Wayback Machine was able to archive the comments, so I guess they are lost forever…

For this new blog, I decided to use Carl’s approach with embedding replies to a Mastodon. I think it’s a neat idea and it’s probably the most reliable solution for comments on a static blog (that I don’t have to pay for, host myself or deal with privacy concerns or advertising).

I have some more ideas regarding the comments system, but that’s for another post ;-) Hopefully I’ll get to blog more often now that I have a shiny new blog!

Happy Holidays 🎄

Enjoy the holidays and see you in 2025 🥳!

In recent weeks we have been working on transferring LabPlot’s documentation to a new format.

We decided to move the documentation from the DocBook and MediaWiki format to the Sphinx/reStrcutredText framework. In our perception Sphinx offers a user-friendly and flexible way to create and manage documentation. Easy math typing and code formatting also come along. Additionally, Sphinx supports basic syntax checks, and modern documentation practices, such as versioning and integration with various output formats like HTML, PDF and ePub.

The new user’s manual is available on a dedicated page: https://docs.labplot.org. Please check it out and let us know what you think.

The manual still needs to be supplemented with new content, so we encourage you to contribute to the documentation, e.g. by fixing and adding new sections, updating images, as collaborative efforts can lead to a more comprehensive resource for everyone. Please check the Git repository dedicated to the documentation to find more details on how to help make it better.