GSoC’22: Adding Custom Actions to Screenshooter

The Task

Screenshooter (xfce4-screenshooter), as the name suggests, is an application that takes screenshots. Some action is needed once the screenshot is taken on the captured image. Currently, the application provides four well-defined actions: to save the picture, open the image, copy it into the clipboard, and upload it to Imgur. But some users may want to perform other specific actions after taking the screenshot, such as printing them or sending them over an email. So the task was to allow users to add custom actions that can be executed once the screenshot is taken. Similar functionalities are also present in Thunar and AppFinder.

The

Sponsored

Solution

The solution was quite simple. We can have a list of user-defined custom actions stored in the system. Each element in the list will denote a custom action and will have attributes “name” and “command”. The “name” attribute stores the string that will be displayed to the user when selecting the custom action. And the “command” attribute is the command that will be executed. The command can have a ‘%f’ placeholder that can be used to get the absolute path of the screenshot captured. For storing this list, xfconf was used. Each custom action has a unique id associated with it. So if that unique id for a custom action is ‘i’ then its attributes are stored as “actions/action-i/name” and “actions/action-i/command”. The rest of the solution includes providing a simple user interface to modify this list and executing the command.

Under The Hood

With the help of my mentor, André Miranda (AndreLDM), this solution was successfully implemented in MR #37.

The first part of implementation involves creating a preferences dialog box that can be used to modify the list of custom actions. It must be noted that whenever the dialog box opens, it reads the data from the hard disk, and whenever it closes it stores the data back into the disk. This dialog box allows users to add, delete and modify custom actions.

The next part was to add an option for selecting a custom action to be executed once the screenshot was taken. Here again, the list of custom actions is read from the system, but it is never written back as no modifications are done to it. This option is only shown if there are custom actions in the list. If, instead, the list is empty, then this option is not offered. Once the user selects the custom action, its name and command are stored in the ScreenshotData structure.

Then comes the most crucial part, where the custom action gets executed. Here we don’t read the list, just the command and name stored in the ScreenshotData structure. The absolute path of the image first replaces the placeholder text. Then “g_spawn_async” is used to execute the command asynchronously. It’s done asynchronously so that the command may not block the application.

This implementation’s beauty lies in how we have used the already implemented code. Once the image is captured, it is stored in the /tmp directory using the “Save” option. Then the execution part happens. So under the hood, two actions are occurring from the action selection dialog box.