Monthly Archives: October 2024

Hyprland EndeavourOS on a PineBook Pro

After installing EndeavourOS on a PineBook Pro, I tried to use Hyprland on this PineBook Pro.

Since I have already blogged about Hyprland a lot, I want to report that Hyprland runs smoothly on this PineBook Pro. I basically reused all my ricing and customizations that I blogged about in my previous posts about Hyprland.

Here are a few screenshots:

That’s all! As I said, this was meant to be a brief report. 🙂

Sway in Arch Linux: getting started

I’m starting a new blog series about Sway, a Wayland Tiling Window Manager (the Wayland version of i3). Though I’ve already blogged about Sway, this post (and a few future ones) are intended as “getting started tutorials”.

I’ll focus on Sway in Arch, in particular, EndeavourOS.

Let’s start by installing EndeavourOS with no graphical environment installed:

Once the installation is finished, let’s log in to a terminal session since we have no Desktop Environment.

Let’s install the main package:

The output shows:

We see some suggestions for packages.

The package “polkit” has already been installed (see above), so we should be fine.

Let’s also install “foot” to be able to open a terminal with the default configuration and also “wmenu” and “dmenu” (see the output above about these programs):

Now, we can start “sway” from the command line.

There’s not much with the default configuration: just the workspace indicator (top-left) and the date and time (top-right), not even a wallpaper (we’ll deal with that in a minute).

We can start a terminal (“foot”) with SUPER+ENTER.

To start an application with the application launcher (by default wmenu/dmenu), for example, “firefox” (if installed) we use SUPER+D and start typing in the prompt appearing in the top left corner; a few letters should be enough til you get to the desired program (and press ENTER to launch it).

Of course, the windows are tiled:

NOTE: the SUPER (i.e., the “Window key”) is the default “mod” modifier for keybindings, but you can change it to something else if you want (e.g., “Alt”).

We can switch workspaces with SUPER+<workspace number>, start other terminals there:

We can focus windows with SUPER+<arrow keys> and move a window to another workspace with SUPER+SHIFT+<workspace number>—and close windows with SUPER+SHIFT+Q.

To move the current window and change its position in the tiling, use SUPER+SHIFT+<arrow keys> (instead of arrow keys, you can also use the H, J, K, and L as in Vim):

Let’s install the package “swaybg” (see the output above; that’s the “Wallpaper tool for sway”):

Now, let’s reload sway with SUPER+SHIFT+C and…

We have the wallpaper!

It’s time to start customizing the configuration.

Let’s create the directory for the configuration file and start from the default one:

Now, we can edit the “~/.config/sway/config” file. (note that the file ends with “include /etc/sway/config.d/*”, which properly sets a few environment variables and makes them available to systemd).

The first thing I will customize is the keyboard layout: I have an Italian keyboard, so I have to specify that (the default is an American layout). I’ll add this section somewhere in the config file (e.g., near the comments about other input configurations):

This will give me an Italian layout by default, and I can switch to an American layout by pressing the right CTRL.

Save the file, reload with SUPER+SHIFT+C, and experiment with the keyboard layouts.

Let’s change the application launcher, which is not very useful in its current shape. Let’s use the Wayland version of Rofi.

Then, let’s open the Sway config file and change the setting of the $menu as follows:

Reload Sway and now pressing the SUPRT+D will get us a much nicer application launcher (just start typing to filter the entries):

Let’s install a file manager, like Nemo.

Then, we can create a shortcut for opening the file manager; let’s open the Sway config file, define a variable for the file manager (it will make it easier in the future to switch to another file manager, for example) and a key binding, e.g., SUPER+SHIFT+ENTER:

Moreover, I prefer Alacritty as a program for terminal:

Then, we just have to change the “$term” definition in the Sway config file: change the line “set $term foot” to

Now, we need an Authentication Agent, which pops up a window asking you for a password whenever an app wants to elevate its privileges. I prefer the KDE one:

And start it when Sway starts; so in the Sway configuration file:

Since this is “exec”, not “exec_always”, you need to restart Sway, not simply reload it.

Now, if we run from a terminal a “systemctl” command that needs superuser privileges, we get the pop-up dialog asking for a password:

The configuration file already contains a commented section for locking and screensaver:

So, let’s install the involved programs (also mentioned above when we installed Sway):

Uncomment the “exec” command; remember that we need to restart Sway to have that mechanism in action. (Of course, you have to wait for 300 seconds). I’m not covering customization of the lock screen and the like here.

We can also set a key binding to lock the screen manually. I usually use SUPER+L; note that this is already bound as a combination to move on the left window (remember the Vim keybindings above?); so, first, I have to uncomment the corresponding bindings (I uncomment them all because I’m not using them: I prefer arrow keys) and add mine:

Let’s install some of the optional packages suggested above when installing Sway (in particular, the “xorg-xwayland” will allow us to run also X applications):

That’s all for this first tutorial part; stay tuned for more to come 🙂

Java, Maven and Gitpod, part 3: Configuring Java

This is the 3rd post about using Java in Gitpod.

It assumes you have already read the first and second posts.

On the bottom, we can see that there are two warnings on our project; let’s click the icon and see them in the “Problems” tab:

Since this is not a Java project managed by Visual Studio Code but a Maven project, we must fix the warning in the POM.

Let’s assume we want to update our project to use the Java version installed in the Gitpod workspace: Java 11 (we can tell that from the warning, but we could also run “java -version” from a terminal to verify that). We open the POM file and update the corresponding properties of Java 1.7: we change “1.7” to “11”:

As soon as we modify the POM, we get a pop-up: the Java LSP detects a change in the project configuration and offers to synchronize the classpath and rebuild the project. Of course, we accept. We accept that, and after a few seconds, the warnings go away.

Note that our choice leads to creating the settings file for this option. We can choose to rebuild the project automatically (“Always”), and the settings file will be updated accordingly. Of course, it makes sense to store such a file in the Git repository.

We can now create a commit with our changes and push them to GitHub.

Remember that the JSON editor is aware of the corresponding schema, so we can enjoy code completion for the string value:

Let’s now say we want to use Java 17 for our project. The workspace provides Java 11, so we must also have Java 17 installed in the Gitpod workspace.

Let’s modify the POM for Java 17 and rebuild the project. Let’s try to run the main file. The Java application still runs, as we can see from the terminal:

Gitpod workspace uses SDKMAN to provide a few versions of tools like the JDK and uses the version required by the project (in this example, Java 17).

We can list the installed JDK in the terminal (and the current one):

If we wanted to go for Java 21, we should install that version with SDKMAN, but we wouldn’t want to do that manually each time we open a Gitpod workspace. Moreover, instead of the “Zulu” distribution, we might use the “Temurin” distribution.

The recommended way is to provide a custom Dockerfile for our Gitpod workspace to have full explicit control over the versions of the tools we use; this will be part of the Git repository and live with the code.

So we create in the root of our project the file “.gitpod.Dockerfile,” and we configure SDKMAN for the version of Java we want to install and set as the current (the available versions can be discovered with “sdk list java”):

Then, we refer to this Dockerfile in the “.gitpod.yml”:

As before, we can let Gitpod validate our configuration and start a new workspace with the rebuilt Docker image.

As shown in my previous post on Gitpod, you might want to start from a smaller base image with only the needed tools like Java. That would decrease the time to build the custom Docker image. That is out of the scope of this post.

However, rebuilding the Docker image will be done the first time you start a workspace, and the custom image will be cached.

On the new workspace, we can verify that we are using the Java version we installed and set as default:

Again, we commit our changes (including the new custom Dockerfile) and push them to GitHub.

One could use the same strategy for installing a specific version of Maven through SDKMAN. Maven is also installed in the workspace through SDKMAN.

I want to conclude that this process seems long. Still, once you get familiar with the configuration of Gitpod for Java/Maven projects, for new repositories of the same kind, it is enough to immediately put in the Git repository the “.gitpod.yml” and the “.gitpod.Dockerfile.” You can immediately start coding with Gitpod! 🙂

Remember, though, that the first time, you will still have to wait for the build of your custom Docker image.

Stay tuned for the fourth part.

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! 🙂