A new GUI for openFrameworks

this looks incredible!

for me one of the most important things is saving state to xml. is that possible?

looking forward to seeing the code…

This looks nice, really great work! I’m also curious about saving state and having the panels/controls tie into the core OF events system as well to keep the code around the implementation a little cleaner. Looking forward to seeing/testing/using.

looks great! also, what kyle and joshua said. I’m already curious.

wow, this looks really impressive. very curious to give it a try. nice work!

want to give it a try also.

I’d been using MyGUI 002, it’s from all the ones i’ve seen the neatest one altough i’ve done some modifications to it so it adjusts to some of my needs.
By what the pics posted this GUI seems much more developed and flexible.

BTW, so far how many OF GUI addons are laying around? any intention of adding an official version to the OF core?

best regards!

these two threads give a good overview over GUIs on oF:

http://forum.openframeworks.cc/t/different-guis-for-openframeworks/4376/0 (bernard could you add yours here when yuo publish it?)


About the communication between my GUI and other code:

I don’t use callbacks, I only use ofEvents.

To control the widgets with the mouse and the keyboard, there are 2 possibilities :

  • let the gui respond to ofEvents.draw, ofEvents.keyPressed, ofEvents.mousePressed etc…

  • call the methods of the gui from draw(), keyPressed (int key), mouseMoved(int x, int y )
    this is specially usefull for the keybord events: if there is a need to use key commands f.e to toggle fullscreen,
    it is usefull to use it in the keyPressed method and only call the gui code if no other key was pressed.

To make the gui trigger different actions I created a special kind of custom ofEvents that can take various parameters and this events are sent when a widget is modified. Group widgets like listboxes use the same event and uses a parameter that corresponds to the index of the widget in the list.
The programer that uses the gui creates then a listener for each event. (I will give a few examples in my code)

These events can also be sent to an OSC object, and so make it possible to control another application (eventually on another computer) from the gui.

Instead of controlling the gui with the mouse and the keybord, it is also possible to send an ofEvent to a gui object to change its state. The gui has its own event listeners. There is no need to create them.

In this way, when the state of an object has changed, it can send an updating message to the gui, in order to synchronize its state with the object.

It is also possible to send OSC events to the gui, making possible a bidirectional communication between applications.

The gui widgets can also be controlled by incoming midi messages (using ofxMidi) .
I actually control remotely the gui of my program with the Korg nanoKontrol.

About saving state to xml:

I don’t use that actually, but it will be easy to implement it and I can do it if can be usefull to somebody.

I actually do the opposite. I save the state of my projects on disk (in another format than xml) and when a project is loaded from disk, it sends messages to the gui to update its state.

When for example a sequencer is used I display the selected track on the gui, and when I select another track, the gui will be changed.

But if a create a routine to save the state of the gui to disk, when loading it from disk, the gui will be updated and will send the same messages as it had been modified with mouse or keybord.

It could be eventually usefull to save the entire gui to an xml file (including the messages) and by this way one could create the gui with another application. One can then imagine to use different guis with the same application for different needs.

this sound good, you’re making us curious. :slight_smile:
xml: one advantage of specifying the whole state is that it can easily be loaded/saved, and configurations can be easily exchanged, or even created with other programs as you pointed out. xml is modern, modular, kinda universally recognized. what format do you use currently?

does the placement of the widgets happen manually? is there an option for (semi)automatic arrangement (planned)?

I actually use a plain text file format to store my preferences.
It is inspired by the format used by Max / Pd patches.
I will also implement the xml now.

About the placement of the widgets:

  • they can be placed in absolute position (relative to the top of the window)

  • relative to the last created widget in the parent panel
    can be on the right or on the bottom of the last widget, with an x and y offset (positive or negative)
    for little corrections/fine placement

  • on the next row or on the next colomn inside the parent panel

Excellent looking, of needs a unified gui - nice visuals too.

You can find it here :

It took a little longer than expected (corrections of the display, saving/restoring the settings to/from xml, synchronization of widgets with variables, and some documentation of the classes and methods)

I took also the time to make an example project that shows most of the possibilities.
It is constructed like a tutorial, with many comments.

Thank you for all your kind comments and hoping you will enjoy what I did!


wow - I can see what took a while - pretty epic stuff.

Great job - thanks for sharing!

this is really impressive. the addon is super complete, well commented, and the example is also well commented. very curious to see who starts working with this next.

I think this is the first good code-comment tutorial I’ve read, and I read a lot of tutorials :slight_smile: Nice work! One thing I noticed though was this line:

// The addon ofxGui depends on the addon ofxUtils  
// Don't forget to add ofxUtils to the project  

which confused me for a moment, but I’m assuming you meant your ofxhUtils.h All the stuff in hUtils looks very useful.

There are 2 mistakes in the file testApp.cpp
of the project ofxhGui_1.0 _Example1

  • In the following comment

// The addon ofxGui depends on the addon ofxUtils
// Don’t forget to add ofxhUtils to the project

It was meant ofxhUtils instead oh ofxUtils

  • In the function void testApp::setup()

#if OF_VERSION < 7
ofSetWindowTitle(“ofxGuiExample1 - openFrameworks 6”);
ofSetWindowTitle(“ofxGuiExample1 - openFrameworks 7”);

It has do be ofxhGuiExample1, and not ofxGuiExample1

(Sorry, it was not my intention to create a confusion between my project and ofxGui)

On older computers or graphical cards, rectangular frames are not always displayed correctly.
I will try to adress this problem in the next release of the addon.
I took much time making the GUI looking identical on Mac OS X and Windows, but it seems only to work on relatively recent hardware.

I had not yet the time to make examples about how to communicate between ofxhGui and MIDI or OSC
I will do that and upload it later.

regarding the older graphics cards rendering rectangles, see this issue https://github.com/openframeworks/openFrameworks/issues/798

i think different graphics cards might have different ideas about whether the pixel grid is aligned to the pixel corner or center.

Thank you so much for this. I have never even managed to get any of the other GUI add-ons to work before.

This one compiles great and is extremely well documented. Great job!

I corrected the incorrect display of framed rectangles on certain video-cards.

The actual version is now ofxhGui 1.01

You can downlod it here:

Many thanks to kylemcdonald for his clever solution