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.
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
Things have changed again in Gnome 47 (fortunately, they haven’t changed again in Gnome 48) because the directory is now named “/usr/share/localsearch3/extract-rules/“. Thus, the removal must be done like this:
1
sudo rm/usr/share/localsearch3/extract-rules/*
If you want to keep a backup, you might want to move those files somewhere.
This is the script I’m using:
it works also in Gnome 46 (with the old directory name)
echo"localsearch3 does not exist, continuing...")&&
sudochown-R${USER}:${USER}~/tmp/extract-rules
That works!
WARNING: as soon as tracker-extract is updated to a new version, those files will show up again, and you’ll have to remove them. Possibly, before logging into Gnome, to avoid that tracker-extract starts eating your CPU.
I like it a lot! Everything seems much more readable.
See, for example, Nautilus (I’m using a different icon theme, but the font is the default one):
Also, the monospace version of Adwaita looks nice:
To better see the difference, here’s a screenshot with the old fonts:
And here’s one with the new Adwaita fonts:
Besides other new features you might find in many articles, I also appreciate that the default image viewer now provides some basic editing features (note the toolbar icon):
At least, the editing operation I use most, “cropping”, is there. Changing the size is not yet possible. That’s why I also use Gwenview in GNOME.
I immediately tried that in one of my Java projects.
Use the “Market Place” to install Copilot in Eclipse:
Once you click install, you must “trust” the contents to be installed:
Once installed and restarted Eclipse, you must authenticate with your GitHub Copilot account by clicking on the Copilot icon in the bottom right:
This will open a dialog with a code you must insert in the opened web page. Note the button to automatically copy the code in the clipboard and open the browser:
In the browser, you’ll have to authenticate in your GitHub account and paste that code (which should be in the clipboard). If everything goes fine, the webpage will tell you that everything is in place to start using Copilot in Eclipse, and Eclipse should show the corresponding success dialog:
I started to do some experiments.
I have this test code where Eclipse shows a warning on the “FileOutputStream” because the resource is not closed. Of course, I know how to solve that: use a try-with-resource block. But let’s ask Copilot.
I opened the file and the Copilot chat (still using the button in the bottom right toolbar):
Here’s what I asked:
I experienced a possible UX design problem here: I didn’t see any answer. I had to enlarge the view to see where Copilot wrote the answer (note in the same part where I wrote the question):
The answer is wrong: that is not the cause of the warning, and that is not the solution.
I tried to be more explicit in the question, detailing the message of the warning:
OK, this time, the answer is correct!
I tried to use the toolbar button to insert the solution in the editor:
However, instead of replacing the interested part, it just inserted that code starting from the editor’s cursor: a disaster of course 😉
Instead of manually copying and pasting the solution, I experimented with Copilot code completion. As I said, I know that I must use a try-with-resource. I converted the lambda expression into a block and typed “try (“. The grey code is suggested by Copilot:
I don’t know whether this is due to the selected solution in the chat or to my previous question, but the proposed code is correct! Press TAB to accept that. Then, I manually removed the duplicate original line. Maybe the original line has been used to propose the correct completion.
For the other part in the same file with the same warning, the completion was done in two steps: I started typing as before, accepted the initial partial condition, went on typing some more, and got the rest of the correct completion:
I also tried asking how to move the Maven project to Java 21 by opening the POM and using the chat:
The answer is correct, but honestly, the question was relatively trivial 😉
Unfortunately, Copilot code completion in the POM file does not work well: it tends to interfere with the default content assist in the POM; I haven’t found a way to use that properly.
Other valid key bindings:
Ctrl + Alt + / to manually trigger Copilot’s code completion;
Ctrl + Right to accept the next word in a suggestion.
Let’s see for future updates 🙂
In the meantime, I’ll try to experiment with that further.
I have always liked Amarok, the (initially) default KDE media player. It’s very feature-rich, nothing compared to Elisa. Moreover, it has two crucial features that I haven’t found in any other players:
it saves statistics (play count and stars) directly into the music file
Once flatpak is configured correctly on your distribution, you just need to run:
1
flatpak install flathub org.kde.amarok
Quoting from previous posts on Amarok, it’s also best to install Flatseal for configuring the flatpak application permission:
1
flatpak install com.github.tchx84.Flatseal
Let’s start Flatseal and check the Amarok permissions. Some settings are already configured to allow Amarok access to a few standard directories and databases. In my case, I also configure the access to all my files and a mount point because I have my music stored on an external drive, which I mount at that mount point “/media/bettini/backuplinux”):
You can now start Amarok either from the Gnome menu or from the command like:
1
flatpak run org.kde.amarok
IMPORTANT: The flatpak version of Amarok stores its files in
1
2
~/.var/app/org.kde.amarok/config
~/.var/app/org.kde.amarok/data/amarok
instead of the standard directories “.config” and “.local”.
If you want to connect your IPOD, first you must ensure that the “libgpod” package is installed, and then you have to add the permission access in Flatseal to the mount point of your IPOD. Otherwise, Amarok will detect your iPod but as a non-initialized one because it cannot access its contents:
If the Flatseal permissions are set correctly, you can enjoy your Amarok iPod!
The installation is smooth and easy to follow, based on standard dialogs:
I’m selecting “Clean Install” here because I’m testing it on a virtual machine.
There’s also the chance to encrypt the drive, but I’m not trying that.
The installation process is fast, and it only takes a few minutes.
It’s time to restart the installed system.
It’s a nice-looking DE, clearly inspired by GNOME, with a nice dock.
There are also a few beautiful wallpapers, all related to the space.
Generally, the DE is very responsive and smooth, though there are still graphical glitches now and then. Remember, it’s still in the alpha stage.
The DE comes with a few typical applications, like a terminal, a file manager, and a text editor; from what I understand, they’ve all been written from scratch. Although these applications look neat and clean, they don’t seem feature-complete yet, at least comparing them to Gnome or, even better, KDE-corresponding applications.
The file manager automatically changes the size of the icons when resizing its window.
However, there’s no way to have a tree view.
The terminal allows for some theme customizations, like custom profiles and also the beautiful transparency effect (by the way, note the style of application settings in Cosmic applications):
The above screenshot also shows the installer’s default partition layout.
However, currently, the terminal only allows you to either “Select All” or the text visible on the screen: while selecting, scrolling does not work.
Then, we have the application launcher that also looks clean and neat:
The launcher that appears with SUPER is very helpful. Note that by default, it shows the windows that are currently opened so you can quickly select one of them, e.g., by starting typing or by using the arrow keys:
Press “?” for more options:
The “File Search” looks interesting: I seem to understand that it relies on the standard “find” (or maybe “fd”) to show directories and files inside of them (see the found text file), though I haven’t tried that with actual directories full of tons of files.
The Google search also looks interesting:
The software center, with the “updates” functionality, looks fine:
Let’s now come to the well-known Pop OS “tiling” features:
The tiling features are nice. Also, the shortcuts make navigating and moving tiled windows very easy. During the moving, you also get nice effects.
In the “Settings” application, you can tweak many settings.
The “Appearance” setting, besides the standard “light” or “dark” mode, also allows you to change the accent color (I switched to green).
You also have additional appearance and theming settings, including icons.
By the way, I love the thick and colored border indicating the focused window. Of course, you can remove it if you don’t like it. I find it nice-looking and useful for easily spotting which window you’re working on.
Speaking of settings, Cosmic adopts a textual file approach, which I greatly like. Configuration files of applications or parts of the desktop can all be found in subdirectories of “~/.config/cosmic”.
For example, this is the file with the terminal opacity:
And this is the accent color of the dark theme:
This makes it very easy to manage your dotfiles in Cosmic. It is much easier than Gnome, with settings stored in the “dconf” database, and KDE, with its configuration files spread around in “~/.config” with names you always have to guess.
Of course, you can customize the shortcuts:
Finally, you have fractional scaling if you want:
To conclude this first look at Cosmic, considering it’s still in the alpha stage, I was very impressed by its responsiveness, cleanness, and beauty.
However, if I had to use it as a daily driver, I’d probably use other applications for tasks like file explorer, terminal, and text editor.
The end of this part is still the branch “fourth-blog-post”.
Currently, we cannot run/debug anything, i.e., not even tests. We need the “nvim-dap” (debugger adapter), which is optional in the LazyVim Java extra (see the documentation, https://www.lazyvim.org/extras/lang/java). If the “nvim-dap” is installed, the LazyVim Java extra automatically configures the corresponding mechanisms for Java. Instead of installing the single plugin, we use another extra: https://www.lazyvim.org/extras/dap/core, which also installs other dap-related goodies, including the UI. We install the extra in one of the documented ways. As done before, I’m using the “:LazyExtras” UI, searching for “dap.core” and installing it. Of course, then we need to restart Neovim.
When you enable this extra, Mason must install additional packages: “java-test” and “java-debugger-adapter”. They are installed automatically (but you have to wait for their installation the first time you start Neovim; as usual, you can check the installation status using the Mason UI, “:Mason”).
Running
These plugins are configured so that the Java LSP can detect Java files with the “main” method. Let’s open such a file (in this example, “Main.java”). To start the application (in debug mode, though in this first run, we haven’t set any breakpoint), the command to search for is “Run/Continue” (not “Run with args”). In fact, “continue” is meant to continue a program under debugging that has stopped due to a breakpoint. Still, it is ALSO meant to start a program if there’s no program under debugging (that’s the documented behavior of DAP). Such commands can be accessed as submenus with “<leader> d” (“d” is for “debug”):
Let’s start this program with “c”.
In the dialog that appears, we select the “Launch” configuration (remember that you can type to fuzzy select):
This example contains a single Java file with a “main” method. If, in your program, you have several Java files with the “main” method, the LSP will detect them all and, upon launching, will show a picker to select the one you want to run.
The program doesn’t do anything interesting besides creating an object, calling a few methods, and logging something on the console. It terminates quickly, so you might see a few additional windows (the UI changes) for a second and then return to the source code. The UI that quickly appeared and disappeared is the “Dap UI”. As shown in the menus above, you can manually toggle it back with “<leader> d u” (as usual, I change the color scheme so that some parts of the UI are more evident):
For the moment, since we did not do any debugging, the only interesting window is the one at the bottom-right, showing the console with the output of the program we have just run.
Running with arguments
Let’s use “Run with Args,” which allows us to pass command line arguments to the Java application.
This application does not do anything with the passed arguments. Let’s change the “main” to print the arguments on the console. For example, adding this line at the beginning:
Java
1
System.out.println(Arrays.toString(args));
Select “<leader> d a”, and specify a few arguments:
We’ll see “[first, second, third]” in the console.
Custom launch configurations
Besides the automatically detected Java files with a “main” method, the LSP is configured to support VSCode launch configurations, which, by default, are searched for in the file at the root of the project “.vscode/launch.json”. The options for such files are similar to the ones found here: https://code.visualstudio.com/docs/java/java-debugging#_configuration-options, though the accepted JSON is not strictly the same, and some options might be different. The specific format accepted by Dap is documented in the Dap documentation (e.g., online at https://github.com/mfussenegger/nvim-dap/blob/master/doc/dap.txt or using the “:help dap-api”).
TIP: it might be a good moment to install the LazyVim JSON extra, as we have already seen before.
If you create in the root of the Java project the file “.vscode/launch.json”, i.e., “:e .vscode/launch.json”, the file is created with some initial contents:
For this example, I’m creating two additional launch configurations for passing some fixed arguments to the main file and another one that prompts the command line to pass:
Note that since these launch configurations do not specify the Java class with the main (see the corresponding option if you want to do that), they work correctly only when your buffer contains a Java file with “main”.
Let’s open the “Main.java” file and try to run the program with “<leader> d c”: we get this selection dialog to choose the configuration (where the first two are as before, and the other ones are taken from the “launch.json” above):
If you select the configuration with the prompt, you get another pop-up dialog where you can insert the command line arguments. The dialog is pre-filled with the default value specified above, “foobar”:
That’s all for this post.
In the next post, we’ll learn how to debug a Java program from Neovim.
I haven’t blogged about the EndeavourOS installation for a while.
Let’s have a look at the new EndeavourOS Mercury. I will install it with KDE Plasma into my LG Gram 16.
The installer has been featuring KDE Plasma instead of Xfce for a while:
Unfortunately, the screen isn’t automatically scaled, so it’s a bit too small. I could change the scaling, but I’ll leave it like that. As shown later, the first time I log into the installed KDE Plasma Wayland session, KDE will automatically scale the display to a comfortable size.
As usual, I must connect to the Internet and add my Italian keyboard layout. If you know KDE, it’s easy with its system settings:
Now that I’m connected let’s start the online installer:
And I also take the chance to update the mirrors (which the documentation says will now be part of the installed system):
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”, and I choose “Online” as the method.
The default language proposed is Italian, which was detected correctly. However, I have always preferred English OS installations, so I changed it.
The location is detected correctly, and I keep the proposed settings for numbers and dates:
I have to change the keyboard layout to Italian:
As I anticipated, I’ll install KDE Plasma:
You can review the packages to install; these are the defaults:
As I usually do, I also install LTS kernel in addition (you never know) and Printing packages:
As for the boot loader, the default is systemd-boot, but I prefer the good ol’ grub:
For partitioning, you have lots of choices:
In this computer, I already have a few Linux installations, so I want to do a manual partitioning:
The crucial thing is to specify the current UEFI partition so that the new entry will go into the existing one. I select it and press “Edit”. I only must specify the “/boot/efi” mount point:
Let’s create the primary partition using the “Free Space”: select it and press “Create”. I specify 100 GB, the BTRFS filesystem, the point point “/” and a label:
One of the helpful features of this installer is that you can also specify the position of the partition: in this case, I choose to have the partition at the end of the free space by dragging the partition to the end:
Here’s the result:
I have two SSDs with a few partitions I want to be mounted on this installation. Thus, I select the other SSD:
I “Edit” the involved partitions with my preferred mount points:
I’m done with partitioning, and in the following window, I specify my user’s details.
Finally, here’s the recap:
Let’s start the “Install”.
Remember that during the slide show, you can toggle the logging (the button on the left of the percentage):
By the way, did you see the first slide about contributing? I’ve just contributed because I love EndeavourOS 🙂 You might want to contribute as well if you like this distro!
In about a few minutes (this computer is powerful), the installation finished without problems. Time to restart!
Rebooting says that a job is still running for “User Manager”, but hitting “Ctrl+Alt+Del” a few times forced the reboot.
Let’s log into the installed system (remember, the default is Wayland):
As anticipated, KDE automatically set the scaling to 125%, which could be fine for this laptop:
I changed it to 150% to have a more readable screen.
The Plasma theme is the “Breeze Dark EndeavourOS”, which is dark with a purple accent:
Installing Nerd Fonts is easy in Arch Linux: they are in the official repositories. That’s not true for Ubuntu and Fedora. Of course, installing them in these distributions is also not complicated. Still, it is a manual procedure: download the font archive, extract it in a specific directory, and regenerate the font cache.
We can benefit from automatic formatting. First, select (from F1) the command “View: Toggle Render Whitespaces”. We can see that the Maven archetype generated Java source code with spaces for indentation:
I prefer tab characters for indentation. If we select “Format Document” (by searching with F1 or by the shortcut “Strl+Shift+I”), the formatter changes the style of curly brackets in the “main” method, but it retains the current indentation characters.
Let’s configure the Java formatted for tab indentation characters. By pressing F1, we access the global search. Let’s start typing “formatter”:
We chose the second one (with “Preview”). We get a notification about a missing formatter profile:
Of course, we accept to create one. This will create a “java-formatter.xml” file in the “.vscode” directory so that our formatting profile will be part of the Git repository. It will also open a visual editor:
We select the “tab” “indentation policy” and uncheck “Detected indentation from file content” (otherwise, the formatter will still use the current indentation character from the current file). Note that the preview will show tab characters now:
Once the file for the formatted profile is saved (and we’ll commit that to the Git repository), we can try formatting our Java source code again, and this time, we get tab indentation characters (you might want to explore the other formatted settings):
If we try to format the “pom-xml”, we get an error saying there is no formatter for XML files; the pop-up offers to install one, and we get a list of available XML formatters. Let’s choose the Red Hat one:
Unfortunately, this formatter does not provide a visual editor for its settings; the customization is documented, but it requires a manual modification of the “.vscode/settings.json” (code completion is still available anyway). For example, to have tab characters (of size 4), I put this section:
1
2
3
4
5
6
"[xml]": {
"editor.defaultFormatter": "redhat.vscode-xml",
"editor.tabSize": 4,
"editor.insertSpaces": false,
"editor.detectIndentation": false
},
When selecting “Format Document”, indentation spaces are turned into tab characters.
If we’re happy with this extension, we can follow the usual procedure to store it in “.gitpod.yml” (e.g., with the gear icon of the extension page).
In Neovim, when you add a new word to your spellchecking dictionary with the command “zg”, the word will be added to a “.add” file in your config directory in the subdirectory “spell”. For example, “spell/en.utf-8.add”, depending on your locale. That’s a textual file you might want to share among different machines, e.g., part of the Git repository hosting your Neovim configuration. However, the used file is “.add.spl”, e.g., “spell/en.utf-8.add.spl”. That’s a binary file you don’t want to store in the Git repository, so you typically add it to “.gitignore”.
The “.spl” file is automatically updated (through the Neovim command “mkspell”) when you add a word with “zg”. But what if you modify the “.add” file from outside Neovim? For example, when you pull the Git repository of the Neovim configuration changes on another machine. You’d have to remember to run the “mkspell” inside Neovime (more details can be found here https://neovim.io/doc/user/spell.html).
Let’s instead make everything automatic by adding an “autocmd”, e.g., in LazyVim, by adding this to the “lua/config/autocmds.lua” file:
Lua
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
-- Ensure that the binary spl file is up-to-date with the source add file
vim.api.nvim_create_autocmd("FocusGained",{
pattern="*",
callback=function()
localconfig_path=vim.fn.stdpath("config")-- Get Neovim's config path
Ubuntu has forced the installation of Firefox and Thunderbird as snap packages for some time. I don’t like snap packages since they’re a bit slower to start, take much more space on the disk, and store the profile files into the “.snap” directory folder, while I want them in the standard place in my home folder. The procedure to revert to the traditional deb installation (through the Mozilla PPA) is well documented but takes several steps, especially to avoid the unintended update to the snap version during the Ubuntu update process.
In this blog post, I’ll document my Ansible tasks to make the whole procedure automatic. This is part of my Ansible playbook for Ubuntu.
These are the main tasks:
YAML
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
---
- name: Check whether snap is installed and on system path
command: 'which snap'
register: snap_installed
ignore_errors: yes
changed_when: false
- name: Remove Firefox and Thunderbird Snaps
become: true
ansible.builtin.snap:
state: absent
name:
-firefox
-thunderbird
when: snap_installed.rc == 0
- name: Copy Mozilla apt key
# The apt_key file is expected to be found on the remote host
The check for snap being installed is required when the playbook is tested with Molecule using a Docker container (the Docker image of Ubuntu does not have snap and the corresponding installed packages).
Then, we remove the snap packages (if “snap” is installed, as said above). Note the use of the “ansible.builtin.snap” module.
I prefer to store the public keys for PPA as part of the Ansible playbook so that I don’t depend on the PGP servers, which tend to be slow and make the Molecule tests flaky. To download the public key locally, I use the link under “Signing key” on the PPA web page:
I add the key and the repository with the corresponding Ansible modules “apt_key” and “apt_repository”.
Note that I then perform a check for the existence of the preference file for the Ubuntu update process, “/etc/apt/preferences.d/mozillateamppa”. I’ll create the file later. If the file does not exist, I assume that this is the first time these Ansible tasks are executed. In that case, I’ll also remove the transitional deb packages for Firefox and Thunderbird, which Ubuntu has in its main repository, which would then force the installation of the corresponding snap packages. Removing such transitional deb packages is crucial, or the real deb packages we want from the Mozilla PPA will not be installed.
Such a preference file is then copied into the final position by using the template file of the playbook, stored in “tasks/files/mozilla/mozillateamppa.txt”:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Package:thunderbird*
Pin:releaseo=LP-PPA-mozillateam
Pin-Priority:1001
Package:thunderbird*
Pin:releaseo=Ubuntu
Pin-Priority:-1
Package:firefox*
Pin:releaseo=LP-PPA-mozillateam
Pin-Priority:1001
Package:firefox*
Pin:releaseo=Ubuntu
Pin-Priority:-1
Then, we install the deb packages from the Mozilla PPA (note the “update_cache: true”: we added a new PPA, so we must update the apt cache).
Finally, we copy another file to ensure that the versions installed from the Mozilla PPA will take precedence during Ubuntu unattended-upgrades. The template file stored in the playbook “tasks/files/mozilla/51unattended-upgrades-mozilla.txt” is:
The end of this part is still the branch “third-blog-post”.
In the first part, we saw how to enable Java LSP in the LazyVim distribution. We also saw a few interesting features for programming in Java in Neovim with such a configuration. In the second part, we saw a few of the IDE mechanisms we get from the Java LSP in LazyVim.
Let’s continue where we left off (remember, I’ll use the above-mentioned Maven project) and see how to deal with Maven dependencies.
Adding support for the pom.xml
By default, opening the pom.xml file gives only syntax highlighting but no LSP support:
We can install the XML LSP, “lemminx”, using Mason, e.g., by modifying the “extend-lsp.lua” file we saw above:
Lua
1
2
3
4
5
6
7
8
9
return{
"williamboman/mason.nvim",
opts={
ensure_installed={
"jdtls",
"lemminx",
},
},
}
Restart Neovim and open the “pom.xml” file again. Wait some time for Mason to install the LSP, and the first thing you might notice is the status line showing the structure of the current XML element:
The XML LSP is schema-aware so that it can provide hovering support (“K”):
It also provides the symbol mechanisms shown above. It provides auto-closing of tags and rename refactoring. Moreover, it can validate what you write according to the schema (in this case, it checks that it is a valid Maven XML).
It also implements a “code action” for quick-fixing it:
Some other notes
If you add a dependency to the POM or change one of the existing dependencies version, you must run “:JdtUpdateConfig” so the Java LSP can download the new dependencies.
In general, when something is not working, “:JdtRestart” might fix things.
In case of misalignments of the workspace, e.g., if you wipe the local Maven cache (“~/.m2/repository”) when restarting an already opened project, you get errors due to unresolved dependencies:
In such a case, you can run “:JdtWipeDataAndRestart”, which wipes the Eclipse workspace (not your project) and restart the LSP, which will resolve the Maven dependencies from scratch.
That’s all for this part!
Note that for the moment, we cannot start/debug a Java program from Neovim. We’ll cover that in the next part.
We still have to cover:
how to run/debug Java programs (with the current configuration, this is not yet possible);
When using Ansible and Molecule with Fedora 41, a few things must be adjusted so that Molecule can access the Docker image for Fedora 41.
This is probably due to some changes in the Python package and the new Dnf 5 package; if you use a default Docker Fedora 41 image, you get errors of the shape during the Molecule run:
1
"msg": "Could not import the libdnf5 python module using /usr/bin/python3.13 (3.13.1 ... [GCC 14.2.1 20240912 (Red Hat 14.2.1-3)]). Please install python3-libdnf5 package or ensure you have specified the correct ansible_python_interpreter. (attempted ['/usr/libexec/platform-python', '/usr/bin/python3', '/usr/bin/python'])"
To solve the problem, you must ensure that the packages “python3” and “python3-libdnf5” are installed in the Docker container used by Molecule during testing.
You can achieve that either by providing a custom Dockerfile for Molecule:
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
---
dependency:
name: galaxy
driver:
name: docker
lint: |
set-e
yamllint.
ansible-lint
platforms:
- name: fedora-gnome-instance
image: custom-fedora-default-ansible
dockerfile: ./Dockerfile
command: ""
privileged: true
build_image: true
...
and this is an example of a Dockerfile:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
FROM fedora:41
LABEL maintainer="Lorenzo Bettini"
ENV container docker
ENV LC_ALL C
ENV DEBIAN_FRONTEND noninteractive
RUN dnf -y update && dnf clean all
RUN dnf makecache \
&& dnf -y install \
python3-pip \
unzip \
sudo \
which \
python3-dnf \
python3-libdnf5 \
&& dnf clean all
...
Alternatively, you can specify the pre-built Docker Fedora 41 in the Molecule file:
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
---
dependency:
name: galaxy
driver:
name: docker
lint: |
set-e
yamllint.
ansible-lint
platforms:
- name: instance-fedora
image: fedora:41
pre_build_image: true
provisioner:
name: ansible
playbooks:
prepare: prepare.yml
...
And provide a “prepare.yml” file to install the above-mentioned required packages:
If you use the Homebrew package manager in macOS and you have macOS 12 because your Mac is too old to update to a new version of macOS, you can say goodbye to Homebrew: if you try to update your brew packages, you get such a message:
1
2
3
4
5
6
7
8
9
10
11
Warning: You are using macOS 12.
We (and Apple) do not provide support for this old version.
It is expected behaviour that some formulae will fail to build in this old version.
It is expected behaviour that Homebrew will be buggy and slow.
Do not create any issues about this on Homebrew's GitHub repositories.
Do not create any issues even if you think this message is unrelated.
Any opened issues will be immediately closed without response.
Do not ask for help from Homebrew or its maintainers on social media.
You may ask for help in Homebrew's discussions but are unlikely to receive a response.
Try to figure out the problem yourself and submit a fix as a pull request.
We will review it but may or may not accept it.
If you continue with the update or install a new package, you’ll have to wait a while; packages will be compiled from the source!
For example, on my old MacBookAir 2016, I only had a few homebrew packages to upgrade:
1
2
3
4
5
6
7
8
9
10
==> Outdated Formulae
bat icu4c@76 libxau python@3.12
ca-certificates jpeg-turbo libxrender readline
cairo libgit2 luajit sqlite
freetype libpng lz4 stow
fzf libssh2 neovim tree-sitter
gettext libtiff openjdk unibilium
git libunistring openssl@3 wget
glib libuv pcre2 xz
harfbuzz libx11 pixman zoxide
After 3 hours (!) I gave up! Things like “zoxide” or “neovim” depend on “llvm”, which, after 30 minutes, wasn’t yet compiled completely! The other dependencies of “zoxide” still take a lot to compile; for example (look at “z3”):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
==> Upgrading zoxide
0.9.4 -> 0.9.6
==> Installing dependencies for zoxide: libssh2, libgit2, z3, swig, llvm and rust
🍺 /usr/local/Cellar/z3/4.13.4: 120 files, 33.9MB, built in 23 minutes 7 seconds
...
Unless you’re willing to wait for several hours (I am not), I guess it’s time to say goodbye to Homebrew. As for me, it also means saying goodbye to macOS on this old MacBookAir (but still a capable computer) and trying to install Linux 🙂
Up to now, I have shown how to get started with Sway with the initial configurations and some other configurations.
Now, I’ll show how to install another status bar in Sway: Waybar (which is more powerful than the default Sway bar). Again, I’m going to do that for Arch Linux. As in the previous posts, I will NOT focus on the look and feel configuration. (This post is similar to the post about Hyprland and Waybar, but it’s specific to Sway).
Before continuing, the Waybar module for keyboard status (Caps lock and Num lock) requires the user to be part of the “input” group. Ensure your user is part of that group by running “groups”. If not, then add it with
1
sudo usermod-aG input$USER
Then, you must log out and log in.
Let’s install the package waybar:
1
sudo pacman-Swaybar
Let’s open a terminal and start Waybar (of course, it will appear on top of the current Sway bar at the moment).
1
waybar&
The result is not that good-looking:
Waybar heavily relies on Nerd fonts for icons, and, currently, we don’t have any installed (unless you have already installed a few yourself).
The terminal will also be filled with warnings about a few missing things (related to Sway) and errors about failures to connect to MPD.
Let’s quit Waybar (close the terminal from where you launched it), and let’s fix the font problem by installing a few font packages:
Let’s start Waybar again, and this time it looks better:
Try to click on the modules and see what happens. For some, the information shown will change (e.g., the time will turn into the date).
If you have “pavucontrol” installed (which should be the case for an EndeavourOS installation), clicking on the volume section will open the “pavucontrol” dialog for adjusting audio settings:
The “Caps” and “Num” locks should react according to the status of the corresponding keyboard keys. The section “it” shows that my current keyboard layout is “Italian.” if you configure several layouts and switch among them, that part in the bar will update automatically. And, of course, the workspace indicator works like in the default Sway bar.
Let’s quit Waybar again and change the Sway configuration to start Waybar instead of the default Sway bar. This section:
1
2
3
4
5
6
7
8
9
10
11
12
13
bar {
position top
# When the status_command prints a new line to stdout, swaybar updates.
# The default just shows the current date and time.
status_command while date +'%Y-%m-%d %X'; do sleep 1; done
colors {
statusline #ffffff
background #323232
inactive_workspace #32323200 #32323200 #5c5c5c
}
}
must be changed as follows:
1
2
3
bar {
swaybar_command waybar
}
Now, start Sway and enjoy Waybar.
Note that Waybar, by default, shows the Sway “mode”. For example, by default, SUPER+R enters the resize mode, where you can resize the current tiled window with arrow keys. The mode is indicated in the Waybar near the workspaces:
To customize the Waybar, create the configuration files for the Waybar (by default, they are searched for in “~/.config/waybar”). We can do that by using the default ones:
1
2
mkdir-p~/.config/waybar
cp/etc/xdg/waybar/*~/.config/waybar/
The above command will copy “config.jsonc” (with the configuration of Waybar modules, i.e., the “boxes” shown in the bar; The configuration uses the JSON file format) and “style.css” (for the style).
At the time of writing, this is the initial part of the configuration file:
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
{
// "layer": "top", // Waybar at top layer
// "position": "bottom", // Waybar position (top|bottom|left|right)
"height":30,// Waybar height (to be removed for auto height)
// "width": 1280, // Waybar width
"spacing":4,// Gaps between modules (4px)
// Choose the order of the modules
"modules-left":[
"sway/workspaces",
"sway/mode",
"sway/scratchpad",
"custom/media"
],
"modules-center":[
"sway/window"
],
"modules-right":[
"mpd",
"idle_inhibitor",
"pulseaudio",
"network",
"power-profiles-daemon",
"cpu",
"memory",
"temperature",
"backlight",
"keyboard-state",
"sway/language",
"battery",
"battery#bat2",
"clock",
"tray"
],
...
The initial parts specify the position and other main configurations. You can edit as you see fit by removing a module, moving it to another position, or enabling new ones. You might want to have a look at the Waybar Wiki for an explanation of the modules.
NOTE: I’m testing this configuration in a virtual machine, so modules like “backlight” and “battery” are not shown because there’s nothing corresponding to them in the virtual machine.
Remember that for each module you mention here, you can have a configuration in the rest of the file, e.g.:
Let’s add a configuration for showing a Taskbar to show all the running applications from all workspaces. This can be useful for quickly looking at all the running applications and quickly switching\ to any of them, especially in many workspaces. I’ll add it to the left section and remove the “custom/media” block, which I don’t use:
1
2
3
4
5
6
"modules-left":[
"sway/workspaces",
"sway/mode",
"sway/scratchpad",
"wlr/taskbar"
],
The module must also be configured to get the functionality that clicking on an element activates that element, possibly switching to the containing workspace (in this example, middle-click will close the window):
1
2
3
4
5
6
7
8
"wlr/taskbar":{
"format":"{icon}",
"icon-size":16,
//"icon-theme": "Numix-Circle",
"tooltip-format":"{title}",
"on-click":"activate",
"on-click-middle":"close"
},
Save the file, and reload Sway to see the block in action (I opened four different applications in four different workspaces):
The right-most section in the bar is a Tray, showing icons of running applications like Dropbox, Skype, or the Network Applet. Let’s install the latter one:
1
sudo pacman-Snetwork-manager-applet
Let’s configure Sway to autostart the “nm-applet”:
1
exec nm-applet
Let’s restart Sway, and now the Tray section is populated by the Network Manager Applet, which you can click and interact with, e.g., for editing connections or connecting to a WiFi network:
Let’s create a custom module for the Power menu, taking inspiration from the EndeavourOS Sway GitHub repository (I’ll change things a bit and simplify them; in particular, I’m going to use “rofi”, i.e., the package “rofi-wayland”, as shown in my previous posts, instead of “wofi”).
First, add the “custom/power” after the “tray” module:
LazyVim has just released version 14, with some new, interesting, and breaking features.
The first breaking feature is that Telescope is no longer the default fuzzy finder picker; the default is fzf-lua. I haven’t been using Neovim for a long time, but I do like Telescope, and I’m not sure I like the new picker.
Here’s a screenshot using Telescope:
Here’s the one using fzf-lua:
Maybe it’s just a matter of configuring the size and dimensions of the window, but I prefer Telescope: I can read the items better, while in fzf-lua, the list width is too short.
This can be seen better when using a folder with a deep subfolder, for example, based on my previous Neovim, Java, and LazyVim post. For example, with Telescope:
While with fzf-lua I can hardly see the names of the files:
The same holds when searching for keymaps (“<leader> s k”). Here’s Telescope:
And here’s fzf-lua (I don’t even understand the strange sequence of characters reported as “details” for some keymaps):
The news page tells you that you have to enable the “editor.telescope” extra to bring back Telescope as the default picker:
However, I went for the alternative shown on the “Telescope” page: it’s just a matter of setting an option (vim.g.lazyvim_picker = “telescope”) to use Telescope as the default picker:
Another change, which is not as breaking as the previous one but concerns the UI, is that the “which-key” interface now defaults to “helix”, so the useful which-key contents are not shown at the bottom of the screen as they used to be:
the contents are shown on the right:
I like this change: the which-key pop-up does not risk covering your buffer, and it can display more content more readably. With the old interface, when the cursor was near the end of the buffer, the interface could not show all the commands, and you had to scroll it. Now, it’s rarer for this to happen. I’ll keep it with the new “helix” preset.
If you look at the corresponding page, it is straightforward to change the corresponding “preset”:
The other breaking change is “blink.cmp as a replacement for nvim-cmp“; even in this case, you can revert to the old behavior by enabling the corresponding Extra. This doesn’t seem to break anything for me for the moment, so I’ll keep that.
You might also want to try the new keymaps; in particular, I like these ones:
The end of this part is still the branch “first-blog-post” (this blog post does not touch the configuration files).
In the first part, we saw how to enable Java LSP in the LazyVim distribution. We also saw a few interesting features for programming in Java in Neovim with such a configuration. In this post, we’ll see a few of the IDE mechanisms we get from the Java LSP in LazyVim. Let’s continue from where we left off (remember, I’ll use the above-mentioned Maven project).
Code completion and snippets
Let’s instead create a new Java file inside a source folder of this Maven project (e.g., starting from “src/main/java”), either with “:e <path>” or with the “Neotree” file explorer that comes installed and configured with LazyVim: toggle the explorer with “<leader> e”. I’ll create an Example.java inside the “app” subfolder: get to that folder, press “a” (for add), write the name “Hello.java”, and press ENTER to confirm:
Pressing ENTER again will open the empty file in a new buffer.
We’ll use snippets configured by default instead of writing all the contents, e.g., the correct package and the class implementation. Let’s enter INSERT mode and press Ctrl+SPACE. Start typing “cl”, we should get to the snippet we need (see the preview on the right): the one with all the correct contents:
Press ENTER to accept the snippet, and we get a valid Java class, with the cursor positioned inside the class’ body:
Let’s keep on using snippets to create a “main” method:
And a “System.out.println” statement:
Till you can write the “Hello World” string as an argument!
You might want to explore other useful snippets, like creating a public method:
Once the snippet has been selected, you have placeholders to edit the return type, the name, etc. Start typing to insert the return type, press TAB to get to the name, change the name, and press TAB to get inside the parenthesis to insert the parameters possibly. The final TAB will get you inside the method body. Shift TAB goes in the other direction.
Code actions
Let’s look at a few other features provided by LazyVim Java Extra. Note that these LSP-related features are not strictly related to the Java LSP but to the general configurations for LSPs. The same keybindings and mechanisms are meant to work with other LSPs, though not all LSPs implement all such capabilities.
You have code actions, using “<leader> c a”, which depend on the context you’re in the source file:
This menu is also handy for having the IDE fix errors for you (handy when you apply TDD); in Eclipse, we’d call them “quick fixes”, but in this context, “quick fix” is meant for quickly seeing all the diagnostics. For example, I intentionally refer to a non-existing symbol, and I use “Code actions” to have the IDE create that field for me (remember to exit insert mode to get the diagnostics; by the way, such dialogs can be filtered starting typing something to access the desired item quickly):
As another example, let’s change the package name in the “Hello.java” file we created above:
As expected, this makes the file invalid, as reported in the editor (and also in the explorer). Let’s use the code actions:
We use the first one because we want the file to be moved to the correct source directory:
Let’s do the opposite, press “c” in the Explorer to cut it:
move to the “app” folder and “p” to paste it:
The file is invalid again; this time, we use the second code action to change the package name in the file to respect the current source directory (remember that you must be in the buffer for code actions, not in the Neotree; you can use Ctrl + L to move to the right window):
Navigating through symbols
You might explore other features like showing symbols; there are many ways of achieving that in LazyVim and its default plug-ins. You can use “<leader> s k” to search for keybindings and start typing “Symbol”. Here are some examples.
“<leader> s s” gives you symbols with Telescope:
“<leader> s S” gives you symbols with Telescope in the entire workspace; the workspace is an LSP concept, but for the Java LSP, it can be seen as the Eclipse workspace that is being used under the hood: you get access to all the Java source files and all the types in the dependencies of the project. Start typing (be patient if you have a workspace/project with tons of dependencies), and you should see the classes of your sources and dependencies. In this example, we can access all the types starting with “Assert” from the JDK and the dependencies (in this project, JUnit, AssertJ, Log4J).
Selecting one will open it in the editor. If it comes from a dependency, the LSP will download the sources of the corresponding Maven artifact and show them in a read-only buffer.
“<leader> c s” gives you the “Trouble” symbol window, which is similar to the Eclipse Outline (note that it is synchronized with the editor; I changed the color theme to make selections more visible):
“<leader> c S” (capital “S”) gives you the “Trouble” window with references and calls to the currently focused element (again, the window is kept synchronized):
Then you have all the navigation capabilities, typically starting with “g,” like goto definition or goto references (opening a telescope picker for all the references in the workspace). You can also explore jump operations like “[c”, “]c”, “[f”, “]f” to navigate around a source code (class definitions, method definitions, etc.)
You also have some refactorings, like “Rename” (of course, updating references throughout the project’s files) and “Extract” (variable, constant, methods). You can experiment with them by searching for them with “<leader> s k” or using “<leader> c” and then waiting for the available commands (provided by the Neovim plugin “which-ley”, automatically configured by LazyVim).
That’s all for this post; stay tuned for future blog posts, where we’ll cover:
Let’s continue the Sway window manager (in Arch Linux) series I started in my previous post and continued in the other post.
Screenshots
We can use “grimshot”, part of sway-contrib, to take screenshots, which requires the main program for performing the actual screenshot, “grim”.
1
sudo pacman-Ssway-contrib grim
By default, such utilities are installed in “/usr/share/sway-contrib”, which is not part of the PATH. So, put that directory in the PATH environment variable or prefix the call with the full path.
This is the first part of a few tutorials on Java development with Neovim using the LazyVim setup. I highly recommend LazyVim because it has many cool plugins configured with nice defaults. Moreover, as we see in this tutorial, it lets you quickly have the Java LSP up and running in Neovim.
You need Java installed (possibly 21), while Maven is optional.
You can follow this step-by-step tutorial by implementing the steps starting from a fresh LazyVim installation (see http://www.lazyvim.org/installation). If you already use LazyVim, you might want to do the steps in this tutorial on a fresh, separate Neovim configuration directory before applying all the configurations in your daily-driver Neovim configuration.
For example, if you start with the starter project provided by LazyVim, you can clone it into a separate configuration directory:
And then you start Neovim pointing to that configuration:
Shell
1
NVIM_APPNAME=lazyvim-java nvim
This way, your existing Neovim configuration won’t be touched, and you’ll be free to experiment with this new configuration.
In these tutorials, the path is always intended relative to the Neovim configuration path when referring to a configuration file. If you follow the above commands, for example, it will be relative to “~/.config/lazyvim-java”.
I suggest you try to follow the tutorials by manually executing the configuration steps in such a new separate Neovim configuration.
The end of the first part is the branch “first-blog-post”.
To make the tutorial more readable, I will use a few different “light” themes in Neovim instead of the default dark one. Remember that you can temporarily switch the theme with “leader uC”.
A few initial notes
LazyVim comes with autoformatting on save. If you don’t want to disable that in configuration, at least you can use these commands to toggle it during the current session:
“<leader> u f” Toggle Auto Format (Global)
“<leader> u F” Toggle Auto Format (Buffer)
Moreover, by default, LazyVim is configured to replace tabs with spaces. I don’t like such a behavior globally, so I disable it by adding this line to the existing file “config/options.lua”
Lua
1
vim.opt.expandtab=false-- Don't use spaces instead of tabs
If you cloned the above Maven Java example, you can try opening one of its Java files in Neovim:
Without the Java LSP, you only have basic syntax highlighting but no other IDE tooling.
Let’s install the LazyVim “Java Extra”. A LazyVim extra is meant to configure several plugins and configurations with a single mechanism. In this case, it will configure the Java LSP (“jdtls”, the Java LSP provided by Eclipse, implementing all the excellent Eclipse IDE Java development features) and configure other related plugins and keybindings.
You have some alternatives to enable an “Extra”, which is documented for each available “Extra”; for Java, see http://www.lazyvim.org/extras/lang/java. I prefer to use the UI: Type “:LazyExtras” to show the LazyVim Extras UI:
The LazyExtras UI proposes some recommended extras based on the files you’ve just opened, so it should recommend “lang.java”; if not, search for “lang.java” and when you’re on that line, press “x” to install the extra.
You get the feedback about restarting Neovim:
Specifying an extra as we’ve just done creates a file in the configuration, “lazyvim.json”, with this content (the numbers for news and version might be different depending on when you follow this tutorial):
Lua
1
2
3
4
5
6
7
8
9
{
"extras":[
"lazyvim.plugins.extras.lang.java"
],
"news":{
"NEWS.md":"7429"
},
"version":7
}
The idea is to keep this file in the Git repository for your configuration as part of your dotfiles for Neovim.
You can now try and open a Java file from this project.
It will not work the first time because Mason has to install the LSP. So, it would try to start the Java LSP (“jdtls”) before it is fully installed. After you see that Mason has successfully installed “jdtls”, you can restart Neovim.
Of course, you could force the installation of “jdtls” by using the Mason UI, “:Mason”: select “jdtls” and install it.
Alternatively, if you want a fully automated solution that, besides installing all the Neovim plugins, also automatically installs the Java LSP, you can add this Lua specification in the Neovim configuration folder (the name does not matter; I call it “extend-lsp” to stress that it extends the Mason configuration of LazyVim, https://github.com/LazyVim/LazyVim/blob/main/lua/lazyvim/plugins/lsp/init.lua) “lua/plugins/extend-lsp.lua” with this content:
Lua
1
2
3
4
5
6
7
8
return{
"williamboman/mason.nvim",
opts={
ensure_installed={
"jdtls",
},
},
}
Now, when you start Neovim, “jdtls” will automatically install. Remember that “jdtls” is a big Java JAR, so you might want to check whether Mason has successfully downloaded and installed it or is still installing it through the Mason UI.
It works best if you start Neovim from the root directory of the Maven project (the one containing the “pom.xml”). If you open a Java file from another directory, the configured LSP will still search for a “pom.xml” in the parent directories until it finds one (other valid files are the Gradle and Ant specification files if the project is not based on Maven); the root of a Git repository is also a valid root directory.
The highlighting looks much better, with many more highlighted parts (thanks to Treesitter, which the LazyVim Java Extra includes), and you can see the messages from the Java LSP doing its checks and tasks (including downloading Maven dependencies if they are not already cached):
This is a Maven project, so the Java LSP has to resolve the Maven dependencies. If this is the first time you open this project, you should see messages about downloading Maven dependencies.
When all dependencies have been resolved, and the Java LSP has correctly compiled the sources, you can also see some editor decorations (inlay hints), like the parameter names, when calling a method (of course, those parts are NOT part of the source, but only visual content in the editor):
You can enable/disable inlay hints with “<leader> u h”.
With “<leader> c C” you can also refresh “code lens”; for Java, you get the references to classes and methods:
Hovering support (“K”) allows you to see the Javadoc of the current element, e.g., for String:
Pressing any key will make the pop-up window go away. If you want to scroll the pop-up window, use “Ctrl w w” (switch window), and you can scroll the Javadoc.
You’re ready to develop your Java program using typical IDE tooling, like content assist.
Exiting the “insert mode” automatically triggers Java validation, possibly showing warnings and error markers in the editor.
NOTE: The Jdtls LSP (i.e., how LazyVim configures such an LSP by default) creates an Eclipse workspace in the directory “~/.cache/lazyvim-java/jdtls/” in a subdirectory named after the Maven project, e.g., in this example, “~/.cache/lazyvim-java/jdtls/maven-bank-example”. This is just information since you don’t need to care about the created workspaces, which are meant to be ephemeral.
The example used in this post is an Eclipse project. The LSP detects that and possibly updates the Eclipse metadata files accordingly, e.g., “.classpath”, “.settings” directory, “.project”, etc.). If you start with a Maven project (not Eclipse) since the Java LSP is the one from Eclipse, it will create the above Eclipse metadata files automatically for you.
Interestingly, you could use a plain existing Eclipse project, and the Java LSP would still work in Neovim. For example, this is an Eclipse project (not Maven), again part of my TDD book: https://github.com/LorenzoBettini/assertj-log4j-bank-example. It contains the JARs for Assertj and Log4J, and the “.classpath” refers to the JARs that are included. It works seamlessly in Neovim!
We use mako, a lightweight notification daemon for Wayland, one of the optional software suggested when we installed Sway. We also need “inotify-tools”:
1
sudo pacman-Sinotify-tools mako
The nice thing about mako is that you don’t need to start it manually as a service: the first time a notification is emitted, mako will run automatically.
Let’s try to run the notification command:
1
notify-send"hello"
We see the pop-up in the screen’s top right corner by default.
You can have a look at mako’s manual (5) about its configuration file and where it is searched for:
1
2
3
4
5
6
7
8
9
10
11
12
man 5 mako
NAME
mako - configuration file
DESCRIPTION
The config file is located at <strong>~/.config/mako/config</strong> or at $XDG_CON‐
FIG_HOME/mako/config. Option lines can be specified to configure mako like so:
key=value
Empty lines and lines that begin with # are ignored.
Each time you modify the configuration, you must reload mako by using one of the following commands:
1
killall mako
or
1
makoctl reload
With that example configuration, we can emit a few notifications with different “urgencies”, and see the different colors and positions of the boxes:
1
2
3
4
5
6
7
notify-send-ulow"hello world\!""This is a low urgency message"
notify-send-unormal"hello world\!""This is a normal message"
notify-send-ucritical\
"This is a critical message\!"\
"OK, that was just a demo ;)"
If you use EndeavourOS, you will get notifications about new updates and when a reboot is required after a system update (the latter is a “critical” notification):
That’s all for this post!
Stay tuned for another post about Sway WM.
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.
