Monthly Archives: February 2024

Hyprland and KDE Applications

Updated on 8 March 2024 (for Plasma 6)

Updated on 30 May 2024 (for Dolphin’s “Open With” empty menu)

This is another post of the Hyprland series.

I am a big fan of KDE applications for many everyday tasks. Since Hyprland is not a full desktop environment, you can choose which applications to install for text editing, images, viewers, file managers, etc.

When I started using Hyprland, I was installing Thunar as a file manager; then I switched to Nemo because it’s more powerful, then to Nautilus (but it doesn’t look right in Hyprland). Finally, I decided to use Dolphin since I already used several KDE applications in Hyprland.

This is the list of Arch packages I install in Hyprland

  • kate (for text editing)
  • gwenview (for quick image editing)
  • konsole (as a terminal, though I still use also Alacritty)
  • breeze-icons (to have nice icons in KDE application)
  • kvantum (for Kate color schemes)
  • okular (for a better PDF viewer and annotator)
  • kcalc (as a calculator)
  • dolphin (for a powerful file manager)
  • dolphin-plugins (e.g., for Dropbox folder overlay)
  • ark (for Archive management, including Dolphin context menus)

Note that some of the above applications (namely, Dolphin and Gweenview) have “baloo” (the KDE file indexer and searcher) as a dependency. In Hyprland, that’s pretty useless and since it takes some resources for indexing, it’s better to disable that for good right after installing the above packages:

 

Some updates after the original post:

UPDATE (8 March): After the update to KDE Plasma 6, the name of the baloo command has changed:

UPDATE (30 May): Dolphin cannot seem to open files anymore because it doesn’t see any association. Its “Open With” menu is also empty. I blogged about the solution.

 

Let’s look at a few features of KDE applications that I like.

Concerning Dolphin, it has several powerful features, too many to list here πŸ˜‰ I mention better renaming for multiple files out of the box. This feature requires additional work for Thunar or Nemo, and I never like the final result.

Let’s see the enabling of the Dropbox plugin (see the installed “dolphin-plugins” above):

After restarting Dolphin, you’ll get the nice overlay on the “Dropbox” folder:

Another reason I like KDE applications is that they have built-in HUD (Head Up Display), that is, a global searchable menu: use the keyboard shortcut Ctrl + Alt + i and you get the menu: start typing to quickly reach the intended item (in this example, I quickly switch to a custom Konsole profile):

You may want to create or change the keybinding for the file manager, in my case it is:

Moreover, you’ll have to update the “~/.config/mimeapps.list” file accordingly, that is, specify this line and replace the corresponding existing ones:

Concerning theming, some applications like Kate allow you to choose the color scheme. For example, since we installed Kvantum, we can choose the color scheme in Kate with “Settings” -> “Window Color Scheme”.

Konsole has profiles that you can create and customize.

On the other hand, Dolphin has no such functionality, so we should theme all KDE/Qt applications. That’s the subject of another possible future post.

Enjoy your KDE applications on Hyprland as well! πŸ™‚

Running Maven from Java: the Maven Embedder

This is probably the beginning of a series of articles about testing Maven plugins.

I’ll start with the Maven Embedder, which allows you to run an embedded Maven from a Java program. Note that we’re not simply running a locally installed Maven binary from a Java program; we run Maven taken from a Java library. So, we’re not forking any process.

Whether this is useful or not for your integration tests is your decision πŸ˜‰

The source code of the example used in this tutorial can be found here: https://github.com/LorenzoBettini/maven-embedder-example/

I like to use the Maven Embedder when using the Maven Verifier Component (described in another blog post). Since it’s not trivial to get the dependencies to run the Maven Embedder properly, I decided to write this tutorial, where I’ll show a basic Java class running the Maven Embedder and a few JUnit tests that use this Java class to build (with the embedded Maven) a test Maven project.

This is the website of the Maven Embedder and its description:

https://maven.apache.org/ref/3.9.6/maven-embedder/

Maven embeddable component, with CLI and logging support.

Remember: this post will NOT describe integration testing for Maven plugins; however, getting to know the Maven Embedder in a simpler context was helpful for me.

Let’s create a simple Java Maven project with the quickstart archetype

Let’s change the Java version in the POM to Java 17, use a more recent version of JUnit, and add another test dependency we’ll use later:

Let’s import the Maven Java project into Eclipse (assuming you have m2e installed in Eclipse).

Let’s add the dependencies for the Maven Embedder:

Getting all the needed dependencies right for the Maven Embedder is not trivial due to the dynamic nature of Maven components and dependency injection. The requirements are properly documented above.

Let’s replace the “App.java” inside “src/main/java/” with this Java class:

That’s just a simple example of using the Maven Embedder. We rely on its “doMain” method that takes the arguments to pass to the embedded Maven, the base directory from where we want to launch the embedded Maven, and the standard output/error where Maven will log all its information. In a more advanced scenario, we could store the logging in a file instead of the console by passing the proper “PrintStream” streams acting on files.

Let’s create the folder “src/test/resources” (it will be used by default as a source folder in Eclipse); this is where we’ll store the test Maven project to build with the Maven Embedder.

Inside that folder, let’s create another Maven project (remember, this will be used only for testing purposes: we’ll use the Maven Embedder to build that project from a JUnit test):

We rely on the fact that the contents of “src/test/resources” are automatically copied recursively into the “target/test-classes” folder. Eclipse and m2e will take care of such a copy; during the Maven build, there’s a dedicated phase (coming before the phase “test”) that performs the copy: “process-test-resources”.

Let’s replace the “AppTest.java” inside “src/test/java/” with this JUnit class:

The first test is simpler: it runs the embedded Maven with the goals “clean” and “verify” on the test project we created above. The second one is more oriented to a proper integration test since it also passes the standard system property to tell Maven to use another local repository (not the default one “~/.m2/repository”). In such a test, we use a temporary local repository inside the target folder and always wipe its contents before the test. This way, Maven will always start with an empty local repository and download everything from scratch for building the test project in this test. On the contrary, the first test, when running the embedded Maven, will use the same local repository of your user.

The first test will be faster but will add Maven artifacts to your local Maven repository. This might be bad if you run the “install” phase on the test project because the test project artifacts will be uselessly stored in your local Maven repository.

The second test will be slower since it will always download dependencies and plugins from scratch. However, it will be completely isolated, which is good for tests and makes it more reproducible.

Note that we are not running Maven on the test project stored in “src/test/reources” to avoid cluttering the test project with generated Maven artifacts: we build the test project copied in the “target/test-classes”.

In both cases, we expect success (as usual, a 0 return value means success).

In a more realistic integration test, we should also verify the presence of some generated artifacts, like the JAR and the executed tests. However, this is easier with the Maven Verifier Component, which I’ll describe in another post.

IMPORTANT: if you run these tests from Eclipse and they fail because the Embedded Maven cannot find the test project to build, run “Project -> Clean” so that Eclipse will force the copying of the test project from “src/test/resources” to “target/test-classes” directory, where the tests expect the test project. Such a copy should happen automatically, but sometimes Eclipse goes out of sync and removes the copied test resources.

If you run such tests, you’ll see the logging of the embedded Maven on the console while it builds the test project. For example, something like that (the log is actually full of additional information like the Java class of the current goal; I replaced such noise with “…” in the shown log below):

REMEMBER: this is not the output of the main project’s build; it is the embedded Maven running the build from our JUnit test on the test project.

Note that the two tests will build the same test project. In a more realistic integration test scenario, each test should build a different test project.

If you only run the second test after it finishes, you can inspect the “target/test-classes” to see the results of the build (note the “local-repo” containing all the downloaded dependencies and plugins for the test project and the generated artifacts, including test results, for the test project):

Now, you can continue experimenting with the Maven Embedder.

In the next articles, we’ll see how to use the Maven Embedder when running Maven integration tests (typically, for integration tests of Maven plugins), e.g., together with the Maven Verifier Component.

Stay tuned πŸ™‚

Hyprland and wlogout

This is another post on the Hyprland series.

In a previous post, I showed how to create a custom button in the Waybar for wlogout: a wlogout is a logout menu for Wayland environments:

Remember that in Arch, this is available as an AUR package, e.g., you have to install it through an AUR helper like Yay:

Of course, you can also test it by running that from the command line.

However, I hadn’t realized that when I click logout in wlogout, I always get a black screen: I don’t return to the SDDM menu.

However, that’s easy to fix, and you can also take the chance to customize its aspect.

First, you have to create its configuration layout file, e.g., by starting from the default one:

Then, we can edit the layout file we copied into “~/.config/wlogout/layout” and change this section

into

Now, logout will work fine.

Let’s also configure “Swaylock” for screen locking, as I have already shown in this previous blog post.

If you still haven’t installed that:

The default screen locking uses a bright screen. Let’s make it darker:

And let’s create and edit its configuration file “~/.config/swaylock/config”; in this example, I’m going to make it “dark green”, so I’m specifying:

By looking at its “man page”, we can see:

-c, –color <rrggbb[aa]>
Turn the screen into the given color instead of white. If -i is used, this sets the background of the image to the given color. Defaults to white (FFFFFF).

The “aa” in the previously present hex notation is the alpha value defining the color’s opacity. In the above example, I’m using no opacity.

This is my complete configuration file for swaylock:

Again, the “man page” explains these values:

-F, –show-failed-attempts
Show the current count of failed authentication attempts.

-f, –daemonize
Detach from the controlling terminal after locking.

In my Hyprland configuration file, I also use “swayidle” (the Idle management daemon for Wayland)

In my waybar configuration, I have:

Note that I’ve used a character using the installed Nerd font. Of course, you can choose anything you like. The β€œwlogout” menu will appear when you click on that module.

That’s all for this post πŸ™‚