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:
1
sudo pacman-Stlp tlp-rdw
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:
1
2
3
4
5
6
7
+++ Battery Care
Plugin: lg
Supported features: charge threshold
Driver usage:
* vendor (lg_laptop) = active (charge threshold)
Parameter value range:
* STOP_CHARGE_THRESH_BAT0: 80(on), 100(off) -- battery care limit
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):
1
2
START_CHARGE_THRESH_BAT0=75
STOP_CHARGE_THRESH_BAT0=80
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).
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:
1
sudo pacman-S--needed git base-devel
And then
1
2
3
4
5
mkdir -p ~/git
cd ~/git
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si
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:
1
yay-Stouchegg
You will get this warning, but proceed anyway: it compiles and works fine:
1
2
3
4
:: (1/1) Parsing SRCINFO: touchegg
-> The following packages are not compatible with your architecture:
touchegg
:: Try to build them anyway? [Y/n]
I customize touchegg touchpad gestures for KDE by creating the file “~/.config/touchegg/touchegg.conf” with the following contents:
XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
<touchégg>
<settings>
<!--
Delay, in milliseconds, since the gesture starts before the animation is displayed.
Default: 150ms if this property is not set.
Example: Use the MAXIMIZE_RESTORE_WINDOW action. You will notice that no animation is
displayed if you complete the action quick enough. This property configures that time.
-->
<property name="animation_delay">150</property>
<!--
Percentage of the gesture to be completed to apply the action. Set to 0 to execute actions unconditionally.
Default: 20% if this property is not set.
Example: Use the MAXIMIZE_RESTORE_WINDOW action. You will notice that, even if the
animation is displayed, the action is not executed if you did not move your fingers far
enough. This property configures the percentage of the gesture that must be reached to
<!-- Change KP_Right to KP_Left if you prefer the other direction -->
<gesture type="SWIPE"fingers="4"direction="LEFT">
<action type="SEND_KEYS">
<repeat>false</repeat>
<modifiers>Alt_L</modifiers>
<keys>KP_Right</keys>
<on>begin</on>
</action>
</gesture>
<gesture type="PINCH"fingers="4"direction="IN">
<action type="SEND_KEYS">
<repeat>true</repeat>
<modifiers>Control_L</modifiers>
<keys>Shift_L+Tab</keys>
<decreaseKeys>Shift_L+Tab</decreaseKeys>
<on>begin</on>
</action>
</gesture>
<gesture type="PINCH"fingers="4"direction="OUT">
<action type="SEND_KEYS">
<repeat>true</repeat>
<modifiers>Control_L</modifiers>
<keys>Tab</keys>
<decreaseKeys>Shift_L+Tab</decreaseKeys>
<on>begin</on>
</action>
</gesture>
</application>
</touchégg>
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
1
touchegg
And then let’s enable it so that it automatically starts on the subsequent boots:
1
sudo systemctl enable touchegg.service
Let’s move on to ZSH, which I prefer as a shell:
1
sudo pacman-Szsh
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”):
1
sudo pacman-Spowerline-fonts fzf curl
Let’s install “Oh My Zsh” by running the following command as documented on its website:
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:
1
curl-sS https://starship.rs/install.sh | sh
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:
1
eval"$(starship init zsh)"
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):
1
2
3
4
5
sudo pacman-Splocate
sudo systemctl enable plocate-updatedb.timer
sudo updatedb
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:
1
sudo pacman-Syakuake
I run it once (it’s enabled by default by pressing “F12”), and it will start automatically upon logging in.
TL; DR: Xtext sources are now in a single Git monorepo (https://github.com/eclipse/xtext), and the build infrastructure is based entirely on Maven/Tycho (Gradle is not used anymore).
Background
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:
once the core project was built successfully, archive its artifacts (p2 repository and Maven artifacts) in Jenkins (JIRO in Eclipse)
trigger downstream jobs, making sure to use the archived artifacts corresponding to the branch with the changes
wait for all downstream jobs to finish
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! 🙂
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
