A few days ago, while working on my highly customized Linux environment (which I detailed in my previous post about my tech setup), I realized that I was missing a key component: a robust clipboard manager. For those unfamiliar, a clipboard manager is a utility that keeps track of multiple items copied to the clipboard, allowing users to access their clipboard history and reuse previously copied content.

My first instinct was to scour the internet for existing solutions. The Linux ecosystem is rich with open-source tools, and I was certain I’d find something that fit my needs. However, after some preliminary research, I decided to tap into a more personalized resource: my colleagues.

As avid Linux users themselves, my coworkers have a wealth of experience with various tools and utilities. It was during this consultation that Edoardo, one of my more tech-savvy colleagues, suggested greenclip.

Greenclip: A Solid Contender

Greenclip is a clipboard manager for Linux that immediately caught my attention. It’s designed to be lightweight and integrates seamlessly with rofi, a window switcher, application launcher, and dmenu replacement that’s already an integral part of my Linux setup.

The integration with rofi was particularly appealing. Rofi is a versatile tool that I use extensively in my workflow. It’s fast, customizable, and provides a unified interface for various system interactions. The prospect of managing my clipboard history through the familiar rofi interface was enticing.

I installed greenclip and set it up to work with rofi. The initial experience was positive. It worked as advertised, maintaining a history of my clipboard entries and allowing me to quickly access them through a rofi menu. The workflow was smooth, and I appreciated the added functionality it brought to my system.

The Unexpected Challenge

However, as with many things in the world of system optimization, the devil was in the details. After using greenclip for a few days, I noticed something concerning: an increase in my system’s power consumption.

The Power Dilemma

I’m meticulous about monitoring my system’s resource usage, and I regularly use tools like powertop to keep an eye on power consumption. Powertop is an excellent utility developed by Intel that helps diagnose issues with power consumption and power management.

immagine

To my dismay, powertop revealed that greenclip was consuming more system resources and energy than I was comfortable with. While the increase might seem negligible to some, it went against one of the core principles of my Linux setup: minimal resource usage.

The Pillars of My Linux Philosophy

It’s worth noting that my Linux configuration is built around three fundamental concepts:

  1. Privacy: I’m cautious about the data I generate and how it’s handled.
  2. Security: Protecting my system and data is paramount.
  3. Low resource/battery usage: I strive for efficiency in every aspect of my setup.

The increased power consumption introduced by greenclip, while not dramatic, was enough to make me reconsider my choice. It was clear that I needed a solution more aligned with my philosophy of minimal resource usage.

The Decision to Go Custom

Faced with this challenge, I made a decision that embodies the spirit of the Linux community: I decided to create my own solution. This choice was driven by several factors:

  1. Complete control: By developing my own tool, I could ensure it adhered strictly to my principles of privacy, security, and efficiency.
  2. Learning opportunity: Creating a custom solution would deepen my understanding of how clipboard management works in Linux.
  3. Tailored functionality: I could implement exactly the features I needed, without any unnecessary bloat.
  4. Open source contribution: By sharing my solution, I could potentially help others facing similar challenges.

Crafting the Custom Clipboard Manager

With the decision made, I set out to create a clipboard manager that would meet my specific needs while maintaining minimal resource usage. The result was a simple yet effective bash script that leverages existing Linux utilities to provide clipboard management functionality.

The Building Blocks

My custom solution relies on several key components:

  1. xclip: A command line interface to the X11 clipboard. It allows reading from and writing to the X selection from the command line or scripts.

  2. clipnotify: A simple tool that listens for selection changes. It’s crucial for detecting when new content is copied to the clipboard.

  3. rofi: While not directly used in the clipboard management, rofi provides the interface for selecting items from the clipboard history.

The Script

Here’s the bash script I developed:

#!/bin/bash

HISTORY="`xdg-user-dir DOCUMENTS`/Personali/clipboard.history"

if [ $1 = "daemon" ]; then
	while $(clipnotify -s clipboard):
	do
		isimage=$(xclip -selection clipboard -t TARGETS -o | grep -c image)
		if  [ $isimage -gt 0 ]; then
			echo "Multimedia content, skipped!"
		else
			clip=$(xclip -o -selection clipboard)
			clip="${clip//$'\n'/\\n}"
			last=$(tail -1 "$HISTORY")
			if [ "$last" != "$clip" ]; then 
				echo "New clip!"
				[[ -z "$clip" ]] || echo "$clip" >> "$HISTORY"; 
			fi
		fi
	done;
elif [ $1 = "rofi" ]; then
	INPUT=$(echo "`tac $HISTORY`" | rofi -dmenu -i -p "")
	[[ -z "$INPUT" ]] || echo -e "$INPUT" | xclip -selection "clipboard" -rmlastnl
fi

Let’s break down how this script works:

  1. The script defines the location of the clipboard history file using the xdg-user-dir command to ensure compatibility across different Linux distributions.

  2. When run with the “daemon” argument, the script enters a loop that:
    • Uses clipnotify to wait for changes in the clipboard.
    • Reads the current clipboard content using xclip.
    • Compares the new content with the last entry in the history file.
    • If the content is new, it’s added at the end of the history file.
  3. When run with the “rofi” argument, the script:
    • Uses rofi to display a menu of clipboard history items.
    • When an item is selected, it’s copied back to the clipboard using xclip.

Setting Up the Custom Solution

To use this custom clipboard manager, I set it up as follows:

  1. I saved the script in a file named myclip.sh and made it executable with chmod +x myclip.sh.

  2. I added a line to my window manager’s autostart file to run the daemon: 
    ~/path/to/myclip.sh daemon &
  3. I created a keyboard shortcut that runs ~/path/to/myclip.sh rofi to bring up the clipboard history menu.

Benefits of the Custom Approach

This custom solution offers several advantages that align perfectly with my Linux philosophy:

  1. Minimal Resource Usage: By using lightweight, built-in Linux utilities, the script consumes minimal system resources. The power usage is negligible compared to more feature-rich clipboard managers.

  2. Privacy and Security: The clipboard history is stored in a plain text file on my local system. I have complete control over where and how this data is stored, ensuring that my clipboard contents remain private and secure.

  3. Simplicity and Transparency: The entire functionality is contained in a short bash script. This simplicity makes it easy to understand exactly what the tool is doing and to modify it if needed.

  4. Easy Synchronization: Because the clipboard history is stored in a simple text file, it can be easily synchronized across different machines using tools like Syncthing, Nextcloud, or rsync. This allows for a consistent clipboard experience across all my devices.

  5. Integration with Existing Workflow: The use of rofi for the selection interface means that accessing clipboard history fits seamlessly into my existing workflow, maintaining consistency in my user experience.

  6. Customizability: The script can be easily modified to change behavior. For example, I could add a feature to limit the number of items in the history, or to exclude certain types of content from being saved.

Potential Enhancements

While the current version of the script meets my needs, there are several potential enhancements that could be made:

  1. Content Filtering: Implement filters to exclude sensitive information (like passwords) from being saved to the history.

  2. History Limit: Add a feature to limit the number of items stored in the history file to manage file size.

  3. Content Type Handling: Enhance the script to handle different types of clipboard content (text, images, files) more robustly.

  4. Encryption: Add an option to encrypt the clipboard history file for additional security.

  5. GUI?: Are you serious?

Conclusion: The Linux Way

This journey of creating a custom clipboard manager exemplifies what I love about the Linux ecosystem. When faced with a challenge, we have the freedom and the tools to craft our own solutions. This isn’t about reinventing the wheel, but about shaping our tools to fit our exact needs and philosophies.

My custom clipboard manager might not have all the bells and whistles of more established tools, but it does exactly what I need it to do, in the way I want it done. It’s efficient, respects my privacy, and integrates seamlessly with my workflow.

This project also highlights the power of the Linux community. By sharing this solution, I hope to inspire others to look critically at their tools and to consider crafting custom solutions when existing ones don’t quite fit the bill.

So, if you’re interested in trying out this clipboard manager or using it as a starting point for your own custom solution, feel free to use and modify the script. And if you make any interesting enhancements, I’d love to hear about them!