Monthly Archives: June 2023

TLP: Limiting Battery Charge on LG Gram in Linux

I had already blogged on how to limit battery charge on LG Gram in Linux. In that post, you had to manually set the threshold “80” in the file “/sys/devices/platform/lg-laptop/battery_care_limit”.

With TLP, the procedure is easier and more automatic.

First, you must install tlp (remember that tlp conflicts with power-profiles-daemon, so you have to disable the latter first or uninstall it). In Arch-based distros:

Ensure that the tlp service is enabled on boot and the first time you should start it (“sudo systemctl start tlp”).

By running “sudo tlp-stat”, you should see near the end this line:

Edit the file “/etc/tlp.conf” and uncomment the following lines (note there’s one also for the start of charging, but that option doesn’t seem to be supported in this laptop):

Restart the service (“sudo systemctl restart tlp.service”), and it should be already active (run “tlp-stat” again):

That’s all. This will persist on reboot. However, this will not persist if you hibernate and return from hibernation (unless you restart the tlp service as shown above).

Customizing KDE in Arch Linux on a PineBook Pro

In a previous blog post (and another one), I showed how to install Arch Linux on a PineBook Pro.

In this blog post, I’m showing how I customize KDE on that installation (thus, it is similar to this other one for GNOME).

I’m not using Wayland because I still don’t find it usable in Plasma. Indeed, I haven’t even installed the Wayland session: I’m using X11.

First of all, the default screen resolution of KDE is too tiny for my eyes. Thus, I set 150% (fractional) scaling:

After that, you have to log out and log in to see the setting in effect.

I also enable “Tap-to-click” in the “Touchpad” settings.

Then, I set “Ctrl+Alt+T” as a shortcut for opening the terminal (Konsole). Actually, the shortcut is already configured in the “Custom Shortcuts”, but it’s not enabled by default in this distribution. It’s just a matter of selecting the corresponding checkbox (the “Examples” checkbox must be selected first to enable the other checkbox):

Then, I install an AUR helper. I like “yay,” so I first installed the needed dependencies:

And then

I install, by using “yay”, the “touchegg” program for touchpad gestures. (Plasma Wayland already provides touchpad gestures, but I prefer to use the X11 session, as I said above). For ARM, we need to install the AUR package:

You will get this warning, but proceed anyway: it compiles and works fine:

I customize touchegg touchpad gestures for KDE by creating the file “~/.config/touchegg/touchegg.conf” with the following contents:

In particular, note the 3-finger gestures (for the “Expose” effect, hide all windows, switch workspace, etc.).

Let’s start “touchegg” and verify that gestures work

And then let’s enable it so that it automatically starts on the subsequent boots:

Let’s move on to ZSH, which I prefer as a shell:

Since I’m going to install “Oh My Zsh” and other Zsh plugins, I install these fonts (remember from the previous post that I had already installed “noto-fonts” and “noto-fonts-emoji”) and finder tool (“curl” is required for the installation of “Oh My Zsh”):

Let’s install “Oh My Zsh” by running the following command as documented on its website:

When asked, I agreed to change my default shell to Zsh. In the end, we should see the prompt changed to the default one of “Oh My Zsh”:

I then install some external plugins:

And I enable them by editing the ~/.zshrc, in particular, the “plugins” line (I also enable other plugins that are part of the OMZ distribution):

Once saved, you have to start a new terminal with zsh to see the plugins in action (remember that, until you log out and log in, the default shell is still BASH, so you might have to run “zsh” manually to switch to ZSH in the currently logged session).

Besides the syntax highlighting for commands, you have completion after “cd” (press TAB), excellent command history (with Ctrl+R), suggestions, etc.

Let’s switch to the “Starship” prompt. Let’s run the documented installation program:

Now, let’s edit the ~/.zshrc file again; we comment the line starting with “ZSH_THEME,” and we add to the end of the file:

Opening another ZSH shell, we should see the fantastic Starship prompt in action, e.g.,

To quickly search for file names from the command line, I install “locate”, enable its periodic indexing and run the indexing once the first time (if you’re on a BTRFS file system, you might want to have a look at this older post of mine):

Then, you should be able to look for files with the command “locate” quickly.

Gnome uses “Baloo” for file indexing and searching, e.g., from “KRunner” (Alt+Space) or the application launcher (Alt+F1 or simply Meta). I like it, and it quickly keeps the index up to date. However, by default, baloo also indexes the file contents, which uses too many resources, so I disable the content indexing feature. I blogged about configuring baloo in another post.

Speaking about KRunner, I find it extremely slow on this laptop; especially the first time you run it, it might take a few seconds to show up. I often use it to search for files or programs, and I need such a mechanism to be fast. I found that the application launcher is instead fast to start (Meta key). However, when you start typing to search, the results are all mixed: applications, files, and settings are all together, and it might not be easy to find what you need:

For this reason, I right-click on the KDE icon and select the “Alternative” “Application Menu”:

This launcher has a valuable feature to categorize the search results. For example, with the exact search string as above, I get results clearly separated:

I also use the “yakuake” drop-down terminal a lot:

I run it once (it’s enabled by default by pressing “F12”), and it will start automatically upon logging in.

That’s all! I hope you enjoyed this post. 🙂

You might also look at my other posts on this PineBook Pro laptop.

Xtext, monorepo and Maven/Tycho

TL; DR: Xtext sources are now in a single Git monorepo (, and the build infrastructure is based entirely on Maven/Tycho (Gradle is not used anymore).


A few years ago, Xtext sources were split into 6 separate GitHub repositories. I did not take part in that decision (I guess at that time, I wasn’t even a committer).

I think that at that time, the splitting was carefully thought out, aiming at making contributions and maintenance easier. In fact, while Xtext is mainly based on Eclipse, it has several core parts that are independent of Eclipse (including LSP support and plain Maven/Gradle projects support, without the Eclipse UI).

Those core parts were built with Gradle. I’m not a fan of Gradle: I’ve always found Gradle gives you too much power as a build tool, not to mention that, typically, the build breaks with new releases of Gradle. On the contrary, Maven has been around for several years and is rock solid. It’s rigid, so you have to obey its rules. But if you do, everything works.
Moreover, its files (POM) and build infrastructures always look the same in Maven projects, so you know where to look when you deal with a Maven project. For Eclipse projects, Tycho complements Maven. Tycho is not perfect, but everything works if you stick with its rules.

The rigidness of Maven/Tycho usually forces you to keep the build simple. And that’s good! 🙂

Of course, also previously, the Eclipse projects of Xtext had to be built with Maven/Tycho. Thus, the build of Xtext was split into 6 repositories with a mixture of Gradle builds and Maven/Tycho builds.

As a result, Xtext was a nightmare to build and maintain. That’s my opinion, of course, but if you read Xtext GitHub issues, PRs, and discussions, you see I wasn’t the only one to say that.

For example, the main problem was that if you changed something in one of the core projects (i.e., on its Git repository), you had to make sure that all the other projects did not break:

  1. once the core project was built successfully, archive its artifacts (p2 repository and Maven artifacts) in Jenkins (JIRO in Eclipse)
  2. trigger downstream jobs, making sure to use the archived artifacts corresponding to the branch with the changes
  3. wait for all downstream jobs to finish
  4. if anything breaks, go back from the beginning and start again!

Moreover, while it was easy to parametrize the Maven and Gradle files to use the archived Maven artifacts, it was a bit harder to use the archived p2 repositories in the target platforms of the Eclipse downstream projects. Typically, you had to temporarily modify and commit the target platform files to refer to the archived p2 repositories corresponding to the current feature branch. Before merging, you must remember to revert the changes to the target platform files.

In the end, the code in the single Git repositories was actually coupled, so the splitting in single Git repositories has always sounded wrong to me.

The release process used to be complex as well. Again, that was due to Git repository splitting and a mixture of Maven/Gradle builds.

A big change

I had always wanted to bring Xtext sources back into a single Git repository and to use Maven/Tycho only. I told the project lead Christian Dietrich about that many times, but he was always reluctant due to the time and effort it would have taken. On January 2023, I finally managed to convince him to give me a chance 🙂

I first started porting all single repositories to Maven/Tycho, removing the Gradle build.

Things were not so easy, but not even impossible. A few tests were failing in the new build infrastructure, but Christian and Sebastian Zarnekow helped me to bring everything to a working situation. We also took the chance to fix a few things in that respect.

In this stage, I also took the chance to set up the CI building also on GitHub Actions (our primary CI is, of course, Eclipse Jenkins “JIRO”).

Then, I moved to the repo merging. This part was easy. I had prepared the single Git repositories thinking about repository merging, so fixing the foreseen merge conflicts was just a matter of adjusting a few things in only a few files (mainly the parent POM).

Finally, I simplified the release infrastructure a lot. We used to have a vast Jenkinsfile for the release, with many complex operations based on Git cloning all the repositories, tagging, and tons of shell operations.

Now, the whole release is carried on during the Maven build (as it should be, in my opinion), including the uploading to the Eclipse web directories. The Jenkinsfile is very small.

The Oomph setup has been simplified as well. It takes time to have a development workspace, but that is due to dependency resolutions and the first Eclipse build. It takes place automatically.

Now, the complete Maven/Tycho build of Xtext, which consists of compilation and running all the tests (almost 40k tests!), takes about 1 hour and a half on Linux (Jenkins and GitHub Actions) and about 2 hours on macOS in GitHub Actions. It takes much less than before when you had to wait for the builds of the single Git repositories and downstream projects. The building of some single Git repositories was, of course, faster, but the overall time for building all the Git repositories was much more significant in the end.

Final thoughts

I hope this vast change improves the maintainability of the project. It should also help contributions from the community. Maybe I’m biased, but personally, I find working and contributing to Xtext much better now, as it used to be in the old days 😉

To me, the effort was very worthwhile!

In the end, it didn’t take long. Of course, I do not measure in months passed from the start of the porting (I started in the first days of January, and the first release with the new infrastructure, version 2.31.0, was at the end of May, though the first milestone with the new infrastructure was at the beginning of April). The time I spent working on that was much less. Of course, I hadn’t worked on that full-time: I did that in my spare time 🙂

In my humble opinion: If your project’s infrastructure and build are too complex, don’t change the build tools: change the latter and keep it simple. 😉 A single big Git monorepo is easier to deal with than 6 small Git repositories, especially when the single Git repositories contain code meant to belong together.

Many thanks to Christian and Sebastian for letting me work on this restructuring and promptly helping me during the process! 🙂