Any Practical Alternative to the Signals + Slots model for GUI Programming?

Question

The majority of GUI Toolkits nowadays use the Signals + Slots model. It was Qt and GTK+, if I am not wrong, who pioneered it.

You know, the widgets or graphical objects (sometimes even ones that aren't displayed) send signals to the main-loop handler. The main-loop handler then calls the events, callbacks or slots assigned for that widget / graphical object. There are usually default (and in most cases virtual) event-handlers already provided by the toolkit for handling all pre-defined signals, therefore, unlike previous designs where the developer had to write the entire main-loop and handler for each and every message himself (think WINAPI), the developer only has to worry about the signals he needs to implement new functionality on.

Now this design is being used in most modern toolkits as far as I know. There are Qt, GTK+, FLTK etc. There is Java Swing. C# even has a language feature for it ( events and delegates ), and Windows Forms has been developed on this design. In fact, over the last decade, this design for GUI programming has become a kind of an unwritten standard. Since it increases productivity and provides greater abstraction.

However, my question is:

Is there any alternative design, that is parallel or practical for modern GUI programming?

i.e Is the Signals + Slots design, the only practical one in town? Is it feasible to do GUI Programming with any other design? Are any modern (preferably successful and popular) GUI toolkits built on an alternative design?

Answer 1

Although I wouldn't call it all that popular, there is always reactive programming for GUIs, especially functional reactive programming, as implemented, for example, by the .NET Rx Framework, as well as by several toolkits in somewhat more esoteric languages/platforms, like reactive-banana or FrTime, for Haskell and Racket respectively.

Answer 2

That's a favorite subject of mine, and for about a decade ('70s to '86) I thought that having a GUI consisting of objects that respond to events was just the right way to do it.

Then I stumbled on another way to do it described here and with a sourceforge project here.

In a nutshell, the problem with objects is that they persist, and if you write code to create them, you also have to write code to modify them incrementally if changes are needed, and somehow get messages to and from them. Wouldn't it be nice if you could just paint what you wanted, and then repaint it if you want something different, and not have to worry about the persistence of prior objects? Wouldn't it also be nice if you never had to write code for message handling, because it is all done under the hood?

That's what that package does. For simple dialogs, it saves an order of magnitude in code. For complex dynamically changing dialogs, it makes them possible.

P.S. I've only done this for desktop UIs and remote terminal UIs, not web browser UIs. I'm sure it's possible, but I haven't had the chance to try it.

Answer 3

Well, there's two distinct ways to go about this:

1. Have every widget expose a granular subscribing mechanism (Signal/Slot, Observer/Observable, Event/Delegate) and have client code subscribe and take action accordingly.
2. Built a widget against an abstraction of the data it presents and have client code implement that abstraction.

Here's an example for the second approach:

interface Action {
     void execute();
     Bool isEnabled();
     Null<String> description();//used for tooltip
}
interface LabledAction extends Action {
     String getName();
}

And now you can build a LabelButton against a LabledAction and client code can just implement it or use some generic default implementation, if available and suitable.

In a way the second approach is less flexible, but more rigid. You don't just somehow wire together the view with the model through relatively atomic means. You design a suitable GUI based on your requirements and then you implement the adapters between that GUI and your domain/application logic.

Answer 4

A few control type systems use a database approach - each gui control is linked to a filed in the database so that the Gui always reflects the database state. DB hooks are used to trigger functions when a value changes.