As stated in the bug report, MouseTrap does not currently update after a user makes a change in their preferences menu. The new setting is written to the configuration file but the user must still close and restart MouseTrap in order to see the change. I first began by attempting to make a change in the main.py file. In the start() method, it calls the settings.py's load() method to initially create the config file. I thought that if I included an else statement there, it would just load the already created user config file. Unfortunately, after this change MouseTrap wouldn't even start up anymore so I reverted back to the original code. I decided to dig deeper into the load() method so I focused on the settings.py file next. However, this was about as far as I got. I never did figure out what change I would need to make in the load() method. I do suggest that the next person who reviews the bug should take a look at the load() method in the settings.py folder again, I do believe that this is where the change needs to go. Or at least, I believe it's part of the solution

The code has significantly changed since Tiago last looked into this. But svieten's suggestion is still relevant.

What if we follow the convention that daemons/servers reload their configuration
(and reopen their log files) when they receive a SIGHUP signal from the
operating system [1]. If mousetrap reloaded its configuration on SIGHUP, the user, mousetrap itself, or an external processes (like a configuration GUI) could cause trigger a mousetrap instance to reload its configuration. For example, a user could trigger a reload as follows:

    ```sh
    $ mousetrap &           # run mousetrap as a background process
    [1] 80369               # user takes note of mousetraps PID
    $ vim ~/.mousetrap      # user modifies mousetrap
    $ kill -SIGHUP 80369    # issue SIGUP to mousetrap via its PID
    ```

Users can also find a processes PID by using `top` or `ps`. However, it is also
common for daemons/servers to write their PID to a file in a documented
location.  This allows other processes to easily get the PID of a running
daemon. It also allows the application to avoid starting multiple instances of
itself, which would also be a good idea for mousetrap. That PID file should
probably be under each user's home directory (e.g., `~/.mousetrap.pid` or
`~/.mousetrap/pid`).

This suggestion could be implemented in roughly three or four parts.

1. Have mousetrap save its PID to a file. This allows other applications to
   easily identify mousetraps PID, and also allows mousetrap to avoid running
   multiple instances of mousetrap at the same time. (pid.py is a handy Python
   module that will make this easy. It's available through pip. But using it
   would add another dependency.)
2. (a) Implement an event bus that allows components to register for and fire events
   (suggested also in bug 741136). (b) Then have all components that depend on
   configuration data register a callback for a "configuration reloaded" event;
   those callbacks would make the necessary adjustments.
3. Implement a Unix signal handler that will reload mousetrap's configuration
   when a SIGHUP is received.

2.b is probably the biggest change, requiring consideration to be given to each
component in the system. With proper testing, each part could be implemented
independently of the others and later integrated.

[1] http://en.wikipedia.org/wiki/Unix\_signal

We're getting our versions straightened out. All bugs associated with gnome3-wip are now against 3.17.x.

mousetrap is not under active development anymore since 2015.
Its codebase has been archived:
https://gitlab.gnome.org/Archive/mousetrap/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the
responsibility for active development again.