Automating Distribution

Of course, you wouldn't want to have to enter the short forms and hotkey actions manually in the autokey-gtk GUI on every single Linux box you use. Also, it would also be useful to automate the process of adding new production helpers to the Autokey configuration instead of detouring via the desktop.

You need to investigate what Autokey actually does behind the scenes to implement this: After the user has pressed the buttons for the Autokey configuration, filled out the text fields, and closed the dialogs (not forgetting to press the Save button in the bar at the top), Autokey stores the data in the user's home directory below ~/config/autokey.

The metadata for the defined keyboard shortcuts now exist in JSON format below the respective folder: My Phrases for phrases and Sample Scripts for actions. A fresh Autokey installation creates a number of sample phrases the first time you call autokey-gtk; they all give you a good idea of the tool's full potential (Figure 6).

Figure 6: The first time you launch it, autokey-gtk generates several sample phrases and scripts.

To automate the process, the Perl script [3] in the following section copies the metadata format used by Autokey from the existing examples and adds new settings defined in a fairly compact Yaml file, which you can edit without much ado to suit your own needs (Listing 1).

Replace Verbose JSON

The JSON files that Autokey uses to store the metadata are relatively verbose, as you can see from Figure 7. Files named .<name>.json contain the information linked to the <name> entry, and the matching Python script for triggering the desired action resides in <name>.py in the same folder.

When called like this,

autokeygen autokey.yaml

Figure 7: Autokey uses the .terminal.json file to store the hotkey mappings for the Python script in terminal.py.

the script in Listing 2 grabs and uses the two entries in the Yaml file – one for the text substitution of the hth short form and a terminal action for the Ctrl+Alt+N shortcut – to form a total of four additional entries in the Autokey configuration tree, as you can see in Figure 8.

Figure 8: The autokeygen script creates compliant Autokey entries as per the Yaml definition in Listing 1.

Each entry creates a JSON file and a text or Python file. Note that Autokey must not be running at this point in time; otherwise, it would not notice the configuration change and would simply overwrite the new data with its own entries later on.

To parse the Yaml and JSON files, Listing 2 first loads the JSON and YAML modules from CPAN. Lines 7 to 12 define where Autokey stores the configuration files; the for loop in lines 14-19 iterates across the entries in the Yaml file from Listing 1; their data is available in the form of an array of hash references.

Depending on the entry type, the symbolic function call in line 18 either jumps to process_script() or process_phrase(). For Perl to allow audacious constructions like this in strict mode, line 17 has to reduce temporarily the level of strictness in the interpretation of symbolic references to a less stringent level.

Program by Example

To avoid the script implementing the whole mess of JSON, it bases its new creations off the sample files already put in place by Autokey; for each entry of the Yaml file, it only changes the fields in the result files that are actually different. The json_rw() function both reads from and writes to the JSON files in the Autokey configuration tree. For example, line 28 reads the test configuration for Insert Date, a sample script for dynamically inserting the current date into text documents. It then modifies only the hotkey, description, and modes entries in lines 30-32 to adapt it to the requirements for the Yaml entry to open a terminal window for the keyboard shortcut Ctrl+Alt+N.

Using a reference to the data hash as an additional argument, the call to json_rw() in line 34 switches to write mode and creates the .terminal.json file in the Autokey configuration. The Python script that uses the system.exec_command() function to call a command in the shell is then sent to the Python file terminal.py by blurt() in line 37.

The hotkey definition in the Yaml file of Listing 1 is defined tightly as ctrl-alt-n, but because Autokey prefers a more complex data structure, the hotkey() function in line 44 prepares the raw data.

The process_phrase() function in lines 58-80 creates the hth text replacement I went through earlier in the format required by Autokey. The slurp() and blurt() functions from the CPAN Sysadm::Install module do the donkey work here. During the test phase, if a script won't run as expected, take a look at the ~/.config/autokey/autokey.log file. This is where system errors are logged, and the messages are typically quite helpful.