Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
2  
QT and GTK+ are far from beeing the first GUI frameworks which were using an event driven approach. The concept reaches back to Smalltalk-80 (en.wikipedia.org/wiki/Smalltalk). –  Doc Brown Apr 1 '12 at 16:41
    
Interesting question, I'm curious if this model changes much with multi-touch interfaces. –  Ben DeMott Apr 1 '12 at 18:15

5 Answers 5

up vote 7 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
Model/View/Controller is good, but it's just an extension of the observer pattern, because the controller part is just an observer of the widget and in the model part the widget is observer of the model, so it's the same mechanism other way around. –  Jan Hudec Apr 2 '12 at 14:13

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.

share|improve this answer
    
+1, But how is it possible to achieve extra functionality, such as user defined input? –  ApprenticeHacker Apr 2 '12 at 10:24
    
@IntermediateHacker: I'm not sure what you mean by user defined input. Do you mean having a form-designer app? –  Mike Dunlavey Apr 2 '12 at 14:27

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.

share|improve this answer
4  
isn't this still signal-slot just with an extra DB layer? –  ratchet freak Apr 2 '12 at 9:25
    
Ultimately underneath it's all interrupts or callbacks - they are the only low level async operations –  Martin Beckett Apr 2 '12 at 15:17

The message queue paradigm that you find in Windows API is not like events and delegates. Delegates are called synchronously and immediately, like std::function, not an asynchronous signal. In addition, the WinAPI does provide DefWindowProc which processes Windows messages as a default implementation. So I'm gonna posit that your question is based on flawed logic.

share|improve this answer
    
I'd be generous and assume he knows of SendMessage which is syncronous, not just PostMessage. However, he's still wrong in that you never had to write the entire message-handling loop for every message. –  gbjbaanb Apr 2 '12 at 12:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.