Author Archives: Lorenzo Bettini

About Lorenzo Bettini

Lorenzo Bettini is an Associate Professor in Computer Science at the Dipartimento di Statistica, Informatica, Applicazioni "Giuseppe Parenti", Università di Firenze, Italy. Previously, he was a researcher in Computer Science at Dipartimento di Informatica, Università di Torino, Italy. He has a Masters Degree summa cum laude in Computer Science (Università di Firenze) and a PhD in "Logics and Theoretical Computer Science" (Università di Siena). His research interests cover design, theory, and the implementation of statically typed programming languages and Domain Specific Languages. He is also the author of about 90 research papers published in international conferences and international journals.

How I manage Neovim configuration with Chezmoi

I love to manage my dotfiles with Chezmoi, which I highly recommend! In a single Git repository, I have common dotfiles and Window Manager specific (KDE, GNOME, Hyprland, and Sway).

However, I prefer to have my Neovim configuration in another Git repository, separate from my Chezmoi dotfiles. I’ve just started learning Neovim, and I’m not yet 100% sure the configuration I use will be the ultimate one (I use Lazyvim); that’s why I want to keep them separate.

Chezmoi offers mechanisms for such situations: https://www.chezmoi.io/user-guide/include-files-from-elsewhere/. In particular, I use “Include a subdirectory from a git repository”: this way, Chezmoi will clone the external Git repository for my Neovim configuration on the first run and will keep it up to date (i.e., “git pull”) at some specified intervals (remember, the default interval is 0!).

You need to create the file “.chezmoiexternal.toml” in the root folder of your Chezmoi file and follow the syntax in the documentation.

For example, I want my “~/.config/nvim” directory (where Neovim configuration lives) to be populated (and kept up-to-date) with the contents of my GitHub repository “https://github.com/LorenzoBettini/starter” (as I said above, I’m using a fork of the Starter repository of Lazyvim):

Note that I specified a 1-hour refresh interval. Thus, if I issue a “chezmoi update,” it will keep that interval into consideration when deciding whether to check for updates (i.e., “pull”) in the Git repository. However, you also have this option in Chezmoi to force the Git update:

That’s all, and enjoy your dotfiles! 🙂

Installing EndeavourOS ARM on a PineBook Pro (August 2024)

I have already blogged about installing EndeavourOS ARM on a PineBook Pro (and previously, directly Arch ARM: the first article and the second article).

This blog post will describe the new procedure for installing EndeavourOS ARM on a PineBook Pro.

As usual, the instructions can be found here: https://endeavouros.com/endeavouros-arm-install/. Previously, there used to be three possible ways to install the system. Now, if we’re not considering the headless server installation, there’s only one way.

First, download the installation image (“.img.xz”) from the above page. For the PineBook Pro, I downloaded “enosLinuxARM-pbp-latest.img.xz“.

This image must be flashed on the final installation medium. I will install EndeavourOS ARM for PineBook Pro on an SD card in this blog post. The idea is that you then boot the PineBook Pro with such a flashed medium, and the installation procedure will finalize the installation on the same medium; during the textual installation, you specify a few configurations.

Of course, the flashing can be performed on any computer, not necessarily from the PineBook Pro.

The delicate part is ensuring you get the name of the flashing device properly or you wipe a device completely. You can use the command “sudo fdisk -l” to get the list of all the devices.

In my case, the inserted SD card is “/dev/sda“, so I flash the image as follows (again, BE COMPLETELY SURE of the correct device!!!):

Be patient; this will take a few minutes, especially depending on the speed of the SD card.

Then, it’s time to boot the PineBook Pro with the SD inserted.

I’m assuming you already have a boot program that allows you to select the booting device. For example, I have “Tow-Boot”.

At some point, I press ESC to select the booting device:

The textual installation starts.

Remember, it will install the system on the same device you used to boot.

Here are some required information:

Of course, you’ll also be asked for your username and password.

Then, you select the Desktop environment (or no desktop at all):

I selected KDE Plasma. Here’s the summary.

After a few minutes, you should get:

Time to reboot!

Unfortunately, at the first reboot, selecting SD to boot into the installed system brought a failure that no bootable image could be found. However, rebooting and selecting SD again succeeded.

IMPORTANT: as you noted, you have no choice about partitioning and filesystem type: you will get EXT4. To be honest, I never managed to setup BTRFS with the previous EndeavourOS installation anyway.

I could finally land on the newly installed KDE Plasma.

I’d suggest doing some configurations and tweaking, e.g., you need to configure swap since 4 gigabytes of RAM are too few! You could go for a swap file, but I’d recommend using zram as the primary swap.

Enjoy your EndeavourOS ARM installation 🙂

Eclipse in Hyprland 0.43

I hadn’t used Eclipse in Hyprland for a while. It used to work correctly; however, starting from somewhere in version 0.41, something broke, and it’s still broken in the current (at the time of writing) version 0.43.

When I execute Eclipse in Hyprland, i.e., in Wayland mode, the trees in Eclipse, e.g., Package Explorer (but also Project Explorer or the Outline) are displayed correctly until you start expanding the tree or hover with the mouse: the elements of the tree gets corrupted and disappear:

Till the whole tree disappears:

I reported the bug (https://github.com/hyprwm/Hyprland/issues/7829). The bug was closed because it had already been reported: in the beginning, the bug talked about DBeaver, which I didn’t know is an Eclipse-based application: https://github.com/hyprwm/Hyprland/issues/6844. The problem is associated with a previous hack to avoid flickering in the Qt application. Unfortunately, the hack breaks Eclipse-based applications, and it’s still there at the time of writing.

If I want to use Eclipse in Hyprland, I have to run it in X11 mode, i.e., by prefixing its execution with the corresponding environment variable set:

Since I have Hyprland with scaling enabled (1.5) Eclipse in X11 mode (Xwayland) gets pixelated:

To avoid that, as documented in Hyprland, I have to disable XWayland scaling by adding this section in “~/.confgi/hyprland/hypr.conf”:

Now, Eclipse runs in Xwayland without flickering but it’s unreadable to me (after all, it is not scaled):

We can scale it with the environment variable “GDK_SCALE”, but that does not support fractional scaling: set it to 2, and then Eclipse gets too big:

However, I can use another environment variable, “GDK_DPI_SCALE”, which scales text only (not icons; better than nothing!);

Here’s how I run Eclipse:

And here’s the result (readable and not too big):

Let’s hope the Hyprland problem gets fixed soon…

Sway: monitor configuration for different computers

I’m using Sway (not as my daily driver) on different computers: PCs and laptops.

For the PCs, I’m using an HDMI monitor. Laptops have different display sizes, e.g., small displays with low resolution and more extensive displays with retina resolution. Thus, I need to set different scaling factors for the different displays.

It’s pretty easy in Sway, and I’ll detail that here.

First, you need to get the information Sway uses to refer to your current monitor:

For example, on my LG GRAM 16, I get:

I want to scale at 1.6 on this computer. Otherwise, I can’t read almost anything.

In “~/.config/sway/config”, I specify scaling for this computer using the name shown above

Reload the configuration, and now scaling is correctly applied when using this laptop.

On the other laptops (e.g., my Acer Aspire Vero), I repeat the same procedure: get the identifier and add a specific configuration with the identifier; for example, for this other laptop, 1.25 scaling is enough:

For HDMI monitors, I want 1.5:

Summarizing, this is the monitor section in my Sway configuration, which automatically sets the desired scale factor according to the computer I’m using:

Of course, you can change many values for each monitor, including resolution and orientation, by specifying the corresponding identifier.

In my case, I only want to change the scaling factor.

Better KDE theming and styling in Hyprland

Recently, I blogged about using KDE applications in Hyprland. I also blogged about theming and styling them. However, I’m not very happy with that solution, so I’ll provide a possible alternative, which, in my opinion, is better. Some of the steps are similar to the ones in my previous post.

I assume you’ve already installed a few KDE applications, like Dolphin, Konsole, and Kate (see the blog post above).

As in all my Hyprland posts, this is based on Arch Linux; I mainly use EndeavourOS.

Let’s install a few packages:

The crucial ones are the “qt5ct” and “qt6ct-kde” packages. We’ll use the latter but also install the former for possible old Qt 5 applications, just in case. The “Hack” font is the standard KDE monospace font, and Kvantum is the theme engine. Finally, “breeze” will install the Breeze color schemes we will use in qt6ct.

IMPORTANT: we use the AUR package qt6ct-kde, which is a patched version of “qt6ct”. If you installed packages, as in my previous post on this subject, you’ll have to replace “qt6ct” when installing this AUR package.

Then, we have to set this environment variable in “~/.config/hypr/hyprland.conf” (note that we specify qt5ct, but for Qt 6 applications, qt6ct will be used automatically):

Let’s restart Hyprland (I’m assuming “env = QT_QPA_PLATFORM,wayland” is also set).

That’s the standard style of Dolphin, Kate, and Konsole with the default settings:

Let’s open the “Qt6 Settings” application (corresponding to “qt6ct”).

Remember that Qt6 settings will be stored in the file “~/.config/qt6ct/qt6ct.conf”.

First of all, I’m changing the fonts to match the standard ones of KDE:

Remember always to click “Apply” after changing something”.

By restarting the above applications, the fonts now look like in a standard KDE system:

Now, benefitting from the patched qt6ct package, differently from my previous post, we can select the “Breeze” style; similarly, we can select “Breeze Dark (KColorScheme)” in color:

Let’s see the results:

Super! Everything looks great with the above simple setting!

If you look at my previous post without the patched version of “qt6ct”, we had to select the “Breeze Dark” icon to have nice-looking icons in the dark style. Now, we didn’t have to!

Moreover, Kate also automatically uses the dark breeze theme (compare that with the previous post):

Note that you can tweak other settings in qt6ct further.

In particular, you can install other icon packages and select another icon set in qt6ct.

Of course, you could also directly use Kvantum themes, as we saw in my previous post. However, with the patched “qt6ct”, having a nice-looking and consistent theme for KDE applications is much easier.

Happy (better) theming! 🙂

Waybar Workspaces in Hyprland

Waybar has a dedicated module for Hyprland workspaces: https://github.com/Alexays/Waybar/wiki/Module:-Hyprland#workspaces. One of its most fantastic features is the possibility of representing the application windows in each workspace.

For example, here I have the workspaces with the following application windows:

  1. Kate (text editor) and terminal (Alacritty)
  2. Dolphin (file manager)
  3. A Firefox window and a Firefox window on GitHub
  4. A Firefox window on YouTube and Thunderbird (email client)

Here’s the Wyabar workspace representation (on the left):

Here I added Google Chrome in the workspace 2:

This is the Waybar module configuration, where the important thing is “{window}” in the “format”. Unfortunately, you must work on defining the rewrite rules and the icon to show as you want. Moreover, these are not icons; they are characters from Nerd fonts:

Probably, your browser will not render the fonts (though you can copy and paste them, and they will be taken correctly). I’m also showing a screenshot of my text editor where the Nerd fonts are rendered correctly:

Of course, you also have a character to be used by default if nothing matches (e.g., a question mark).

Nice feature, isn’t it? 🙂

Downgrading packages in Arch Linux Arm

In Arch Linux, you can easily downgrade packages with the script https://github.com/archlinux-downgrade/downgrade, also available from AUR.

I experienced problems with the new version (2:2.11.1) of wpa_supplicant in PineBook Pro, where I have EndeavourOS. WiFi does not work anymore with the new version of wpa_supplicant.

I tried downgrading as suggested in the EndeavourOS forum. However, I got this error:

That’s because, by default, the downgrade script uses this archive site https://archive.archlinux.org or the local cache (which I always clear). However, that archive is for the x86 architecture. You must use a corresponding archive for the arm architecture, like https://alaa.ad24.cz/, using the command line option:

So I ran (note that I also chose to add the package to “IgnorePkg” to avoid further future updates, at least until the bug is solved):

When running the command, you get the possible versions to downgrade to:

Reboot, and WiFi works again 🙂

Multibooting Fedora and Arch with GRUB

I have already blogged about multibooting several different Linux distributions with GRUB.

This post is a simplified and updated version of the previous post.

Moreover, I made it easier to test such configurations manually: install several Linux distributions in a single KVM virtual machine.

In this post, I’ll show how to configure GRUB (without os-prober, which doesn’t work well with different Linux distributions like Fedora and Arch) by delegating to other GRUB configurations (i.e., chain loading).

I’ll use Arch EndeavourOS (BTRFS) and Fedora. I’ll show the two possible solutions: EndeavourOS as the main GRUB delegating to Fedora and vice-versa.

First, we need to tweak both distributions’ GRUB configurations.

Preparing EndeavourOS

We must tweak the EndeavourOS GRUB UEFI entry. Otherwise, when trying to boot Fedora, you return to UEFI (this has been a known problem/choice for some time).

The easiest way is to remove the UEFI entry simply:

Or, if you want to keep a backup:

As a further alternative, if you want to keep the UEFI entry, you must remove the culprit call

As usual, you must run “grub-mkconfig”.

Preparing Fedora

It’s better to remove os-prober since, as I said above, it wouldn’t work for other Linux distributions, and it takes some time when updating GRUB: edit with sudo the file “/etc/default/grub” and ensure you have this line:

Also, ensure you have this line (if you use EndeavourOS as the principal GRUB, otherwise you will not see Fedora entries):

But then, you’ll have to update GRUB after you install a new kernel. (if you use Fedora as the principal GRUB, the above modification is unnecessary).

Then, run

Booting EndeavourOS from Fedora

Detect the partition of EndeavourOS, e.g., with “lsblk”. (remember that I’m testing this in a KVM virtual machine where I have installed both distributions; thus, partitions will start with “vd”; they are virtual disks).

EndeavourOS is in “vda3”.

Edit the file with sudo “/etc/grub.d/40_custom”

Add this entry (for more details on these entries, please see my old post):

By default, Fedora does not show the GRUB menu, which would break this post’s intent.

To show the grub menu, run:

Update GRUB:

Reboot the virtual machine configured to start with Fedora, and you’ll see the EndeavourOS entry to boot EndeavourOS (you will get to the EndeavourOS GRUB entries from the Fedora GRUB):

Booting Fedora from EndeavourOS

As done above, inspect the partitions:

Fedora is in “vda2”:

Edit with sudo “/etc/grub.d/40_custom” and add this entry:

Update GRUB:

Reboot the virtual machine to start with EndeavourOS, and you’ll see the Fedora entry to boot Fedora (you will get to the Fedora GRUB entries from the EndeavourOS GRUB):

Final notes

Fedora has its way of updating the system, which requires rebooting, installing updates, reboot again. This process doesn’t work well when Fedora is not the principal booting system; at least, it requires attention to manually select the Fedora entry a few times during this update/booting process. Thus, it’s better to keep Fedora as the principal booting system.

Problems with xdg-desktop-portal-kde as well

I recently blogged about some problems with UI tests in GNOME due to xdg-desktop-portal-gnome.

Unfortunately, I also started to experience problems similar to those with KDE Plasma 6.1 (Linux EndeavourOS and Arch); as in the other blog post, the problem is only with Wayland.

I’ll use this example project (taken from my TDD book): https://github.com/LorenzoBettini/demo-attsw. It is a simple Java Swing application where UI tests are written with AssertJ Swing. I run “mvn verify,” and most of the UI tests fail (when the AssertJ Swing bot tries to interact with the application window, it mostly gets the position wrong). This is the leading cause of the failure: I get this dialog popping up from KDE, “Remote control requested”, coming from “xdg-desktop-portal-kde“:

This shows up as soon as one of the UI tests starts.

First, I must click “Share” (of course, tests have already failed). Note that the dialog remembers the setting for the application you used to run the tests. For example, if you change the Java version to run the tests, you’ll get the dialog popping up again.

Starting the UI tests again still leads to failures. I have to change these system settings:

Now, UI tests finally succeed. Though, they tend to be quite flaky. I see that while they run, since they interact with the keyboard and mouse, other windows get focused, and some interactions are performed on the other windows, not one of the applications under test. Things improve if you only leave the application under test on the screen. It is even better to place the mouse in the part of the screen where the application under test usually appears.

In general, with such kinds of UI tests, it might be better to switch to X11… 🙁

A first look at Fedora 40 Sway

I started to look at the Window Manager Sway. Hopefully, in the future, I’ll post more articles on that.

In the meantime, I looked at the Fedora Sway spin (the current version is 40) and will briefly comment on that in this post.

The live environment already provides a Sway window manager and leaves documentation about how to start programs, especially the installer:

Let’s follow the suggestion and select the installer:

The installer is the usual Fedora one:

However, the next part is different from what I have always seen in a Fedora installation, at least the default Gnome one: you have more things to set:

I won’t show the other installation parts since they are standard in Fedora installation. I went with the defaults because I’m trying that in a virtual machine, so I’ll stick with the default partitioning scheme.

After the installation is concluded, let’s restart, and here’s the greeting login screen:

And once you log in:

No more help message: you’re on your own 😉

Probably, a basic knowledge of Sway is required and assumed.

At least, you may remember the SUPER + d shortcut to open the application launcher, and you can run something from there.

It’s better if you know about the basic shortcuts, which are the Sway default in this installation:

  • SUPER+SHIFT+Q: close the current window
  • SUPER+ENTER: run the default terminal, which here is “foot”
  • SUPER+SHIFT+C: reload Sway

The look and feel of the installed and configured Sway is nice; the “Waybar” is configured with a few helpful information. You have the tray icon (on the right) for network connections—the volume control opens a dialog to configure the volume and microphone. Moreover, media keys are already configured. For example, the ones for volume, and you have a visual feedback:

A few screenshot key bindings are also configured:

# Capture the currently active output
Print
# Capture the currently active window
Alt+Print
# Select and capture a custom rectangular area
Ctrl+Print

However, you have no visual feedback for such features; more effort could have been made.

Software-wise, you don’t have much installed: you have Thunar as a file manager but no text editor, for example.

The disappointing part is the configuration of Sway: you might expect you have everything already created in the “~/.config” subdirectories, following the standard Sway and other application structures. Unfortunately, it’s not like that: you have nothing in your home directory in that respect. Everything is configured system-wide. Of course, you can customize everything, but you must go through the documentation: https://docs.fedoraproject.org/en-US/fedora-sericea/configuration-guide/.

Several precedence rules are documented in the link, but I find that mechanism quite cumbersome. There are configuration files spread in many places:

You have to add additional files to your home folder or completely override a configuration file with one with the same name in your configuration folder.

I’ve just started experimenting with Sway; such a mechanism is hard to grasp and use.

For example, the installation procedure completely forgot the “Italian” layout I specified for the keyboard! There’s no “~/.config/swat/config” file to modify quickly. Should I copy the default one there and modify it; however, the part about the keyboard layout is not even commented on.

After reading the documentation, I came up with this (the configuration file’s name is my own; I haven’t followed a pattern; the important thing is the directory where the “.conf” file is):

Then, I reloaded Sway with SUPER+SHIFT+C and got the Italian keyboard layout.

But it wasn’t easy…

In general, I had the impression that Fedora Sway is not for beginners of Sway; however, it doesn’t seem to be for Sway experts either: they’d expect to customize Sway as they see fit anyway, and probably they have their dotfiles ready to be used.

However, maybe Fedora Sway is not bad for starting to experiment with Sway in the end. 🙂

Environment Variables in Sway

Setting environment variables in Hyprland is easy: just put them in its config file. Setting environment variables in Sway is a bit harder, and there seems to be some confusion. The documentation is unclear about that, at least in my humble opinion.

This blog post documents my way of setting environment variables in Sway.

Let’s install qt6ct for some experiments.

If we run it, we get the following problem:

Where can environment variables be specified when using Sway?

In my experiments, “~/.profile” is not loaded (either when logging in or using SDDM). Instead, “~/.bash_profile” and “~/.zshenv” should be used for BASH and ZSH, respectively.

So, in those files, source “~/.profile” explicitly

Let’s put the environment variable declaration and export into “~/.profile”

Exit Sway and get back in, and now qt6ct is happy:

If we want also to have our environment variables available to systemd, we can follow another strategy to specify environment variables in one place.

First of all, let’s create a file (or any, if you want to have several environment variables categorized in different files) that ends with “.conf” in the directory “~/.config/environment.d/”.

For example, I have “~/.config/environment.d/10-env.conf” (these files are read by systemd alphabetically); I move the environment variable definition in this file (so, I remove it from “~/.profile”):

Note that in this file, you only have to use the syntax “key=value” (to see the full syntax: https://www.freedesktop.org/software/systemd/man/latest/environment.d.html)

Each time you modify that directory, you have to run this command:

To verify that systemd read this file, run

And you should see the line:

If you restart Sway and run qt6ct, you will see that qt6ct complains again. The environment variable is only visible to the systemd. We have to export the variables read by systemd.

To avoid duplication, we can use the program “/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator”, which does precisely that (of course, it handles all the environment variables in the “.conf” files in the environment.d directory). In “~/.profile” we now put this line:

Restart Sway and run qt6ct, and now everything went back to work!

You can also open a terminal from Sway and verify the environment variable is there!

I hope you find this blog post helpful 🙂

Modifier-only shortcuts in KDE Plasma 6.1

Before KDE Plasma 6.1 (released a few days ago and already available in Arch), if you wanted to configure a “modifer-only” shortcut (e.g., SUPER key, also known as META, to activate the “Overview” effect), you had to manually modify the “~/.config/kwinrc” file and add these lines:

Another example is if you wanted the SUPER key to activate the “Present Windows” (AKA “Expose”) effect:

In Plasma 6.1, modifier-only shortcuts must not be specified in “~/.config/kwinrc”: they are in “~/.config/kglobalshortcutsrc” and, as such, can be visually specified through the standard KDE shortcut system settings:

By default, SUPER is configured to start the “Application Launcher” (this means that previous specifications in “ModifierOnlyShortcuts” in “~/.config/kwinrc” are not considered anymore).

If we want to assign it to “Overview”, we first search for current shortcuts for “Overview”:

Click on “Add custom shortcut” and press SUPER. You are notified about an existing binding for the “Meta” key:

And, of course, we choose to reassign it.

Done!

Thus, such a setting will be stored in “~/.config/kglobalshortcutsrc”:

Nice feature, though it breaks existing configurations, which need to be adapted 😉

KDE theming and styling in Hyprland

Recently, I blogged about using KDE applications in Hyprland.

But what about theming and styling them?

I’ll show how to do that in this blog post, assuming you’ve already installed a few KDE applications, like Dolphin, Konsole, and Kate (see the above-linked blog post).

WARNING: the strategy shown in this post is not optimal, in my humble opinion. There’s a more recent post where I show a better strategy (in my opinion).

As in all my Hyprland posts, this is based on Arch Linux; I mainly use EndeavourOS.

Let’s install a few packages:

The crucial ones are the “qt5ct” and “qt6ct” packages. We’ll use the latter but also install the former for possible old Qt 5 applications, just in case. The “Hack” font is the standard KDE monospace font, and Kvantum is the theme engine.

Then, we have to set this environment variable in “~/.config/hypr/hyprland.conf” (note that we specify qt5ct, but for Qt 6 applications, qt6ct will be used automatically):

Let’s restart Hyprland (I’m assuming “env = QT_QPA_PLATFORM,wayland” is also set).

That’s the standard style of Dolphin, Kate, and Konsole with the default settings:

Let’s open the “Qt6 Settings” application (corresponding to “qt6ct”).

Remember that Qt6 settings will be stored in the file “~/.config/qt6ct/qt6ct.conf”.

First of all, I’m changing the fonts to match the standard ones of KDE:

Remember always to click “Apply” after changing something”.

By restarting the above applications, the fonts now look like in a standard KDE system:

Let’s try to change the appearance colors to a darker setting in the palette:

Unfortunately, the result is a small disaster:

Dolphin is the only application that reacted to the change but in a wrong way.

Instead, let’s revert to the default palette and change the Style to Kvantum (“kvantum-dark”):

The result is improving:

However, it’s still ugly: the icons are mostly invisible, and the Konsole menu bar does not like this change.

Let’s fix the icons first: we select “Breeze Dark.” (Remember: We installed them at the beginning.)

The result has improved: icons are better visible, and in Dolphin, folder icons all look fine:

The rest of the ugly look is due to the default Kvantum theme.

So, from now on, we can try to select a Kvantum theme that makes the KDE applications look nice.

Let’s open Kvantum (“Kvantum Manager”) and try with another theme, e.g. “KvAdaptaDark”:

Now KDE applications look better:

Unfortunately, there’s a white bar in Konsole.

Moreover, Kate does not use the dark settings for the editor. However, Kate allows you to select a color scheme:

For example, by selecting “KvAdaptaDark” here as well, we get a nice-looking Kate:

Remember that Kvantum settings will be stored in the file “~/.config/Kvantum/kvantum.kvconfig”.

Now, you can experiment with other Kvantum themes.

For example, this is “KvArcDark”, which still has problems with Konsole menus:

Or “KvGnomeDark”, which doesn’t look bad after all (probably it’s the best up to now: we don’t even have the white bar in Konsole):

You can further tweak each Kvantum theme and change other settings in qt6ct.

In particular, you can install other icon packages and select another icon set in qt6ct.

Stay tuned for another post for styling Qt and KDE applications.

The new Xbase JvmGenericTypeValidator in Xtext

The new release of Xtext 2.35.0 comes with many new cool features. I personally worked on the introduction of the JvmGenericTypeValidator.

Quoting from the release notes:

Automatic validation for Xbase languages

The new JvmGenericTypeValidator was introduced to automatically perform several Java-related checks in the hierarchy of the inferred JvmGenericTypes of an Xbase language, with the corresponding error reporting.
For example, cycles in a hierarchy, extension of a final class, proper extension of an abstract class (do you implement all the abstract methods or declare the inferred class as abstract?), proper method overriding, etc. It also performs duplicate elements checks, like duplicate parameter names, duplicate fields and duplicate methods (keeping the type-erasure into consideration when using types with arguments).

This mechanism assumes that you implement the JvmModelInferrer “correctly”.
It only checks the first inferred JvmGenericType for the same DSL element (i.e., if for an element Entity you infer two JvmGenericTypes, t1 and t2, only the first one will be checked).
Moreover, it only checks Jvm model elements with an associated source element.
Concerning intended classes to extend and interfaces to extend/implement, it assumes the model inferrer uses the new JvmTypesBuilder#setSuperClass(JvmDeclaredType, JvmTypeReference) and JvmTypesBuilder#addSuperInterface(JvmDeclaredType, JvmTypeReference), respectively.

Currently, this validator must be enabled explicitly through the composedCheck in the MWE2 file or the @ComposedChecks annotation in the validator, e.g., @ComposedChecks(validators = JvmGenericTypeValidator.class).

The Domainmodel example now uses this validator.
The Xtend validator has been refactored to also use this validator.

This means that if you implement your model inferrer “correctly” and enable this validator, you get lots of valuable checks, which you would usually have to implement yourself (if you ever did that).

Let’s see that in action in the Domainmodel example (you can materialize that in your workspace through the Xtext wizard).

The example used in this tutorial can be found online at https://github.com/LorenzoBettini/jvm-generic-type-validator-example. Remember that if you clone the example from GitHub, you’ll have to run the MWE2 workflow after importing the projects.

As reported in the release notes, the Domainmodel validator already uses the JvmGenericTypeValidator:

Moreover, its model inferrer uses the above-mentioned API in JvmTypesBuilder for specifying the expected superclass, if present (note that setSuperClass is used here as an Xtend extension method and uses the syntactic sugar for setter):

Let’s start another Eclipse instance (in the GitHub project, you can use the launch “/org.eclipse.xtext.example.domainmodel.ui/Domainmodel Eclipse.launch”).

Let’s create an Eclipse plug-in project; in the MANIFEST, let’s add the Xbase lib as a dependency, and in the “src” folder, we create a file “Example.dmodel”, accepting to convert the project to an Xtext project.

Let’s start with a method with two parameters with the same name and see the reported error:

Let’s add two methods with the same name and a parameter but with the same type-erasure in the generic type:

Remember using setSuperClass to express that the extended class must be a class, not an interface? Let’s see that in action:

And don’t try to extend a final class 😉

Let’s see what happens if you try to extend an abstract class without defining all the abstract methods (remember that in the Domainmodel, all entities are mapped to concrete Java classes):

Of course, the error goes away if you implement the abstract methods:

Before going on, remember that implementing these validation checks manually is not trivial: you have to consider type-erasure and inherited methods. You get them for free thanks to the JvmGenericTypeValidator 🙂

Note that the error about missing implemented abstract methods, as the one above, contains information (i.e., in Xtext, “issue data”) about the missing methods, their types, and parameters. Thus, you could implement a quickfix to add the implementation methods automatically. This is not trivial, but it’s doable with the provided information. You might want to take inspiration from what Xtend does (remember that now Xtend uses the JvmGenericTypeValidator).

Let’s extend the Domainmodel a bit:

  • we add the optional “abstract” keyword for entities
  • we add the “implements” interfaces feature

These are the relevant parts in the modified grammar:

Let’s run MWE2 to regenerate the language, and let’s adapt the model inferrer accordingly (note the use of the new method JvmTypesBuilder.addSuperInterface; this method should also be used in the case your Xbase DSL has elements that are mapped to interfaces extending other interfaces):

Let’s restart the running Eclipse and see the new features in action, according to checks automatically performed by the JvmGenericTypeValidator.

For example, similarly to extended classes, we have the check for implemented interfaces:

Moreover, declaring a mapped Java class as abstract is taken into consideration: now we don’t have errors anymore with an abstract entity:

And, of course, mapped implemented interfaces are considered when checking whether a concrete class implements all the abstract methods:

Speaking of quickfixes, we can create a quickfix that intercepts the problem of a concrete entity missing implemented methods to turn the entity into an abstract one:

Let’s restart Eclipse and see the quickfix in action:

Unfortunately, as implemented, the semantic model quickfix leaves the resulting program text poorly formatted.

This version works fine, though it requires manual modification of the textual file:

Here’s the result after applying the quickfix:

Other features not shown in this blog post and not implemented by the Domainmodel example are related to declared thrown exceptions in operations. The JvmGenericTypeValidator will check that the thrown exceptions are correct in the case of overridden methods, according to the Java semantics.

Note that the JvmGenericTypeValidator can be customized if needed. For example, Xtend customizes it.

On a side note, while I took care of implementing and testing the JvmGenericTypeValidator and refactoring Xtend validation accordingly, most of the code extracted in JvmGenericTypeValidator comes from the original implementation in the XtendValidator made by Sebastian Zarnekow!

Happy validation-made-easy! 🙂

Customizing Grub during the EndeavourOS installation

I typically have several EndeavourOS installations on my computers: one for KDE, one for Hyprland, etc. Thus, I want to have different UEFI entries, but they would all have “endeavouros”, each overriding the others.

You can change the grub ID later by issuing a proper “grub-install” program from the running system or by booting it with the live ISO and then chrooting it.

Why not specify a different grub ID during the installation?

It’s easy to do so:

  • Once you boot the live ISO, before starting the installation, open a terminal (in the current version, the live environment is KDE, so you open Konsole);
  • Open the file “/etc/calamares/modules/bootloader.conf” with an editor (e.g., “sudo nano /etc/calamares/modules/bootloader.conf”; you need sudo but no password in the live environment);
  • Look for the line (near the end):

    and change it to a different string (e.g., “eos-kde” when you install KDE, “eos-gnome” when you install GNOME, etc.);
  • Save the file and go on with the installation as usual!

Now, each installation will have a separate and different grub id.

Fixing the empty “open with” in Dolphin in Hyprland

I have already blogged about KDE applications in Hyprland.

However, with the latest updates, things broke a bit especially with Dolphin, which does not recognize file associations anymore: double-clicking on a file always shows this empty menu, as if it could not find any associations for any file:

On the Arch forum that has already been reported and claimed as solved: https://bbs.archlinux.org/viewtopic.php?pid=2167442. However, the reported solution only temporarily solves the problem, at least in Hyprland.

The steps to solve the problem and make it permanent are the following:

Install this package:

Check that it works by running:

Now, if you run Dolphin you should be able to open the files again.

However, as soon as you install/update KDE packages, the problem shows up again. To solve this permanently, add this line in the file “~/.config/hypr/hyprland.conf”:

Exit Hyprland and get back in.

Now the problem should be solved for good! 🙂

Dual boot in a KVM Virtual Machine

If you want to experiment with multi-booting in Linux (for example, see this other post), you might want to consider experimenting with a virtual machine.

In this blog post, I’ll show you how to install two Linux distributions on the same KVM virtual machine.

I’ll use Fedora 40 and EndeavourOS Gemini. Make sure you download their ISOs.

Let’s create the virtual machine:

You need to specify enough space for the storage for two Linux distributions.

Of course, I’m going to use UEFI:

And 3d acceleration:

Let’s start the installation of Fedora:

I’m going to use manual partitioning, e.g., in Fedora, the only usable tool I can think of: Blivet-GUI:

I’m creating the partition for UEFI:

And the partition for the main system. Although I could choose the entire disk, and then resize it later when installing EndeavourOS, let’s make things simpler and only use half of the space of the VM’s disk:

We can continue the installation til the end.

Restart the virtual machine and finalize the Fedora installation.

Shut down the virtual machine.

You might want to create a snapshot in case you want to return to this step.

Now, we must configure the virtual machine to give precedence to the CD ROM as a boot device and “insert” in the CD drive the ISO of EndeavourOS Gemini (see my review).

Let’s edit its “Details” accordingly:

First, enable “SATA CDROM 1” and move it up in order:

Then, load the ISO in the SATA CDROM 1:

Let’s start the virtual machine, which will now boot from the EndeavourOS Live ISO:

Now, we can install EndeavourOS Gemini (see my review). The critical part are choosing GRUB:

And the partitioning: we must choose manual partitioning:

Now, we must mount the existing EFI partition (the one we created during the Fedora installation above) as “/boot/efi”

And allocate the rest of the free space to EndeavourOS (I choose BTRFS here); if you want to add another installation later, you might want to leave some free space.

Here’s the result:

You then get a warning about the EFI partition expected to be FAT32, while Fedora created it as FAT16, but you can ignore it: the installation will succeed anyway:

That’s the summary:

Let’s conclude the installation.

At the end of the installation, instead of “restart”, shut the machine down.

In fact, we have to “virtually” remove the CD ROM as the first boot media; otherwise, the virtual machine will always boot from the ISO (you can also remove the ISO from the virtual CD ROM). We basically revert the operations we performed before installing EndeavourOS:

Now, the EndeavourOS GRUB menu will appear instead of the Fedora one:

Let’s boot into it and make sure everything works.

Now, let’s reboot the virtual machine; this time, we select the “UEFI Firmware Settings” in the GRUB menu:

And we’re into the “Tiano” UEFI:

By selecting “Boot Manager”, we access the list of available UEFI entries:

We can select “Fedora”, now in the second position, and temporarily boot that.

Alternatively, we can change the boot order:

That’all! Now, you can experiment with multi-booting.

Happy “virtual” multi-booting! 😉

Disabling tracker-extract in Gnome 46

I like the tracker service in Gnome, which indexes files so that you can easily search for them from the Activity view or the file manager. However, I don’t like tracker-extract, which also indexes the file contents: I use Recoll for such a service, and tracker-extract uses too much CPU (it indexes new or modified files as you create/change them).

In the past, up to Gnome 45, I could disable tracker-extract only with

However, in Gnome 46, that service has gone, so tracker extract always runs, and I couldn’t find a way to disable it. I discovered it when I upgraded to Fedora 40 or EndeavourOS, which both provide Gnome 46. I bet it will be the same for Ubuntu 24.04.

Luckily, I found help on the Gnome discourse forum: https://discourse.gnome.org/t/can-tracker-extract-be-disabled-in-gnome-46/20782.

There’s no supported way to disable tracker-extract, but I was suggested to simply wipe the tracker-extract rules from “/usr/share/tracker3-miners/extract-rules/”.

For example,

If you want to keep a backup, you might want to move those files somewhere.

That works!

But be warned: as soon as tracker-extract is updated to a new version, those files will show up again, and you’ll have to remove them again. Possibly, before logging into Gnome, to avoid that tracker-extract starts eating your CPU.

In the meantime, I also created this issue for Gnome: https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/342.

Getting started with Rust with Visual Studio Code

I started learning Rust, and I found Visual Studio Code an excellent IDE for experimenting with Rust (in the future, I’ll also evaluate my beloved Eclipse).

I thought I’d share this experience.

Assuming you have already installed Rust, let’s create a project

Open Visual Studio Code in the “hello” directory

We get syntax highlighting for the Rust source but nothing more:

Let’s install the “Rust Extension Pack”, which includes several Rust-related plugins:

Returning to our Rust project, we can see that the “target” folder has been created with compiled binaries, thanks to the installed extension:

Moreover, we now have the code lens to run our Rust program in the Rust editor. And we also have hovering (and, of course, code completion!):

Moreover, we also get live validation in the editor with possible error markers and quickfixes when available.

Let’s run our Rust program and see the output (after compilation) in the Console:

Let’s try to debug it, and we get a message telling us to install another extension:

Let’s go with CodeLLB:

And here we are: I set a breakpoint, and the debugger correctly stopped there:

Happy learning and coding with Rust! 😉

EndeavourOS Gemini

I haven’t blogged about the EndeavourOS installation for a while.

Let’s have a look at the new EndeavourOS Gemini. I’m going to install it into a KVM virtual machine.

The installer now features KDE Plasma instead of Xfce as in the past (and the Arm installer has been removed, unfortunately):

As usual, I update the mirrors through the Welcome app; note that you also have the partition manager if you want to partition in advance. I’ll use the partition program during the installation.

Let’s start the installer; I choose “Online” because I want to install GNOME:

The installer is still the good Calamares:

In that respect, nothing has changed since the last time I used that. It has been a bit polished and uses the KDE dark theme. The following steps are as usual:

As I said, I’ll go for GNOME:

Then, you can refine the package selection; note that for GNOME, there are a few small customizations implemented by EndeavourOS, but if you scroll down, you can also go for a Vanilla GNOME:

By default, the most interesting applications are already selected:

As for the boot loader, the default is systemd-boot, but I prefer the good ol’ grub:

Since I’m testing this in a virtual machine, I’ll have the partitioner erase the whole disk, but you can always opt for manual partitioning:

Time to insert the user information, a quick recap, and then the installation starts with the usual slide show:

And we’re done: ready to reboot into the installed system:

Here’s the installed system:

Remember that GNOME defaults to Wayland (it’s been like that for a few years now):

Now that we’re in the installed system, thanks to the automatically installed spice agent, I can scale the virtual machine:

(I had to install Neofetch; I remember that it was automatically installed in the past.) We have GNOME 46.1 (at the time of writing):

“Gnome Tweaks” has already been installed, so a few aspects of GNOME can be easily customized.

Firefox is there, but as in the past, you must install Thunderbird (same for LibreOffice).

Concerning the theme, EndeavourOS uses “Qogir” for the cursor and icons, which look very nice.

Note that the tracker3-miners package is not installed by default, so “Search Locations” is disabled:

I use Tracker often, and it might be a bit confusing not to install this component by default. On the other hand, if not configured correctly, Tracker becomes a resource hog, so EndeavourOS’ choice might be a good one.

As usual, EndeavourOS proved to be an awesome Arch Linux experience! Very well done!

Now it’s time to run my Ansible playbook to install and configure Gnome 🙂