My current system is Fedora, a Linux (or GNU/Linux) OS, so the installation commands in this post target it.

The JDK is not the JRE

Even if Java is already installed in the OS, it’s almost certainly only the Java Runtime Environment (JRE). For development we need the Java Development Kit (JDK).

To achieve this we need to select the version from the package manager in the system.

• sudo dnf install java-latest-openjdk-devel installs the latest OpenJDK

The -devel suffix is the part that brings the compiler and the rest of the development tooling; the plain java-latest-openjdk package is only the runtime. One caveat: “latest” currently means an early access build of the next JDK release, which can be ahead of what some projects expect. If you prefer a stable release, install a numbered package instead — e.g. sudo dnf install java-25-openjdk-devel — after checking what the repositories offer:

dnf list --available 'java-*-openjdk-devel'

With the JDK in place, we can confirm which version is active:

java -version

Now we have the development kit, and should be able to start developing.

Managing dependencies with Maven

In today’s open source ecosystem we have a lot of available packages that we can use as dependencies. Having dependencies means we need a way to manage them, and for that we could go for the old school Maven (that downloads half of the internet, wink wink).

• sudo dnf install maven installs the latest Maven version

• mvn -version shows the Maven and JDK versions in use

Scaffolding a project with Archetype

Creating a new project, in older days, I basically used the IDE to set it up. At the moment I’m using neovim and don’t have a plugin for that (and don’t really want to add one dedicated to it). But with some investigation I found out that Maven has a workaround for this.

Maven has the Archetype, a project templating tool. With it and some parameters we can easily create a project, provided that an Archetype exists for the type of project that we are looking for.

In my case I want to create a Cucumber project, which has an Archetype. To create it I’ll execute the following command.

mvn archetype:generate                        \
  -DarchetypeGroupId=io.cucumber              \
  -DarchetypeArtifactId=cucumber-archetype    \
  -DarchetypeVersion=8.0.4                    \
  -DgroupId=hellocucumber                     \
  -DartifactId=hellocucumber                  \
  -Dpackage=hellocucumber                     \
  -Dversion=1.0.0-SNAPSHOT                    \
  -DinteractiveMode=false

If -DinteractiveMode=false is left out, Maven asks for each of those values one by one, which is handy when you don’t want to memorise the property names.

This will generate a project with cucumber, JUnit, and AssertJ dependencies. Besides the dependencies, it adds the base file and folder structure to build a testing project, with an example test. To confirm that everything is wired up:

cd hellocucumber
mvn test

Takeaway

Even with an IDE capable of generating a Java project, Archetype is an awesome piece of templating that Maven gave to developers, allowing a new project to be generated from a template instead of having to create every file by hand.

It also connects with the way I already work: both at my job and in my personal repositories I keep ‘starter’ projects. The idea is to use them as templates, so starting something new never begins completely from scratch. A feature like this opens new ways to generate and consume those starters.

For now I’ll keep exploring Cucumber and refreshing my memory of Java, but I’m seeing a path to explore, and maybe to create a custom Archetype if I’m able to generate one locally. I need to squeeze some time in a near future to explore it.

Another point where this technology can help is in tasks that I do not have experience with. Being able to execute it, acquiring insight on how to do it, and having the chance to learn a new skill, is a must.

I don’t have a taste for design, nor experience with design tools, so every time I need to create an image or a design it is a problem to me. The time that I spend testing designs and exploring the tools available in the application that I’m using is a lot, and because I don’t do this type of task regularly, the knowledge that I gain during the task execution is never consolidated.

For this site I need to create a hero image for each post, and that, as I described above, would be a pain. This post is an informal documentation of some experiences that I had, and some notes on how to use a tool. Spending time to create a hero image would go against the objective of creating a post where the only overhead is acquiring the experience and knowledge on the application, tool, or procedure that I am writing about.

Finding a GIMP MCP

Some weeks ago I came across someone who had created an MCP for the GIMP application. Since I have been using ChatGPT to generate the images for the other posts, and they are not what I tend to say that are good and/or professional (they are better and faster than I would do manually) I thought that this could be a good tool to explore.

After a quick research I discovered that there is more than one GIMP MCP available, and I found a list of them with some evaluation on this page: Glama Best GIMP MCP Servers. I don’t know the quality of this site, it is the first time that I have seen it.

With the objective of creating a new image and not only editing an existing one, I looked at the list and at the evaluation that it has regarding license, quality, maintenance, and the last update, and I selected this one to test: gimp3-mcp by tifyr.

It was updated for the last time 12 days ago, has an A rate for license and maintenance. The only item that does not have any rate is quality. It supports GIMP 3.2, and has the ability to create or open images, paint, edit, and export them, and to look at the image between the steps to check its work.

Installation and setup

To install it I followed the steps in the installation section of the GitHub repository. The system that I’m using to test it has a Void Linux distribution, and I had no issue installing it.

To test this I used the OpenCode harness, with its free tier of models, and the GIMP version is 3.2.6 rev 1.

• gimp3-mcp installation

uvx gimp3-mcp install-plugin

• OpenCode MCP configuration

{
  "mcp": {
    "gimp": {
      "type": "local",
      "enabled": true,
      "command": ["uvx", "gimp3-mcp"]
    }
  }
}

Does the model matter?

Regarding the models, I was able to use a model that does not have the image processing ability, but from the experiments that I have done, using an image-capable model tends to reduce the token consumption and to generate a better image. With this ability the model can retrieve the current image snapshot from the MCP and analyze it, without it, it needs to use Python scripting to analyze it.

Does a skill help?

This MCP has some quirks that an agent needs to battle at the start. Using it with only the configuration on the harness is usable, but causes some issues when the agent starts the prompt execution. From my testing, the best solution that I found is to create a skill dedicated to it.

Using a skill will enable the agent/model to work with better performance during the image generation. I used a model to analyze the gimp3-mcp, and to plan and implement a skill to help with this. It created a bundle that, besides the skill file, has a bash and a python script to start GIMP and the MCP. If you want to take a look and test it, it is located here: alexandrepascoal/opencode-skills.

Results

I stored all the images that were generated, both to be able to compare and evaluate the results, and to have examples to show in this post. Below I list the result images with what was used to generate them.

The prompt used to generate the images was something like: I need to create an hero image to a post document describing my experiment with a gimp mcp. Use the images available in the current folder. The images that I had in the folder were the logos of GIMP and OpenCode.

Only the prompt. I installed the MCP, configured it in OpenCode, and prompted it with a model that does not have image processing. I can’t remember the prompt that I used for this one, but I think that the main issue was not giving any base images or style to the model.

With base images. I used the same model as the previous one, but this time I added to the folder the two logos (GIMP and OpenCode). The result is more professional, more sober, as it was made by an adult.

With base images and a model with image processing. At this point, in my opinion, the main difference is the speed and the token consumption, and the image is more professional than the previous one, all the components are legible, no problem for me using it.

With a skill. In regards to this one, it’s professional and readable. The main point here is that it kept the speed and token consumption of the previous image, but there were no issues with starting GIMP, the MCP, or having failing API calls. It was like a breeze.

Limitations

One point that could be relevant in the way this could be implemented, is that the MCP needs to have GIMP started and it will be in headed mode. The application will be open on the computer that is being used, the image that is being generated/manipulated is displayed in the application, and the user could interact with it. This could limit the use of this in a server without a graphical interface, and the user being able to interact with it leaves room to interfere with the execution.

Wrapping up

At the moment this is the only one that I have tested, related to GIMP. During the analysis that I requested from the tool, the model reported some issues with it. I’m not sure that they are valid or not, I need to take a look at the report and the code to be able to have a clear vision. But even with this I think that gimp3-mcp by tifyr is a tool that produces good results.

For now I think that I’ll keep using it and exploring what I can achieve with it. The skill that I created may need to be more curated, but it made a difference in the result.

The other available MCPs could be better, faster, with fewer issues. I could take a look into them in the future.

Problem

Sway has a keybind configuration that enables the user to create “layers”, similar to the vim modes, or the layers present on a computer keyboard. This allows a key or key combination to have different actions depending on what mode is active.

As an example, I have the CMD+M to open the mail client in normal mode and have the same key combination to open the mastodon client in the social mode. To define this in Sway, and not expanding on this, we define the mode, the keybinds in it, and a keybind to activate it.

mode "print" {
	# Print Area
	bindsym A mode "default" ; exec dms screenshot # Print Area
	# Print Screen
	bindsym S mode "default" ; exec dms screenshot full # Print Screen
	# Print Window
	bindsym W mode "default" ; exec dms screenshot window # Print Window
	# Exit Print Mode
	bindsym Escape mode "default" ; # Exit Print Mode
}
# Open Print Mode
bindsym Print mode "print" ; # Open Print Mode

The problem with this is that when using the OS we have no way of knowing what mode we’re in — and if our cats like to walk across the keyboard, we’re in for a surprise :)

Solution

In DMS there is a plugin that displays the mode that is active but it only works for Hyprland, and since I’m using sway… you know what I did.

I created a plugin to display the name of the active mode in the Dank Bar, using the theme style. It only displays the name of the mode if the active is not the default.

Resolution

Sway has the binding state available using the command swaymsg -t get_binding_state, which returns a json with the name of the active state.

swaymsg -t get_binding_state
{
  "name": "default"
}

I used the Process QtObject to execute the swaymsg call and retrieve the response. The Process has a list of properties from where I used the id, command, and stdout.

With the command I execute the command and with the stdout retrieved the response, the id is the identification of the Process component so we can call it from other code components.

I used the SplitParser to read the streamed stdout line by line and extract the value of the name field from the returned JSON (not my brightest work), giving me the name of the current active mode.

I also created two global variables to store the name of the mode and a flag that controls whether it should be displayed (hidden when the mode is default). These variables are updated in the Process and consumed by the horizontalBarPill to show or hide the name.

I’m not sure whether the binding state could be monitored another way, but I used the Timer from QtQuick to execute the Process every 200 milliseconds.

Conclusion

As in the other post, my knowledge of Quickshell is not the best. But the ability to create these types of applications gives me some curiosity to play with the framework every time I find these kinds of cases, and to improve the apps that I build.

This plugin has room to be improved… when retrieving the data from the swaymsg, I’m pretty sure that if I invest some time it could be better developed. Another point that I missed and didn’t take the time to implement is the verticalBarPill — at the moment the plugin only displays the text horizontally, so it won’t be visible in a vertical bar.

If you are interested in using it, improving it, or just taking a look at it, you can find it in the Codeberg repo quickshell-sway-modes-plugin.

If you find an issue with it, or have some improvement to it, feel free to ping me or make a proposal in the repo.

Problem

The Dank Material Shell has some plugins, official and 3rd party, available from the Plugins section in the Settings component. I noticed the existence of a plugin that displays the number of available updates on the dnf and flatpak package managers, this is very useful as it allows to know how many updates are pending and decide when to apply them.

Obviously this plugin is useful for a person that uses the Fedora distribution, but useless on Debian-based distributions, Void, or Arch.

Another issue is that in some cases the number of updates available does not match the real updates number. Later on I found that this issue might be caused by the way some flatpak packages are presented, some do not have the same number of properties and this could be the cause for the issue with the number in this plugin.

Solution

At the moment, both my main and work computers run Fedora, so the package managers weren’t a problem, just an itch in my brain. The missing available updates number was the same type of itch…

With all these itches, I thought that I could try to build a plugin of the same type that supports the other GNU/Linux distributions and with the correct updates number.

Resolution

I built a plugin that can be added to the Dank Bar (the bar that the DMS has). That will list the updates available from dnf, flatpak, xbps, apt, and pacman if they exist in the system.

The component, on click, will display a popout with the list of the available package managers that have available updates, an option to fetch the updates manually, the ability to run updates for each package manager individually, and even a button to execute all available updates at once.

Besides the actions available in the popout, it also displays the list of the packages that have new versions available. It also has the ability to use the keyboard to navigate the popout component, giving a better integration to the Window Managers philosophy of the keyboard being the main input to navigate. Also has the ability to toggle the popout so this can be mapped into a key/key combination, giving one more integration to the keyboard.

The plugin has some configurations that could be changed in the DMS settings. They are the time in minutes at which the plugin will execute the updates check; the option to select the terminal that will be used to execute the update; and the option to activate/deactivate the notifications regarding a successful or failed update execution.

Conclusion

The way I built this plugin gave me an awkward feeling, not being comfortable with the Quickshell framework and developing outside my area of expertise.

The decision to build it this way was mostly due to the fact that learning QML would not give me any advantage for my work, as I don’t see any personal drive to learn it.

So I created the plugin with the name System Updates, and it is available in the Codeberg repo quickshell-system-updates-plugin.

I think that this little application is useful to myself, as well as anyone else who wants to perform system updates on a Linux-based machine with minimal effort. And the ability to build something useful this quickly is amazing!

PS:

• This tool will have some issues, even with me forcing the existence of tests. So if you use it and find any problem please report it and/or propose corrections.
• Regarding the package managers, the current implementation has been tested with dnf and flatpak, and less extensively with xbps. The other managers apt and pacman do not have any test, so I would appreciate if someone could take a look at them and share their experience.
• There are some managers that this tool does not support, from the back of my mind yay and snap, if there is any interest in supporting these tools please comment.