I am designing a program responsible for a GUI (with the graphics and user input being managed within a typical update loop) which has several states:

  • The default state is an animation which continuously runs despite any user input.

  • A notification state can be invoked which displays a notification instead of the animation. Notifications have a timeout which should-self close after that time and return to the default animation, it could also be closed prematurely by user input or by another notification of greater priority.

  • There is also a presentation mode which plays a video clip and should self-close and return to the default state after it ends. However, an important notification can also pause the video and be displayed, after which the video should resume, and return to the default animation once it ends.

More states are envisioned in the future although their requirements have not yet been defined. But as you can see, the architecture should be extensible with the ability for more states being added in. Therefore, each state should be able to control it's own lifecycle and invoked state changes for the GUI. For each state transition the screen should also fade out the current state and face in the next one.

My question is what kind of OOP architecture can be used to achieve this (as opposed to if/then statements in the update loop)? Are there any design patterns (perhaps state pattern) that can achieve this?

Note: It is being developed with SFML and c++.

  • If you can use Qt, why don't consider the QStateMachine Framework?
    – Moia
    May 22, 2018 at 8:32
  • Most modern GUI frameworks don't require to write an event loop by yourself, they provide you with one. SFML seems to work differently, so you question is very specific to this framework.
    – Doc Brown
    Aug 20, 2018 at 10:59
  • ... so if you want to create your own "GUI event queue", I would google for exactly these terms, took me immeditaley to this site, maybe that's what you are looking for?
    – Doc Brown
    Aug 20, 2018 at 11:06

2 Answers 2


You could use the state pattern but as it is now this looks like a simple app with a couple of views - im not sure implemening an explicit state machine is worth it but this is depending on the capabilities of your GUI framework.

If it really is bare-bones and you have a render loop for drawing etc then yes it might be worth it but if the framework is higher level and facilitates swapping views etc I wouldn't bother.


State pattern certainly looks like a candidate for the different "screens" and their transitions. As you need to cross-fade, you'd have to vary it slightly, having an "active" state and an "obsolete" (or previous) state during the fade-out (both would animate, but only the active would have a behaviour or reaction to the UI events).

I'd seriously reconsider having a loop running continuously. That will probably put the CPU use to a 100%. Even with a loop, the best option seems to "sleep" the process some milliseconds and issue updates at regular intervals (you'd still get nice and smooth animations, but reducing the CPU usage greatly). Then, for both the "animation tick" and other UI events, the Observer pattern will help. One of the advantages you'd get is that you can even decide to animate or not to animate certain elements dynamically by just subscribing or unsubscribing them to the "animation tick" events. You can ignore the animation of a hidden widget in its redraw function, but there's no need to even call that function in the first place! ;)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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