How to manage event-based input in a modular user interface?

Question

User interfaces often consist of different input devices like buttons, input fields, dialog boxes, sliders and others. The event order generally determines the expected behavior, and this behavior often is not easy to catch in a simple rule.

Is there a generic approach to this type of problem?

As an illustration of how easily an interface can become complex, take an interface with 3 toggle buttons. If the behavior of a button click depends on the state of each button, 2 ^ 3 * 3 = 24 event cases are possible. If the behavior also depends on the event history, the number of event cases grows exponentially.

As a real-life example, look at a wysiwyg text editor that I am working on. I choose the focus/blur event on the editor to enable/disable the editor. Some buttons (widgets) return the focus to the editor immediately, while other buttons open a dialog. In the image below arrows show where the focus should go when clicking on an interface element.

I found managing of focus a tricky issue here, often introducing undesired or counter-intuitive behavior.

Answer 1

Getting my question right is part of the answer. My question is about a special case in which widgets are not only representations of data, but rather input devices for a shared piece of information.

An event dispatcher, as suggested by Matteo Migliore, has a different use. It is helpful in cases where the information flow is more linear: on the one side one or more objects that can fire an event and on the other side objects that listen to those events.

In my case, not only the managing of events should be centralized, but more importantly, also the managing of logic. This logic is characterized by several actuators influencing the same datasource in a way that can easily cause loops. In my case this datasource is: where is the focus and when should the editor be activated/deactivated.

The solution to prevent loops is to use an internal state variable and carefully design a mapping that translates each state + event combination into an action + new state. A basic implementation could look like:

switch (eventdescription) {
  case 'click_in_txt':
    switch (state) {
      case 'inactive':
        activate();
        state = 'active';
        break;
      case 'plugin_has_focus';
        close_plugin();
        state = 'active'
        break;
      default:
        console.log('undefined situation ' + state + ' / ' + eventdescription);
    }
  ...
}

This approach still needs some trial and error, but it easy to see which situation causes a bug, and then you can change the behavior for that situation alone. Also the console.log() function shows where you overlooked some combination of events that might cause unexpected behavior.